• Concept
• Motivation
• Competition
• Tech Specs
• Requirements
• Architecture
• Use Cases
• System States
• Risks
• Error Handling
• Implementation
• Test Cases
• Evaluation
• Lessons
• Fun Stuff
• References
• 18-549 Home

Trac

Source (tarball)

MEMBERS

PROJECT CONCEPT

• Give consumers access to their personal physiological data.
• Wireless network of sensors on the body to process and record EKG, temperature, and location data.

MOTIVATION

• 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.

COMPETITIVE ANALYSIS

• 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)

TECHNICAL SPECIFICATIONS

• Sensor modules
  • Physical sensor - Telos tmote (with EKG pad, pulse oximeter).
  • Send data wirelessly to sensor server.
• 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.
• User interface
  • Desktop application for uploading data from the sensor server via Bluetooth.
  • Web interface for viewing and sharing data.

REQUIREMENTS

• 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.

ARCHITECTURE

USE CASES (INTERACTION DIAGRAMS)

RISKS & MITIGATION STRATEGIES

IMPLEMENTATION DETAILS

• Sensor modules
  • Hardware
    • 2 Telos tmote sky units
    • Node 1 - Pulse oximeter and accelerometer used for pedometry.
    • Node 2 - EKG.
  • Software
    • 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
• Sensor server
  • Software
    • 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.
  • Hardware
    • Robostix and gumstix board
    • EM-406A GPS receiver
    • Xbee module
    • LCD screen
• PC
  • 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.
• Common
  • The database schema
    • Bodystats contains the data from the body sensors
      • Time
      • Exercise ID
      • GPS Location Data
      • Heart Rate
      • Pulse Ox
      • Temperature
    • Users contains the user data so the data can be personalized
      • User Name
      • Password
      • Height
      • Weight
    • Exercise Route contains the usual exercise route data
      • Exercise ID
      • User Name
      • GPS Location

TEST CASES

• Sensor Nodes
  • 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
• Sensor Server
  • 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
  • Shutdown
  • Unexpected shutdown
  • Memory fills up
  • GPS sending rate
  • Test GPS inside, outside
• Computer
  • 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).

EXPERIMENTAL EVALUATION

• 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

FUN STUFF

REFERENCES

• Project Proposal and Requirements, Team Project Presentation, February 1, 2008
• Design & Architecture, Team Project Presentation, February 15, 2008
• Test Plan & Experimental Validation Team Project Presentation, March 28, 2008
• Final Project Presentation, Team Project Presentation, Date TBD
• Project Poster, May 2, 2008