Heart Spark Tech Details
This document is for owners of the Heart Spark Logging Beta who want to know all the nitty gritty details of how the device works.
Table of Contents:
- Real Time Clock, the upper right chip. An RTC keeps track of the date and time independently of the microcontroller. This info is logged to the EEPROM along with the heart data. A real time clock is *usually* operated from a power supply, with a battery backup to keep it running when the power goes down. In this case, the Heart Spark Logging is itself operated from a small battery, and it has an even tinier “battery” for when the main battery is not present. More specifically, I have placed some large caps on the board. See “Battery Life” below for some discussion of the implication of this.
- EEPROM, the upper right chip. The EEPROM is where the data is stored. I have used a 512Kbit EEPROM, which is enough to store 64,000 data points. Due to some overhead (storing the date every so often and stuff like that), it can actually only store a maximum of 61831 data points. Currently the only mode is to store the Heart Rate (BPM) of every single heart beat. If your heart beats at about the same speed as mine, this is about 14 hours of data.
- FTDI. On the back near the bottom of the Heart Spark Logging are 6 header pins, these are the FTDI headers. FTDI is “future technology devices international”, a small company that makes chips for “converting legacy peripherals to Universal Serial Bus (USB)”. The legacy peripheral in this case is UART, a serial protocol widely spoken by current microcontrollers, which are as a class much to small to properly implement USB. Anyway, by hooking an FTDI cable up to the headers, you’ll be able to open a serial port (“COM1″ on windows, /dev/cu-usbserial-A600e0nf on MacOS-X, similar on most linux systems) on your computer to talk with the microcontroller on the Heart Spark Logging.
- the rest of the hardware is similar to that on the regular Heart Spark: an ATMEGA168 microcontroller from Atmel, a polar heart-rate receiver (listens at 5kHz for the chest strap), a CR2032 coin cell holder, 6 LEDs, and a dual-DIP switch for mode selection.
Heart Spark Battery Life
Testing shows that battery life is now about 24 hours of data capture and logging. However, battery life is substantially influenced by mode, some flashing modes consume more energy, while others require more current draw.
Additionally, my experience is that it’s difficult to get the full 24h all in one go. Coin cells are not designed for rapid depletion, they are designed for incredible small loads spread over years (think of your typical watch). Heart Spark drains the coin cell much faster than it’s designed for, and one side effect of this can be that after about 15 hours of use, a coin cell will appear to be dead, while it really isn’t. If you let the coin cell rest for an hour outside the Heart Spark, it’s possible to get another 6 or 7 hours from it. And again resting it will typically get an hour or two more again.
Another issue to consider is temperature. I’ve found that these coin cells are really adverse to cold temperatures – just a minute or two outside in ~0C (32F) temperatures causes the Heart Spark to go dark. And, recovery is often slow, with many “false starts” during the period where the battery is almost but not quite up to temperature. For this reason it’s best to place the Heart Spark inside your shirt when stepping outside in cold weather.
Finally, regarding the “battery backup” on the Real Time Clock. I did some testing, and the caps provide about 1 minute of operating power for the RTC, and about 20 minutes of holding power. What this means is: you set the clock by hooking the HS up to the Processing application. After you remove the HS from the computer, you have about 1 minute in which to insert a battery, before the RTC will stop keeping time. If you take up to 20 minutes, what will happen is the clock will read slow by that many minutes (minus one). If you take more than 20 minutes, the clock will actually loose all it’s data and the date inside the HS will become random. Note that you get a similar amount of time if you switch batteries – this is more important since it’s easier to drain the RTC battery without noticing.
Using the Software
The Heart Spark Logging software is called Heart Logger. It’s a JAVA application written in processing, the “open source programming language and environment for people who want to create images, animations, and interactions.” I actually found it very difficult to do scatter plot stuff in processing, so I gave up trying. But I did succeed in getting processing to do the heavy lifting of talking to the Heart Spark, parsing the data, and formatting it into csv for logging to a file. Work flow is basically:
- Launch the software
- Change the file name to something meaningful (typically I put some details of what I was doing during the data collection)
- Plug the FTDI cable into the Heart Spark Logging and then into the computer
- Click “Open Serial Port”, see version number
- Click “Grab and Log Data”, it will tell you the number of pages of data to be retrieved, and then you’ll see the data in red flash by. If the Heart Spark Logging is completely full, there will be 511 pages, and it will take almost exactly 2 minutes to retrieve it all
- If for some reason there is a problem and it doesn’t get all the data you think there should be, you can click “Grab ALL Data”, which will retrieve 511 pages regardless of how many the HS thinks are new. You’ll you to manually inspect it later to determine what’s actually useful, of course.
- Click “Quit” to close the program
Using the Firmware
The software talks to the Heart Spark firmware, which is written in Arduino. There really isn’t much to say here, since the firmware is not supposed to be used directly by the user. You can use the Arduino IDE (or any serial communication program, such a HyperTerm on windows) to talk directly to the Heart Spark firmware. The protocol is very short. Some useful commands:
- ‘c’ toggles “chatter mode”, which is on by default – the Heart Spark is naturally rather noisy, talking all the time about what’s going on
- ‘v’ transmit the version string
- ‘p’ transmit the write-page counter
- ‘l’ toggle logging
- ‘P’ reset write-page number to 1
- ‘d’ transmit current RTC date
- ‘D’ set date – must follow up with properly formatted date string
- ‘t’ test EEPROM, transmit results of page tested
- ‘*’ transmit page of data, then increment read-page counter
- ‘r’ reset read-page counter to 1
It’s primitive, but it gets the job done. Note that ‘P’ is very dangerous because it will cause new data to start overwriting pages from the very beginning.
- Inside the Heart Spark is the EEPROM (see hardware above). The EEPROM has fundamental physical units of data called pages that are 128 bytes in size. Because of the way the EEPROM works, it’s very convenient to work in pages as the fundamental unit of data, so the Heart Spark Logging has page-based data storage. Each page consists of a small header which contains a header map number, the date and time the page was first created, and then all of the heartrate data in BPM, one byte for each beat. This forces your heart rate to be between 0-255 BPM, but that’s a pretty reasonable range anyway. Pages are written to the EEPROM when they are full, which takes between 1-2 minutes depending on your heartrate. So at any given time, taking the battery out may cause up to 2 minutes of data loss. This is not a big deal, but it’s worth remembering if you’re super eager to see data for what just happened.
- The software grabs these pages, and then expands them out into fully time-stamped csv data. It exploits the clever fact that BPM data is actually implicitly time data as well. 1/BPM = minutes elapsed since last beat. Every page, the error accumulating from all that adding is removed by resyncing with the new timestamp on that page. Minutes is set to zero at the time given by the first page of data. Also, the software calculates the full unix epoch for each moment, this value ensures that should you wish to stuff all of your data into a gigantic database, everything ends up with a unique and meaningful x-axis value. You’d be able to do things like pull out the data associated with 6-7pm on Mondays. The format in the csv:
- unix epoch
- heart rate (BPM)
- once every page, various strings corresponding to the real date/time, this is super handy for human inspection
Here is a recent data file with 3 pages of data: HeartData_2011Jan13.txt. I renamed it from .csv so that your browser will open it directly (rather than requesting to save it to file). The thing to look at is the last value on the shorter rows – that’s the BPM of that heart beat. This file start in the high 60 low 70s, but the third page has some 90s in it.
Plotting the Data
I’ve created an Asymptote script which will accept the csv files the software generates, a few parameters, and output a very pretty PDF of the data. Note that this script is not the only way – you can use any software that you desire, including spreadsheet software such as Excel or LibreOffice. The Asymptote script should be run using the shell script, and passing in command line arguments. You can read about the details of this in the readme file, which displays automatically on the github page.