Design of a Wearable Physical Activity Monitoring System using Mobile Phones and Accelerometers

Abstract

This paper describes the motivation for, and overarching design of, an open-source hardware and software system to enable population-scale, longitudinal measurement of physical activity and sedentary behavior using common mobile phones. The “Wockets” data collection system permits researchers to collect raw motion data from participants who wear multiple small, comfortable sensors for 24 hours per day, including during sleep, and monitor data collection remotely.

I. Introduction

The impact of physical activity on health is well documented. Physical inactivity, for example, may contribute to the onset of chronic diseases, such as heart disease and diabetes, as well as conditions such as overweight and obesity that may exacerbate a host of health problems. Because of the important relationship between physical activity and health, medical researchers seek better tools for studying how and when people engage in physical activity and/or sedentary behaviors.

Objective activity monitors using accelerometers for measuring activities have been developed in research labs and as commercial products. Typically, subjects are asked to wear a single activity monitor at the hip. The Actigraph GT1M and GT3X [1] activity monitors are widely used by researchers and clinicians. These and similar devices measure two or three-axis acceleration in a band-limited frequency. An analog to digital converter samples the data, typically at 10Hz or above, and these values are then filtered and integrated using proprietary algorithms over a specific time period (epoch), usually 1 s or 1 min. This “activity count” can then mapped to energy expenditure. One limitation of this approach is that raw acceleration data are often not saved due to memory limitations on the device. Raw data contain additional information that might be used to discriminate between activity types or to more accurately estimate energy expenditure [2].

Within ubiquitous and wearable computing, much work has been proposed to detect activity type from wearable accelerometers using features computed from the raw accelerometer signal (versus summarized activity counts output by most motion monitors) (e.g., [3–6]). The raw signal may be useful for computing energy expenditure [2, 7]. New commercial monitors, such as the GT3X+ [1] (see Fig. 1) can collect multiple days of raw data for such analyses. Moreover, some research suggests that activity type and activity energy expenditure estimates may be improved by using multiple sensors simultaneously [2].

Figure 1.

(Left) An Actigraph GT3X+ (red) in comparison to a Wocket. (Right) Components in a Wocket “kit” include 4 Wockets, a charger, and 4 custom moisture-wicking bands.

II. Motivation and Design Goals

We aim to avoid some of the known problems with activity monitors, such as missing data, sampling bias, and study cost, by creating a technology that can be worn for many weeks or months for 24 hours a day on multiple parts of the body and collect raw acceleration data. Our design goals are as follows:

• Minimize the cost of the system technology by exploiting the computational and storage capabilities of standard (i.e. unmodified) mobile phones participants will own already.

• Allow the collection and analysis of raw data as well as summary “count” data, eventually for real-time activity type detection on the phone and later analysis of the raw data by researchers.

• Create a technology that can be worn continuously and with minimal participant burden, including during sleep, at multiple locations on the body.

• Allow remote administration of long-term studies, where the integrity of the data can be checked without requiring participant contact.

III. Design Process

Prior to developing our prototype system, we recruited 20 non-technical subjects and used participatory design exercises to elicit information about the proposed physical activity monitoring hardware and software technology. Those sessions led to the following specific design criteria for the system (among others not discussed here):

• Sensors should be thin, wearable underneath clothing, and aesthetically pleasing or aesthetically neutral.

• The system (including the mobile phone) should operate on a single charge per day and the plug for the charger should not require hand strength or agility.

• The sensors should be easy to use, especially the connectors for charging the sensors, and robust to problems such as exposure to water.

• The system should not rely on using the phone’s internal accelerometer for measuring body movement because phones are too-often carried in bags or put down; sensors for measuring body movement should be fixed to the body under clothing; the system should work if the phone is not being carried but is only within earshot.

While there are many examples of commercial and research wearable accelerometers, Wockets are thin enough to wear under clothing, able to operate for an entire day on one charge, able to send raw data from multiple sensors simultaneously to a mobile phone, waterproof and easy to use by non-technical individuals, small and comfortable enough to be worn 24 hours per day for weeks at a time, and sufficiently inexpensive so that large numbers might be feasible for use in large cohort studies.

