Fitbit API and High Resolution Heart Rate Data

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 works perfectly. All I had to do was to set my callback URL in the ‘manage my apps’ tab at to, and then 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 thoughts on “Fitbit API and High Resolution Heart Rate Data”

    1. I have extensively examined our Fitbit heart rate data. Sometimes the time difference between two consecutive and equal heart rate records is not equal to 15 seconds.
      Do you have any other ideas what could be a reason for this timestamp inconsistency?

      Thank you!

  1. I don’t know why but my stands still with “Bus STARTED” forever.
    What parameters do you call it with? Client (Consumer) Key and the Client (Consumer) Secret-is this correct? Are there any other precautions to be done?


  2. I managed. I called it in an SSH-remote session, so it was not able to open the browser 😉
    BUT: I followed your steps with the script only for heart rate, but I get some strange errors
    Traceback (most recent call last):
    File “”, line 12, in
    intradayH = authd_client.intraday_time_series(‘activities/heart’, base_date = ‘2015-06-23’, detail_level = ‘1min’, start_time = None, end_time = None)
    File “/usr/local/lib/python2.7/dist-packages/fitbit-0.1.3-py2.7.egg/fitbit/”, line 389, in intraday_time_series
    return self.make_request(url)
    File “/usr/local/lib/python2.7/dist-packages/fitbit-0.1.3-py2.7.egg/fitbit/”, line 201, in make_request
    response = self.client.make_request(*args, **kwargs)
    File “/usr/local/lib/python2.7/dist-packages/fitbit-0.1.3-py2.7.egg/fitbit/”, line 96, in make_request
    raise HTTPBadRequest(response)
    fitbit.exceptions.HTTPBadRequest: Resource owner is required

    Do you have any idea, why this happens?

Leave a Reply

Your email address will not be published. Required fields are marked *