24/7 HR Sampling

So I checked my fit files in the MONITOR folder for the last three mornings before syncing. With FW 3.20/2.30 it seems that the longest period between HR readings (during sleep, probably also during daytime) is 15 minutes. This for my sake would be ok.

However there are always 2-6 consecutive readings that have the same HR value. Of course it could be that my HR is not moving around that much while sleeping, though I would expect to see a little more variance to it. It can't be just coincidence on three nights, can it? That's why the HR graphs look so flatlined all the time. Maybe during sync those consecutive identical valus even get discarded.

A possibility could be, that Garmin updated their "smoothing" algorythms as of WHR 2.30 and that those algorythms also affect 24/7 HR. IF this is the case I would consider this wrong. While smoothing seems ok for running, for 24/7 HR I would like to see even a difference of 1 bpm.

Whether or not my resting HR is one bpm lower or higher is crucial for my training to win the olympics next year ;) Well, I just want to see it!


I'm trying to get my hands on some monitor fit files from the previous firmware to compare the frequency and distribution of HR.

This is the sort of granularity you get with a Fitbit trace. Overnight HR definitely varies by a few BPM.

I wonder if the watch was originally programmed to measure heart rate every 15 minutes and then record the result, also every 15 minutes. Then with the update they changed the rate of measuring, but not the rate of recording. So it just records the previously measured rate multiple times. That would explain the multiple identical rates in the file (which I also have).

Does not make a lot of sense to "wake up" the optical and then not record a value unless it had somehow determined it as being invalid.

On that, when I manually look at my resting HR in LPM the initial value is sometimes "wrong" based on my expectation of would expect to see - e.g. under 50 not 73 (as it was right now) etc etc Sometimes it seems to "stick" at that "wrong" value for a bit and then come down again.

philippe - when you see those consecutive same values - are they believable?

After a few button presses it has come down to 45 so it does seem to need a bit of time to "settle".

Overnight I saw it gave me a 35 RHR which historically is what I always have used as my RHR. As such that is at least "correct"!

I wonder if the watch was originally programmed to measure heart rate every 15 minutes and then record the result, also every 15 minutes. Then with the update they changed the rate of measuring, but not the rate of recording. So it just records the previously measured rate multiple times. That would explain the multiple identical rates in the file (which I also have).

Doesn't make sense, but of course this is another theory why suddenly there are so many consecutive HR numbers.

philippe - when you see those consecutive same values - are they believable?

After a few button presses it has come down to 45 so it does seem to need a bit of time to "settle".

Overnight I saw it gave me a 35 RHR which historically is what I always have used as my RHR. As such that is at least "correct"!

Before I had the FR235 I used to measure RHR after waking up with my iPhone camera and usually was somewhere around 54.

The lowest reading I got with the FR235 was 42, but the average was something around 50. When I look at the fit files I extracted, the average of overnight measurements is above 60. That might be possible, due to movement or maybe due to stress (as from a run or the little itching I feel in my throat). However there is hardly any reading below 55, only once I found a 48 for two consecutive readings.

So it's hard to say, the readings might not be wrong, I don't think they are. I just think there is some kind of smoothing or alike going on. Just by looking at the graphs from before 3.20/2.30 there was a lot more variance to the HR readings.

So I just found out, that in GC Webservice it is possible to export all the fitfiles for any selected day! I went ahead and exported some days before the 3.20 update. There can be a lot of files in the downloaded zip. My guess is, that there is one fit file for each sync. So I converted them using the FitToCSV again, and then found one of the earlier ones that was biggest, that must be the one containing sleeptime readings.

Unfortunately I still haven't figured out how to match the timestap_16 to a correct time of day, but at least it's always possible to get reading frequency from that.

So, compared to after 3.20 update I found the following for FW3.13. Note that this is all just my interpretation just by looking at the frequency and HR numbers in those files!

a) The maximum time difference between readings is also 15 minutes
b) There are more readings with a faster frequency, ranging somewhere between 1 and 14 minutes. Albeit not that many, but still more than in 3.20.
c) There are less consecutive readings with the same HR number. If there are, they are usually only two readings with the same value, not up to 6 as in 3.20.
d) The average HR looks about the same. Though I did not really find those readings below 50 and hence I'm not sure if I really got the right fit files that are supposed to have my sleeping HR data.