IV. System Overview and Tradeoffs

Components of the Wockets System include 4 Wocket sensors (2 worn, 2 charging at all times), a charger, moisture wicking bands, the mobile phone running custom software, and a server where data are aggregated and available for remote review (see Fig. 1). Although we have used up to five Wockets simultaneously with the same phone in laboratory experiments, to minimize participant burden the typical use scenario would consist of using two sensors at a time, where one measures upper-body motion and the other measures lower-body motion. In that case, participants are asked to put on two sensors each morning after bathing, one on the upper body (typically the wrist or upper arm) and one on the lower body (typically the ankle or the pocket). They wear those sensors until the next morning, when they swap them with the other two sensors that have been left in the charging unit. Participants can use their phone normally.

The system switches between two modes. In continuous mode, Wockets stream real-time 40Hz, 3-axis (10 bit/axis) accelerometer data to the phone, permitting low-latency processing and activity-based feedback if desired. In that mode, the Wocket will transmit for ≈8.3 hours and the phone (with display off and no other applications running) will receive data for ≈10 hours. Because this performance is insufficient for practical deployments, Wockets also have a power-efficient mode, where raw accelerometer data are cached for 1 min and then transmitted to the phone in a single burst.

The majority of the time, participants will have the phone within earshot, which is typically close enough for Bluetooth radio communication, and therefore raw data will be collected. However, there are occasions when the phone may not be within radio range of the Wockets for short and long periods of time. A common scenario is that during sleep, if a person rolls on top of a sensor, the body can block the Bluetooth transmission until the person moves again. One option to handle such cases would be to add memory to the Wocket, with an undesirable tradeoff of making the devices larger and more costly. We therefore chose to optimize on size and cost and instead programmed the Wocket to compute a motion summary value each minute that is transmitted to the phone. The phone must acknowledge receipt of these values, otherwise the values are stored in the Wocket’s microprocessor memory (16KB). In this configuration, summary data are received for each minute where raw data are lost, for up to 16 hours in a day. Beyond that time, some data are lost.

V. System Components

Each component of the system has been optimized for size and cost, while still permitting the sensors to be produced in small-scale quantities.

A. Wocket Hardware

The size and cost of the Wocket is minimized by offloading nearly all processing and storage to the phone. The hardware consists of the following components:

Function	Component	Cost (qty 100)
Processor	ATMEGA1284P	4.61
Communication	RN-41	20.25
Accelerometer	MMA7331LCR1	1.58
Power Regulator	TPS76930	0.76
Capacitor Bank	47uF SMT 0805 × 2	1.43
Battery Charger	BQ24083	2.33
Battery	3.7V 240mAh with PCB	5.99
PCB	N/A	3.57
Misc	30 SMT components	1.67
Assembly	Incl. functional test & packaging	21.00
Total		$63.19

Although other radio technologies are less costly and more efficient than Bluetooth, one of our design goals is to operate with unmodified mobile phones, and the only viable option at this time is Bluetooth.

We chose the RN-41 Bluetooth module based on proven functionality, reduced device cost, and turnkey compliance. Prior experience with the device’s interface to Bluetooth’s SPP protocol highlighted the reliability advantage of distinct control and data modes for controlling resource constrained microcontrollers. The choice of a radio module allows a low cost, double-sided printed circuit board (disconnected ground plane) with little impact on RF performance. Finally the RN-41 has Bluetooth SIG and regulatory approvals. Bluetooth SIG certification promises reliable end-user performance and device interoperability. FCC and ETSI, radiated energy and electromagnetic immunity testing document device safety for subject informed consent and IRB risk analysis.

The Atmega1284P microcontroller was selected based on meeting an application-driven list of requirements: large RAM size for data buffering, chip-scale package size, moderate cost, and low-cost development chain and in-circuit programmer to encourage community support.

