Skip to main content
Try Wikispaces Classroom now.
Brand new from Wikispaces.
Pages and Files
Quick Start Guide
History of Major Design Decisions
Ongoing Validation Testing
Which Phones Can be Used and how? (coming soon)
Phone Testing Procedure (coming soon)
Obtaining Wockets Hardware
Option 1: Make Them Yourself (Detailed Info on Assembly) (Coming soon)
Option 2: Buy Them in Small Quantities (Coming soon)
Option 3: Collaborate with Wockets Team (use loaners) (Coming soon)
Testing and Calibrating Wockets
Calibrating a Wocket
Testing a Wocket (coming soon)
Google Code Site
(all software, including firmware)
HW Design History and Tech Specs
Wockets data formats (coming soon)
Wockets Software Architecture (coming soon)
Wockets Timestamp Correction (coming soon)
Wocket Enclosure and Band
Housing V3 Sealer Construction
Sensor Housing V4 concept and production
Bands and poach concept and production
Activity Recognition Software
Research Papers - Reading List
Wireless Sensor Kits
Other BT Sensors
Open Source Hardware
Open Source Tips
Physical Activity Conferences
Legacy Stuff (e.g., MITes)
MITes Design Info
Files for MIT/Stanford/UT/Northeastern Projects
Ongoing Validation Testing
The research teams working on Wockets are developing procedures and studies to validate the sensors.
This page is a to-do list of sorts for the team. Only recently (August 2011) did we receive the latest hardware revisions. We could use help doing the engineering performance testing of the sensors, which includes some of the issue below.
[Revise list below]
Top priority issues that may impact hardware design
Verify check that we are maximizing our sensitivity, for the various g ranges allowed for by the acclerometer.
Verify that the device works properly at accelerometer settings other than 1.5g. Test by visually inspecting plots and running calibration proceedure.
Use meter to measure average current draw when transmitting.
Battery life at room temperature
Transmit continuously and timestamp when no more data is received. Compute mean and variance across devices.
Detail switch behavior so that switch can be used for two purposes:
Initiating programming mode (when device plugged into programmer)
Setting device to "nearly off" (when device not plugged into anything) -- to save the battery so it is not discharging between use. Pressing button again in this state should turn the device back on.
Wireless dropout in a standard configuration
Wear three sensors (hip, wrist, left pockt) and carry phone in right pocket. Measure PPS for several hours of normal behavior ranging from working at the desk to vigorous running. Confirm that despite proximity to body, sensors staying connected and data are being received.
Shelf-life with battery connected
The wocket is always on, so this would be equivalent to measuring battery life when the bluetooth is not connected. This could be calculated by measuring the power consumption
Confirm that adding a second battery operates as expected
Verify how much non-volitile memory we have available on the microprcessor for storing sensor calibration parameters. (Think about how we will set these in practice, in some easy way)
Determine if we can check how many packets received. I none for some time, can we force a reset faster than the BT chip is doing now?
Other performance tests that may impact hardware design
Outdoor wireless range
In an open field, transmit packets at 60Hz and count the # of received packets/sec (PPS), averaged over 1 minute. Do this with 1.) antenna in parallel, line of sight orientation and 2.) antenna constantly changing orientation (rotating by hand). Repeat at 5m intervals.
Indoor wireless range (with occlusions)
Similar to outdoor test, except in a “typical” indoor room (?). This may be repeated in more than one room.
Wireless range orientation sensitivity
With the sensor 1m away from the phone in line of sight, average PPS when antenna is held parallel and perpendicular relative to the phone.
Wireless dropout due to body blocking
The straightforward way to do this would be to define a set of common body blocking situations and count PPS, trying to keep antenna orientation fixed relative to phone if it had an effect. Phone is kept stationary 1m away. One could potentially sort the scenarios by obstacle width between sensor and phone and the degree of antenna enclosure. Need suggestions for sensor locations.
Accelerometer values: sensitivity to temperature
Heat the device to 150F in oven. (or with hot air rework station) Use thermometer to keep track of temperature as it cools down. Record raw ADC data with sensor stationary. For cold temperatures, put sensor in a glass container and place container in an ice bath. Record data as it warms to room temperature.
Accelerometer values: sensitivity to humidity
use digital humidistat, humidifier, and dehumidifier in an enclosed area (plastic container or similar)
Accelerometer values: differences between devices and need for calibration
For all working sensors, compute the offset and slope of the accelerometer output using Fahd's calibration code.
Variability on sampling rate (at phone reception)
With sensor and phone at fixed positions, record samples for 2 minutes and calculate the variance of the PPS distribution. (Do this for multiple distances?)
Noise level of accelerometer
Set accelerometer flat. Acquire raw ADC output for 1 minute. Find the mean and variance of the output values. Also, you could use an oscilloscope and observe noise frequency and amplitude.
Battery life in cold temperature
Transmit continuously and timestamp when no more data is received. Compute mean and variance across devices. Compare with room temperature results.
Impact on wireless performance of
Other Wockets (1-5)
2.4 GHz phone
WiFi network (heavy usage)
Accuracy of tilt sensing software
help on how to format text
Turn off "Getting Started"