As said d), I'm not 100% sure that I picked the right files to analyze sleep HR data. If only someone would figure out how to correctly match the timestamp_16 value to correct local (or UTF) time.

However I think we can say that the frequency has not been decreased. Or rather "recording" frequency (as in writing a data record) has not been decreased compared to 3.13, i.e. there's still a data record being written at least every 15 minutes. If every of those records come from "real-time" HR data I don't know.

However, my first impressions of looking at pre-3.20 data rather supports my suspicion, that something has happened. We already have more than one theory for why we see so many consecutive HR numbers of the same value:
- smoothing is being applied
- reading frequency has been decreased while recording frequency is still the same

Well, we could speculate much more of what that might be... but I think everyone agrees, that something HAS been changed.

To convert the timestamp_16 to a real date add the difference between one of the timestamp fields to the _16 field (if the _16 field is 222 and the full timestamp is 55345, then you'd add 55000 to 222 for a number of 55222). After that if you divide that number by 86400, then add Date(1989, 12, 31), finally add 4/24 (where 4 is how many hours you are from Greenwich mean time) and format it like mm/dd/yyyy h:mm. I believe that will get you the time you are looking for.

To convert the timestamp_16 to a real date add the difference between one of the timestamp fields to the _16 field (if the _16 field is 222 and the full timestamp is 55345, then you'd add 55000 to 222 for a number of 55222). After that if you divide that number by 86400, then add Date(1989, 12, 31), finally add 4/24 (where 4 is how many hours you are from Greenwich mean time) and format it like mm/dd/yyyy h:mm. I believe that will get you the time you are looking for.

Thanks! That worked pretty well!


There's just one little thing. My last sync was at 23:00, so when I checked this morning, the watch had created two fitfiles, where the first has the last change date set to midnight, the other one to when I copied it from the watch. So at midnight, a new file is being created.

I looked at the latter of the files, as I was interested in the "sleeping" data. Here are the first few lines when filtered for "local_timestamp" and "heart_rate" in column I.

The first line gives me the timestamp I added to the timestamp_16 values.

Now the next few lines seem a little strange. I suppose they are carried over from the previous day (before midnight), at least from my GMT+1 perspective. To get a reasonable local time that makes sense, instead of adding (1/24) for my GMT+1 zone, I substracted (17/24). So I suppose the watch starts a new file at GMT 00:00, but because I'm already at 01:00 then, I do get some values from "yesterday" from my perspective. Then again it's funny, that the timestamp_16 doesn't just start at GMT midnight.


After that (where timestamp_16 is 488) everything is as expected and works perfectly with your formula.

[table="width: 500"]
[tr]
[td]Field 1[/td]
[td]Value 1[/td]
[td]=((timestamp+timestamp_16)/86400)+DATE(1989;12;31)+(1/24)[/td]
[/tr]
[tr]
[td]timestamp [/td]
[td]819327600[/td]
[td][/td]
[/tr]
[tr]
[td]timestamp_16 [/td]
[td]62664[/td]
[td]18.12.2015 01:24:24[/td]
[/tr]
[tr]
[td]timestamp_16 [/td]
[td]63324[/td]
[td]18.12.2015 01:35:24[/td]
[/tr]
[tr]
[td]timestamp_16 [/td]
[td]64224 [/td]
[td]18.12.2015 01:50:24[/td]
[/tr]
[tr]
[td]timestamp_16 [/td]
[td]65124[/td]
[td]18.12.2015 02:05:24[/td]
[/tr]
[tr]
[td]timestamp_16 [/td]
[td]488[/td]
[td]18.12.2015 00:08:08[/td]
[/tr]
[tr]
[td]timestamp_16 [/td]
[td]1388[/td]
[td]18.12.2015 00:23:08[/td]
[/tr]
[/table]

Ok, one change on the formula you used. It's not really timestamp+timestamp_16. Using your data from below it would be 819300000+62664. You just have to 'fill' the extra values based on the full timestamp. If you did string manipulation you could concatenate 8193 to 62664, but I figure it's simpler to treat it as a number and do simple math in Excel.