Power management component choice was straightforward. The capacitor bank was experimentally sized to prevent data artifacts from radio activity or duty-cycling. The battery size was selected to minimize thickness and match the size of the rest of the sensor with the additional safety requirement of integrated over/under voltage and over-current cutoff. In the current version of the Wocket, we use a 240 mAh battery.

Mini-USB connectors add bulk and cost, and micro-USB connectors were found in an early prototype to easy snap off and require substantial hand dexterity. To simplify the physical charging interface, the Wocket uses PCB edge fingers shaped in a male microSD card form factor.

B. Charging Hardware

The PCD edge interconnect solution requires a custom-built charger with female microSD charging ports as part of the kit. This represents a compromise on system cost, but it results in a charging scheme that requires little physical dexterity, precision, and strength to use effectively. The interconnect is also thin and facilitates waterproofing of the sensor without adding bulk, as described shortly. The custom charger (see Fig 1b) holds two Wockets and will fully charge both in <3.5 hours. The power inlet is a mini-USB connector allowing use of commodity phone chargers or a PC port. The charger includes charge status indication and current limiting at a total cost of $25.59.

C. Wocket Encapsulation

The shape of the Wocket, in particular the connector, makes it possible to use two thin, inexpensive encapsulation techniques. To fully waterproof sensors, they are encapsulated in a semi-rigid molded enclosure. After testing a variety of materials, a hot melt adhesive (3M 3750 AE) was found to be sufficient. Using molds machine-routed from Teflon R PTFE Sheet and a hot glue gun, a single individual can encase approximately 8 sensors per hour without any other specialized tools. The resulting housing could be produced at small and large quantities at low cost and is thin and completely waterproof. The curved shape of the sensor also provides a reference point with respect to proper sensor orientation against the skin (ensuring the radio is away from the skin to maximize transmission range), and the connector shape provides reference point to use for orienting the sensor on each limb and in the bands.

D. Bands

Comfort is critical to enabling long-term wearability of the sensors. We iteratively tested stretchable textiles for the sensor bands, selecting a .5mm neoprene. Small details, such as location of seams, proved important in ensuring that sensors feel soft on the skin. At the same time, the bands must be simple to mass produce. A single piece design made of neoprene eases cutting and assembly process. Fabric cutting is executed with scissors, laser-cut or die-cut. Band design does not require ring or clip hardware. An adaptable system with thin hook and loop fastener fits multiple sizes, simplifying production. Fig. 1a shows a band on the wrist. The sensor can only be inserted in the band one way, and the band provides a visual hint at the desired orientation on the body. At this time, in quantities of 100, each band costs $1.50 in materials and $3.00 to produce locally. A pocket version of the band is used to protect and stabilize pocket-worn Wockets.

E. Software and Firmware

The Wocket firmware is interrupt driven to minimize the time the microcontroller holds a spin-lock (e.g. between samples). Both the continuous and power-efficient modes allow full-duplex communication between the Wocket (that acts as a slave) and a master device (such as a phone). The Wockets transmission leverages Bluetooth error handling and flow control and therefore does not guarantee delivery.

Data and control packets are of variable length. A packet consists of a header byte followed by a variable length payload. The header consists of one synchronization bit for alignment if a loss occurs, two bits that specify the type of the packet (compressed, uncompressed, control and response packets), and a 5 bit opcode field only for command and response packets. Payload bytes reserve their first bit for synchronization. Data packets are delivered in two types: raw acceleration packets that can be sampled at a maximum of 90 Hz and integrated summary counts transmitted 1/min. Command packets enable remote devices to retrieve or set a number of parameters on the Wocket such as sampling rate, number of sampled packets, battery level, calibration values etc.

The Wocket has limited RAM capacity allowing for storage of approximately 1.5 min of raw data at 40Hz in addition to 16 hours of integrated summary data. As such, if a Wocket remains disconnected for a period exceeding 1.5 minutes, raw circular data buffers overflow and raw data loss occurs. Summary counts continue to be stored and upon successful connection summary data are transmitted in batches of 10 counts every minute along with any raw data. Deletion of transmitted summary counts does not occur until the receiving end acknowledges the reception of the counts using a simplified window-based flow control scheme similar to TCP flow control.

