Wearable Wireless Heart Rate/Activity Monitor
Team:
Shannon onstate
Cody
Casey
Mentor:
Dr. Patrick Chiang
OregonSateUniversity
1
Contents
Contents......
List of Figures and Tables......
1. Project Overview......
1.1 Project Purpose and Motivation......
1.2 Project Requirements and Revisions......
2. Hardware Design......
2.1 Patch-based Flexible ECG Sensor......
2.2 TS1004......
2.3 TPS62730......
2.4 UAF42......
2.5 LM317
3. Software Design......
3.1 Microcontroller Code Architecture......
3.2 Smartphone Application......
4. Results and Discussion......
4.1 Testing......
4. 2 Discussion of Errors......
5. Conclusions and Future Work......
6. Acknowledgements......
7. References......
Appendix A: Schematics......
Battery Regulator......
CC2540......
Filter......
IMU......
Regulator......
ECG Amplfier......
SD Card......
Appendix B: Code......
Microcontroller Sampling Code......
Microcontroller BLE Code......
I2C and IMU Data Processing Code......
Matlab Logcat ECG Data Parsing......
Appendix C: Bill of Materials......
Appendix D: Verification and Other Resources......
List of Figures and Tables
Figure 1……………………3
Figure 2……………………8
Figure 3……………………9
Figure 4…………………...10
Table 1……………………..5
Table 2……………………..9
1. Project Overview
1.1 Project Purpose and Motivation
The market for wearable health technology is robust and increasing rapidly. Reports from the leading electronics industry consultant IHS Electronics and Media show that medical and fitness devices made up the largest percentage of the wearable device market in 2011[5]. The wearable device market gained $8.5 billion of revenue in 2012 and is projected to increase to $30 billion by 2018 [6]. The Consumer Electronic Association supports predictions that this market is growing in their discovery that ownership of wearable fitness devices is increasing, and particularly that ownership of mobile fitness apps increased from 8% to 20% of their survey participants between 2012 and 2013. Their online survey also found that while 75% of participants already own some manner of fitness technology, interest in buying a wearable fitness device within the next year quadrupled from 2012 to a rate of 13% in 2013 [7].
Interestingly, that same study also reported that the majority of users were already in good health and that a primary reason for their use was maintaining their motivation to exercise. This indicates that these devices not only have potential as health trackers, but also as catalysts to forming healthier habits.
The project presented here is an initial prototype for a collaborative university study funded by the USDA investigating the role of technology in youth obesity prevention. The overarching goal was to demonstrate and end-to-end system, showing successful collection of biometric data from a wearable device, analysis and user feedback on these data, and continuous upload of these data to a study management server.
1.2 Project Requirements and Revisions
This project was designed and implemented as part of OSU’s electrical engineering senior design curriculum over the course of this year. Each team participating in the senior design courses devises fifteen engineering requirements they strive to meet with their design. The requirements for this project were as follows:
1.Device adheres to body at least 4 hours during light activity.
2. Device functions for at least 4 hours before requiring battery recharge.
3. Batteries recharge via u-USB in under 2 hours.
4. Device communicates with phone via Bluetooth 4.0.
5.Bluetooth range spans a minimum of 3m.
6. Low battery LED turns red when charge hits 10% ± 5% of its average full charge.
7. IMU measures at least ±1.0G acceleration.
8. Device records IMU data at a min of 33 Hz.
9.Device can measure 30 - 250 bpm.
10. Heart rate calculated within 10% of 20 sec manual pulse check 9 out of 10 times.
11. All major app tasks reachable within 3 clicks.
12. App has <= 8 buttons on main page.
13. App updates HR and activity at least once a minute.
14.Audio alert when HR falls below 55 bpm or above user entered max.
15. Device stores at least 2 hours data on SD card.
Of these requirements, all were satisfied except 7, 8, 9, and 15. A discussion of each of these successes and failures is included in the “Results and Discussion” section.
The initial system was composed of several satellite boards containing the various project blocks connected for purposes of testing. For instance, for the bulk of our development and testing, we used the CC2540DK-MINI keyfob for our ADC, microcontroller, Bluetooth transmission, and LED indicator functions. The original design also did not include any signal filtering after amplification, a change that has been added to the new version. This provided us the platform we needed to test microcontroller and Android code. All of the video demos included in this submission are of this system. Nevertheless, a new revision is currently under development. For ease of reading, we have chosen to include the bill of materials from this design. This design includes the components of the keyfob that were the most relevant to our system.
2. Hardware Design
2.1 Patch-based Flexible ECG Sensor
The design choice of a flexible sensor patch connected directly to the chest was an option that had very limited previous implementations and it made more sense to gather heart rate data directly from the source of the heart rate impulses. The sensor itself is a three-axis ECG sensor, with two inputs for the potential difference in skin voltage and a driven-right leg for common-mode interference reduction.
Figure 1: Three-axis electrocardiograph (ECG) sensor, with positive (top) and negative (bottom) voltage terminals and driven-right leg terminal (center).
The difference in the voltage measured on the skin from the sensor was miniscule, on the range of microvolts, and required a low-power operational amplifier (TS1004) to amplify the signal to optimally use the range of the ADC on the CC2540. The amplification resulted in approximately a 200mV peak-to-peak heart rate signal. There was a generous amount of 60 Hz noise associated with the signal, determined by an FFT in MATLAB, that was skewing the peak detection alogrithm. Because of the 60 Hz noise experienced from the user, the UAF42 design of a 60 Hz notch filter was implemented into the design which drastically reduced the noise that was being experienced from the user/electronics interface.
2.2 TS1004
A large amount of electromagnetic interference (EMI) is often coupled to the patient's body through the skin, where the patient can act as an antenna picking up 60 Hz noise from electrical power lines. The capacitive coupling of the various sources that the body picks up as well as what the system establishes from cables and protection circuitry, help determine the common-mode interference between the ECG sensor and the operational amplifier. The TS1004 is a quad op amp that was used not only to amplify the heart rate signal, but also as a nano-powered active filter to help establish the common-mode to differential mode mismatches in electrode impedances, cable impedances, and onboard protection circuitry [1].
To power the quad rail-to-rail TS1004, it would take any supply voltages in the range of 0.65V to 2.5V with a supply current of 0.6uA per amplifier. This low amount of supply current and operating voltage translates into very long equipment operating times. The size of this quad op amp is also relatively small, 14 pin TSSOP package size, making it easy to place on the PCB.
A problem that occurred for us in the testing phase was that the company went out of business during the build of the project. Fortunately there were extra components that were ordered and it never became a problem.
2.3 TPS62730
The TPS62730 step down converter reduces the 3.3 V regulated battery input voltage to a steady 2.1 V; which was an ample voltage supply for the TS1004 as well as coupling nicely with TI's CC2540Bluetooth low energy solution in terms of reductions in current consumption to support sleep and low power modes. Since Bluetooth is the main current drain of our wireless device, it makes sense to eliminate as much overdraw on current consumption as possible. Normally, connecting the CC2540 to a voltage source would activate the internal LDO’s of the chip and step the operating voltage down to 1.8V where most of the power is lost in the conversion. With the addition of the TPS62730 , the DC/DC regulator steps the battery voltage to 2.1 V when the chip is in active mode and bypasses the supply to the chip and peripherals when the chip is in sleep mode. This reduces on current consumption of the chip during active mode [3].
The TPS62730 features an Ultra Low Power bypass mode with typically 30nA current consumption to support sleep and low power modes of the CC2540 [3]. It has seamless transitions between sleep and power modes which allow it to consume less by controlling the output voltage to the CC2540.
Between the CC2540 and TPS62730 , there is a mechanism that will enable the CC2540 to operate at full battery voltage for millisecond durations during Bluetooth activation, via V_BYPASS. During this operation, the current consumption is drastically reduced. When the TPS62730 , operating in Bypass Mode for Bluetooth receiving, passes a full 3.6V to the CC2540, it saves 34.2% on the average current drawn. This is opposed to supplying the CC2540 directly with a 3.6V supply (DC/DC OFF in Figure 2 below).
Table 1: Percentages of current saved when using the TPS62730 to regulate and switch between different power modes
The TPS62730 will also supply voltage to the amplifier and SD Card via the output VCC. These blocks will require a similar voltage as the CC2540, approximately 2.1V will be ample for operation of all three.
The TPS62730 is a robust regulator that met requirements for a good portion of the components within the project. The six-pin DRY package size allows for it to fit into small areas on a PCB. It is an excellent IC that has provided efficient voltage regulation.
2.4 UAF42
Due to the EMI experienced by the user/electronics interface, there was a sufficient amount of noise that disrupted the functionality of the peak detection algorithm set in place from initial prototypes. The system required a 90% accuracy of counting peaks during operation measured against a manual wrist pulse test. With the addition of the UAF42 the 60 Hz noise was notably reduced, which is expected to support more robust and accurate peak detection.
The documentation that was provided by Burr-Brown Application Bulletin for creating a 60 Hz notch filter out of the UAF42 was greatly helpful [4]. Given that it has tight tolerances, and low-loss capacitors, the UAF42 was extremely suitable for doing away with the noise in the ECG signal. Direct implementation of the circuit diagram provided in the application note for the 60 Hz notch filter made it easy to eliminate nearly all of the 60 Hz noise.
2.5 LM317
For regulating the battery voltage, the LM317 LDO was perfect for its ability to reduce the battery input voltage to a steady 3.3 V. The LM317 has an adjustable output voltage that can be programmed anywhere from 1.2 V to 37 V with output resistors and the ability to supply 1.5 A of load current, which is greater than the Li-Ion battery capacity and discharge rate. Other advantages of choosing this component compared to other LDO's is that it utilizes internal current limiting, thermal shutdown and safe area compensation.
Most of the components were powered by this 3.3 V source, so this fixed output 3.3V LDO regulator turned out to be an ideal solution for voltage regulation. Given that the device was operating on the lower end of the voltage and current capabilities of the LM317, the power dissipation was never a big concern. When power dissipation is of concern, there are internal limitations that will disable the component which will not lead to any further damage of other components.
The small package size, 3/4 terminal DCY (SOT-223), allowed it to fit into almost any areas of the PCB. Thus this was a great IC for efficiently regulating the voltage on the device.
3. Software Design
3.1 Microcontroller Code Architecture
The microcontroller code directs the sampling of sensor data, the formation and updating of Bluetooth Low Energy (BLE) data characteristics, Bluetooth transmission, and writing of data to local SD card storage. As previously mentioned, the SD card functionality and portions of IMU communication have not yet been completed, so the explanation of these portions of the architecture will pertain to their concept rather than their actuality.
The BLE portion of the code (see Appendix B) formats ECG and IMU data into BLE characteristics. The Android application retrieves these data by continuously polling the device. Through various testing and experimenting with notifications and multiple characteristic reads, it was decided that polling one characteristic containing a package of the desired data was the most reliable way to retrieve the desired data. Thus, the BLE code sets up characteristic 5 to contain one counter byte, 8 bytes of ECG data containing the high and low bytes of 4 samples, 4 bytes of accelerometer data, and 4 bytes of gyro data (see Figure). The code is set to sample the data at 33 Hz, and the characteristic is fully updated roughly every 120 ms, so the effective sampling rate seen by the phone is still 33 Hz as required. Since the phone is polling these values, the counter byte was added so the phone can discard any repeat values it finds.
Once enacted the SD Code will write about 4Kb of data to the SD Card every 30ms
It will be parsed with a '**PARSE**' string, for easy data parsing later
This ensures accurate data collection and local storage. Any RTC data will be recorded at an arbitrary point in time because the cc2540 does not support a RTC.
3.2 Smartphone Application
The Smartphone app design was oriented around ease of use. As per the requirements, it was designed so that the user can log in, connect to the sensor, and view there are data within three clicks of their current location in the app. Additionally, the design of the application main page was kept minimal, hence the requirement for a main page with fewer than 8 buttons. To meet these requirements, each page of the application contains three navigational buttons in the top right which allow the user to bring the main page, Bluetooth device selection page, or the data display page into view. These buttons take the form of icons, but they also contain text counterparts in a drop-down list in the case that these icons are not self-explanatory to some users.
On the application main page, the user can enroll or login to a study being maintained on the server. This requires the phone to be able to connect to the internet. They can also enter their desired maximum heart rate limit, and this feature was made independent of server connection so that the user may use the application as an alert device even when they are not uploading data. To pair with the sensors, they hit the Select Bluetooth Sensor button and are directed to a list of available devices as shown in Figure. Upon device selection, the user is automatically redirected to the Data Display page. Before the first data and calculation are computed, the application tells the user it is waiting. After the first computation is performed, the display is updated and will be updated roughly every five seconds as long as the connection with the sensor is maintained. Whenever the user’s heart rate exceeds their entered maximum heart rate limit or falls below 55 bmp, the phone sounds an alarm and a toast pops up at the bottom of the page telling the user what type of heart rate range violation has occurred.
All the heart rate processing occurs on the phone. A peak detection algorithm was implemented based on the first few steps of the Pan-Tompkins algorithm [8], a traditional algorithm used in ECG processing. First, the derivative of the data was computed and squared. Peaks were detected from this signal based thresholds of the peak magnitude and the magnitudes of the rising and falling edges of the peaks. Nearest neighbor elimination was also used, meaning that any peak that was detected within 8 samples of another peak was not counted. A size of 8 samples was chosen for this to be consistent with detecting a rate as high as 250 bpm keeping this calculation in mind:
By the same reasoning, this was also the size of the window chosen for detecting local maxima.
The application stores data it receives from the sensor in local arrays until it is time to process a window. The window size chosen for counting peaks in the heart rate data is 10 seconds. Once peaks are counted in one 10 second window, the window slides by five seconds, and the process is repeated. Once three windows have been computed, heart rate is computed as the average of the two rates with the smallest difference. This was implemented to reduce the effect of false positives and negatives in the peak detection.