Skip to main content
Get your Wikispaces Classroom now:
the easiest way to manage your class.
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
Major design decision - wireless protocol
Major Design Decision: Wireless Protocol Strategy
The basic constraints for our system can be found here:
. There are at least ways that we could achieved this goal. Choosing an approach was one of the biggest design decisions we made.
Option 1: Use two wireless protocols.
We could have used a low-power, lightweight wireless protocol for the accelerometer devices to be worn on the body. The low power devices would transmit to a receiver that then transmits to the phone. Our only viable option for transmitting to the phone today (and at least for another year or two, if not longer) is Bluetooth (BT). The intermediate device could be carried anywhere on the body, so it can be larger than the accelerometers, so it could clearly have a battery that perimts 24h performance even recieving the low-power protocol and transmitting Bluetooth.
We knew we could get 24h of continuous transmission of accelerometer data at 180Hz doing this on a battery as small as a CR2032 coin cell.
The intermediate device would be able to do substantially more processing than the transmitters, perhaps using strategies that would allow for Bluetooth battery life saving on the phone.
If phone wireless protocols change, no change would be required to the transmitters, only the intermediate device.
Low-power transmitters, such as those from Nordic Semiconducter, are far less expensive than Bluetooth transmitters, and this system configuration only requires one Bluetooth transmitter (as opposed to one BT transmitter per acceleromter), possibly keeping cost down.
Carrying the intermediate device creates a substantial user-interface burden. Our user studies suggested that the carrying the device could be problematic for many people.
This configuration creates many points of failure. The two different wireless protocols can both fail, with greater chance of wireless interference. We experienced this with a prototype we built. There are more security concerns.
The low-power transmitters may be more susceptible to body blocking than BT-based transmitters.
Two different types of devices (transmitters and the intermediate device) must be manufactured, increasingly complexity and possibly cost.
Option 2: Make Bluetooth transmitters.
Here transmitters send data directly to the mobile phone using Bluetooth. To make this viable, a strategy must be used to reduce the amount of data transmitted, otherwise the battery size is too large to be practical. We have considered several strategies, such as transmitting only when limbs move. We obtained some preliminary evidence, for instance, that in a 24h period, the worst case sensor location of the wrist would require transmitting only about 25% of the day, possbily far less. An alternative strategy would be to have the transmitters compute important features on the data locally, and only send that data rather than raw accelerometer data. That reduces the flexibility of what can be done on the phone, however.
This is a simple configuration that may lead to simple electronics that may be more robust, less expensive, smaller, etc.
The user doesn't need to worry about carrying any extra devices.
Data transmission using Bluetooth may be more reliable than a low-power protocol and less prone to body blocking and interference.
The range may permit activity tracking even if the phone is fairly far from the body (e.g. when placed on a counter at home).
Bluetooth is power-hungry. We know that we cannot transmit 24h continuosly with a battery size that is reasonable so the sensor will be comfortable on all parts of the body (e.g., small wrist). The transmitter must use a strategy to reduce transmissions.
Every transmitter needs a BT radio, which are more expensive than other options.
The BT transmission must be optimized to eek out all available battery life ... no wasted bytes should be sent. Data should be carefully managed to fill BT packets optimally.
Even though technically it is possible according to the specs, in practice obtaining multiple reliable BT pairings to a phone (without requiring user interaction and allowing for robust, automatic reconnections) could be problematic. [There is a limit of 7 but this is more than the 3+ we want to achieve].
Tricks that may increase battery life (e.g., local buffering and thresholding) may also introduce new problems, such as how to get synchronized data from multiple transmitters on the phone.
We ultimately decided on Option 2.
[Add more information here about other major design decisions ... starting with Windows Mobile, the choice of microSD connector with charger, etc.]
help on how to format text
Turn off "Getting Started"