1. Dragonfruit
Real Time Well-Being Monitoring
Alex Erdman | Brendan Tawa

2. Team
Alex Erdman Brendan Tawa
 Hometown: St. Louis, MO  Hometown: Fairport, NY
 Hobbies:  Hobbies:
Aviation, Photography, Liquor Video Games, Skiing, Beer
 After RIT:  After RIT:
Intel – Client Applications Cisco - Technical Assistance
Engineering (Folsom, CA) Center (Raleigh, NC)

3. Product Vision
 Develop a system for monitoring elderly persons or medical
patients in a household environment.
 Monitor What?
 Environmental parameters:
 Ambient Temperature / Humidity
 Smoke / Fire / CO
 Physical Security
 Patient Health
 General Activity
 Did the person get out of bed in the morning? Is there periodic movement?
 Fall Detection
 Heart Rate / BP

4. Target Market
 Families
 Private Caregivers
 Senior Apartments
 Nursing Homes / Rehab Centers
 Geographies Where Competing Commercial Services Aren’t
Available

5. What Is Dragonfruit?
Environment Monitoring
3 Tier Solution:
Patient Monitoring
1. Sensor Network
 In-home and on-person
2. Base Station
 Single piece of on-site
hardware to aggregate
all sensor data.
3. Web-Based GUI
 Provide real time information
and historical event logs. Email Alerts Web Tracking
Mobile / Desktop

6. Tier 1 | Sensor Network
 Environment Sensors
 Typically analog
 Motion detection
 Smoke / fire / CO
 Intrusion detection
 Interface device : electric imp
 Patient Metrics
 Typically digital
 Heart Rate / BP
 Fall Detection
 Interface device: TI ez430 Chronos Wristwatch

7. Tier 1 | Sensor Network
 Electric Imp
 ARM Cortex-M3 microcontroller
 802.11n WiFi, GPIO, I2C, UART, PWM, Analog I/O
 SD Card Form-Factor
 Pros
 Form Factor
 Cost
 $30
 $12 breakout
 Cons
 Squirrel ?
 Web-based SDK
 Poor debugging
 Community support
pails in comparison
to mBed

8. Tier 1 | Sensor Network
 TI ez430-Chronos Wristwatch
 MSP430, 915Mhz RF transmitter, 96-segment LCD
 3-axis accelerometer, pressure sensor, temperature sensor
 Pros
 Form Factor
 Cost
 $60
 Eclipse + C
 Active user
community
 Cons
 Unstable HW 
 TI documentation
scarce / poor
 Flaky client drivers

9. Tier 2 | Base Station
 RaspberryPi
 ARM1176JZ-F, GPIO, Ethernet, HDMI, Audio, USB
 Pros
 Cost
 $35
 I/O
 Flexible UI
 Active user
community
 Cons
 None ?

10. Tier 2 | Base Station
 Inside the base station - “Pi Filling” : Python, Python and HTML
 Establish HTTP socket server / listen for POSTs from electric imp
 overload the server’s do_Post handler function
 parse JSON string fields into local variables
 decide if the data constitutes an “alarm condition”
 has the smoke alarm been set off?
 the motion detector has been triggered
 note the time
 how long before next trigger is expected?
 log alarms by sensor ID and date/time in SQLite database
 Open serial comm with ez430-Chronos RF receiver
 poll receiver for accelerometer data
 compute the moving average of mgrav in Z direction
 is there a sharp spike over a window of ~6 samples?
 indicates possible fall
 SMTP daemon to send email alerts.
 Serve HTML for web interface
 dynamically generate log tables from SQLite database

11. Tier 3 | Web-Based GUI
 Presents all system data in one place,
easily accessible anywhere, from any
web enabled device.
 Python script crawls the SQLite data
and reports last known events and
generates historical logs.

12. Why Dragonfruit?
 The idea isn’t new.
 The technology isn’t new.
 Commercial solutions already available.
 What sets Dragonfruit apart?
 Accessibility
 Low initial costs, no recurring fees.
 Similar service from ADT
 $365 install
 ~$80/mo. = ~$1000/yr.
 Similar service from Philips LifeLine
 $100 install + $30 enrollment + $20 s&h
 $41/mo.
 Push button pendant only, no fall detection, no environment monitoring
 Dragonfruit works wherever there is a web connection
 Traditional services rely on PSTN and are region specific

13. Retrospective | Looking Back
 Did the final product measure up to our original goals?
 No – but it is a start.
 “lofty” goals from the beginning
 Envision a polished final product, retail ready
 Solid aluminum housing
 Black glass front
 Voice activation
 End up with prototype / proof of concept
 Two guys
 Three platforms
 Five software languages
 Squirrel, C, Python, SQL, HTML
 Ten weeks
 Minus ~a week to finalize platform / idea
 Minus time commitment to other full-time undergrad responsibilities

14. Retrospective | Roadblocks
 Self-support
 Hardware
 Middleware
 Web
 WiFi @ RIT
 Electric imps wouldn’t work at first
 Chris to manually register the MAC addresses
 TI watch
 Crashing, resetting
 RF USB dongle
 Send erroneous data if buffer filled up
 Electric Imp / COSM
 Foreign language
 Attempted to use COSM as primary data transport method, mainly due to
its curb appeal, however it introduced significant delay; resulted to HTTP
POST

15. Retrospective | Lessons Learned
 In general we liked the project.
 The idea of following an idea from conception to implementation is
rewarding.
 More applicable, certainly more challenging then textbook lab
exercises.
 Exciting challenge to consider / incorporate UX.
 Branching out from C / VHDL
 Taking what you know from those languages and applying it others.
 Time flies
 Make quick decisions
 HW selection or SW methodology
 If something is panning out, how much effort are you going to sink into it
before moving on to plan B?

16. Retrospective | Dragonfruit 2.0
 If we had to do it again.
 (Recommendations for future ESDIII students)
 Keep it simple. No, really. Keep it simple.
 Ambitions
 Realistic goals up front.
 Get initial features 100% working, then add on.
 HW
 1 platform
 Choose wisely.
Home Health Hub Reference
 Well documented, solid online user community Platform
 1 SDK
 Rely less on middleware, such as python, do as much work as possible in
hardware microcode.
 Time management
 If something isn’t working, cut your losses and move on to the next option.

17. Dragonfruit
Real Time Well-Being Monitoring
Alex Erdman | Brendan Tawa