TEAM 6: Healthnet
|John Bauman||Kyunghwan Choi||Eugene Marinelli||Adam Goldhammer
- Give consumers access to their personal physiological data.
- Wireless network of sensors on the body to process and record EKG, temperature, and location data.
- Current consumer fitness products only report heart rate and blood pressure data.
- Devices in the medical industry capable of more detailed reporting are not very portable and often expensive.
- Our product will allow consumers to record detailed physiological information at their convenience.
Power Glove Basic Strapless Heart Rate Monitor
- Requires no chest strap
- Simple 2 button Operation
- Cheap ($80)
- But this is a very basic unit which displays the heart rate only
Garmin ForeRunner 301 speed & distance watch with heart rate
- Manufactured from the biggest GPS company
- Provides precise latitude, longitude, and altitude data
- Amount of calories burned
- Performance data can be archived
- The user can create, analyze and store workout data on PC
- Heart rate monitor
- Costly ($200)
TIMEX BodyLink Trail Runner
- A famous watch company with the unit
- Provides Latitude, Longitude, Altitude and elevation data with ascent and descent rates
- Ability to add 10 waypoints
- Realtime, average and max speed
- Continuous odometer
- Current pace, average and best pace
- Expensive ($300)
- Physical sensor - Telos tmote (with EKG pad, pulse oximeter).
- Send data wirelessly to sensor server.
- Wearable Gumstix ARM board wired to one sensor, and equipped with Bluetooth transmitter.
- GPS connected to grab location data
- Screen for displaying current data to user
- Embedded software manages data from the sensors and interfaces with a personal computer.
- Desktop application for uploading data from the sensor server via Bluetooth.
- Web interface for viewing and sharing data.
- Wireless sensor network of EKG pads, pulse oximeters, and other types of sensors.
- Wirelessly transmit data to a personal computer for analysis and visualization.
- Display heart rate and energy expenditure data.
- Make hardware system convenient and portable.
USE CASES (INTERACTION DIAGRAMS)
Use cases (PDF)
RISKS & MITIGATION STRATEGIES
|Problems with sensors and nodes
||Alternative node hardware: mica2dots
|Inability to support data rates between devices
||Compression and less frequent trasmission
||Error detection. Variety of sensors
- 2 Telos tmote sky units
- Node 1 - Pulse oximeter and accelerometer used for pedometry.
- Node 2 - EKG.
- TinyOS 2.0 + nesC
- Simple software - read data, multiplex it, send wirelessly
- Have to keep time synchronization with server and other nodes, so synchronize time at startup and occasionally afterwards
- The aggregator daemon polls for sensor values and stores them to a sqlite database.
- gpsd is the daemon which communicates with the GPS device and serves the user's current
location. The aggregator requests the location from gpsd using a TCP socket.
- noded handles communication with the sensor nodes.
- The uploader script requests data entries from the Sensor Server and stores each entry in
a local sqlite database.
- The user interface is implemented in PHP and uses jpgraph to generate charts and maps.
- The database schema
- Bodystats contains the data from the body sensors
- Exercise ID
- GPS Location Data
- Heart Rate
- Pulse Ox
contains the user data
so the data can be personalized
- User Name
- Exercise Route contains the usual exercise route data
- Exercise ID
- User Name
- GPS Location
- Startup - This will actually happen often, and we can just turn on the power fault-free.
- Transmitting data - occurs, makes sensor - this is the cornerstone of the project, just transmit data fault-free.
- Concurrent Nodes - it will be necessary for us to have more than one node, we can just run multiple nodes transmitting data, fault-free
- Time Synchronization - do times match up afterwords - we need to make sure that times match up so that we can correlate data - we can test this by injecting events to two or more nodes, and making sure that the times match
- Startup - obviously necessary, just turn on the power.
- Pairing with computer - without this, no data works - just attempt to pair from a computer and make sure it works.
- GPS data - this is a nice device function - move to places, find latitude and longitude from GPS, and compare with real location - fault-free.
- Connection with sensor nodes - otherwise data will never be collected - run normal system fault-free.
- Connection with upload program - otherwise data will never be collected - run the uploader script fault free.
- Stress test communiations - bandwidth, reliability - want to make sure it always works at uploading - test sending and receiving fault-injected stuff (interference from other motes)
- Test aggregating data - we want all data to be transmitted well - collect two or more types of data and upload all of them fault-free.
- Test communication between modules
- Simultaneous access to database
- Unexpected shutdown
- Memory fills up
- GPS sending rate
- Test GPS inside, outside
- Stress test uploader program - there will be lots of radio noise, problems - add lots of bluetooth and wifi devices and make sure the program still works.
- Pairing over bluetooth
- Receiving illegal values - Our code will be buggy, so we don't want to crash the computer - send illegal values, and make sure the computer will handle them (fault-injected).
- Charts are accurate, correspond to data - user confused if charts all wrong, defeats device purpose - put known data in database, compare against chaarts (fault-free)
- Correct set of data is saved - user angry if device deletes data - send known data, and make sure it is all saved on computer (fault-free).
- Transmission rate (Sensor server - Computer)
- Time transmission of datasets of known sizes. Divide time by data set size.
- Data must upload in a timely manner.
- Units: s
- Amount of data that can be stored on sensor server
- Run sensor server until memory is full, record data set size.
- Document maximum time sensor server can run between uploading to a computer.
- Units: MB or hr
- Battery life (nodes and sensor server)
- Run unit till power failure.
- Average battery life must be documented for users.
- Units: hr
Sensor server and sensor node prototypes
Hardware at final demo
- Project Proposal and Requirements, Team Project Presentation, February 1, 2008
- Design & Architecture, Team Project Presentation, February 15, 2008
- Mid-semester Project Status, Team Project Presentation
- Test Plan & Experimental Validation Team Project Presentation, March 28, 2008
- Final Project Presentation, Team Project Presentation
- Project Poster, May 2, 2008
Back to the top of this page
18-549 course home page