was successfully added to your cart.

Fitbit API and High Resolution Heart Rate Data

By June 14, 2015Devices

After trying the Jawbone UP3 for a few days and quickly returning it due to multiple limitations, I’m now testing a Fitbit Charge HR. I’m mostly interested in heart rate data, so I had to to update my code to OAuth 2.0. Fortunately orcasgit/python-fitbit is completely on top of things and their new gather_keys_oauth2.py works perfectly. All I had to do was to set my callback URL in the ‘manage my apps’ tab at dev.fitbit.com to http://127.0.0.1:8080/, and then gather_keys_oauth2.py returned my OAuth 2.0 access and refresh tokens. I dropped those into a text file (‘config.ini’) and used them to set up my client:

There was a small issue with orcasgit/python-fitbit, which had to do with the new ‘1sec’ detail level for the heart rate data, but I made that change and the merge is pending at github. Now, the data are flowing,

I was expecting 1 sec resolution data (based on the ‘1sec’ parameter), but the timestamps are actually spaced 5 to 15 seconds apart. It would not surprise me if ‘1sec’ is a request rather than a guaranteed minimal temporal resolution; perhaps the device does some kind of (sensible) compression and concatenates runs of identical rates, e.g. if your heart rate is precisely 59 bpm for a while, it is probably silly to continuously report a sequence of {“value”: 59}, over and over again. If this is true, are we (basically) dealing with a lossless run length encoded (RLE) data stream? Any ideas? It’s not a simple RLE, as this data 4-tuple demonstrates: {“value”: 60, “time”: “00:05:00”}, {“value”: 60, “time”: “00:05:15”}, {“value”: 60, “time”: “00:05:30”}, {“value”: 62, “time”: “00:05:40”}. If it were a simple RLE-ish encoding, then this sequence would be {“value”: 60, “time”: “00:05:00”}, {“value”: 62, “time”: “00:05:40”}, with the recipient code then assuming 40 seconds of 60 +/- 0.5 bpm or something similar. My guess right now is RLE modified to provide at least one datapoint every 15 seconds, and updating more quickly when something is changing, yielding the observed {“value”: 60, “time”: “00:05:00”}, {“value”: 60, “time”: “00:05:15”}, {“value”: 60, “time”: “00:05:30”}, {“value”: 62, “time”: “00:05:40”}.

8 Comments

Leave a Reply