A Wocket runs for a full day with a 240 mAh battery and without depleting a standard phone’s battery. The Wockets software achieves this by putting both the Wocket and the phone in their lowest power states without disrupting normal use of the phone. The Wockets and phone are then synchronized to connect regularly every minute for approximately 10 s to transmit buffered data from the Wocket before it overflows its internal buffers.

The data arriving from multiple Wockets are aligned within a 1 s window on the phone. In continuous mode, data are assumed to be largely in sync, and a minor correction is applied based on the expected sampling rate of each Wocket. In power-efficient mode, a successful connection serves as a temporal reference point for both the phone and the Wocket. Upon successful connection, a Wocket marks its last sampled packet as the last sample to be transmitted in the current batch. The phone uses its connection time to timestamp the last data packet in a batch. Earlier packets are then spaced out evenly between the current connection time and the last connection time if no overflow occurred. If an overflow occurred, the packets are spaced backwards based on the expected sampling rate for the Wocket.

F. User Interface

Each day participants wearing the Wockets system must swap two sensors with charged sensors. A series of prompts on the phone guides the user through the procedure. The Wockets are color coded and labeled to facilitate this process. Wockets software can be remotely updated throughout a research study. Applications currently in use in the field validation of the system include a status monitoring interface and an experience sampling application for self-report of physical activity.

G. Remote Monitoring Website

The Wockets software uses the phone’s data network to send motion summary data to a remote server on an hourly basis. This permits remote compliance monitoring for each participant. Custom software permits the summary data to be viewed hourly, as well as meta-data such as swap times and self-annotations of activity. Server tools are being developed to process the incoming data to detect, in real-time, missing data or unusual data, and to send timely feedback to the participants using the phone to reinforce proper compliance. Participants are asked to plug in the mobile phone each night to charge the phone and to permit raw data from the past 24 hours to be uploaded to a secure server. After data are successfully uploaded they can be deleted from the phones. This permits long-term operation and remote monitoring of studies that would require significant staff time using existing raw data collection systems that typically run out of memory after in days or weeks.

VI. Lab Testing

We ran experiments to evaluate the power consumption of the Wockets System in both continuous and power-efficient transmission modes. The power measurements were taken by measuring the voltage drop across a resistor during phone use. When the Wocket is not connected to the phone, the radio is continuously awaiting a connection and therefore the current consumption is a relatively high 11.88 mAmps. When the Wocket is connected and transmits continuously, the power consumption registered 26.63 mAmps on average. With a 240 mAmps battery the Wocket operates for approximately 8.3 hours. In power-efficient mode, the Wocket shuts down its radio for approximately 45 s, during which the power consumption is dramatically reduced. The average power consumption for the Wocket in power-efficient mode is 6.18 mA, lower than a Wocket waiting for connections. The lifetime of a 240 mAh battery exceeds 32 hours. For the phone, the baseline power consumption with the screen off is 10.86 mA. With the screen off and the Wockets connected, the power consumption jumps to 109.42 mA. For an 1100 mAh standard battery, the phone would operate for approximately 10 hours. Once the Wockets are configured to run in power-efficient mode, the consumption drops as low as 31.5 mA that allows the phone to run for over 34 hours (if no other functionality is being used).

VII. Limitations

At this time, we have implemented the Wockets system for Windows Mobile (6.x version) phones. We are porting the technology to Android mobile phones. The cost of the system, including parts and materials for the custom housing (but not including labor of assembly) is ≈$297 per Wocket kit in quantities of 100. This price, while substantially less than the ≈$350 for a commercial GT3X+, could be reduced with large-scale production.

VIII. Future Work

The Wockets system is open source. Additional information about the design of the technology and future plans are available on the project website: http://web.mit.edu/wockets. Current plans include integration of real-time activity type detection to the system, based on prior work [8], and enhancing the remote compliance monitoring tools for large-scale deployments.