Welcome Guest,Register Now
Log In

ANT Forum

Welcome guest, please Login or Register

   

Durations for cumulative monitoring events (steps)

Rank

Total Posts: 2

Joined 2016-09-01

PM

I have one minor question. In the FIT File Types Description, Rev 2.1 section 15.2, the storage of accumulated values time ranges is described as the difference from the previous message.

This is specifically listed in bold in section 15.5.1:
"As a result, a starting point shall always be logged."

It is also recommended to log starting points to narrow the duration for monitoring reports, in section 15.5.2:
"This loss of resolution can be prevented by recording a starting reference point as shown in Figure 15-6."


The reason I bring these points up is that neither the sample monitoring file included in the SDK, nor the files exported by Garmin Connect from my Vivosmart HR, contain these reference points.

I fully expect I'll have to kludge it by making assumptions directly against the specification ("no assumptions about the message frequency should be made"), but do you have any advice about which ones?

I believe my device in particular always resets steps at midnight, always switches files then, and does store initial values if non-zero when it switches files. In addition, I suspect the actual interval can be traced back not to the matching activity type but the previous steps report.

Tracing the time back to monitoring events in general is not the right way to go, as I frequently have long intervals between step reports with more frequent heart rate reports between.      
RankRankRank

Total Posts: 68

Joined 0

PM

The interval can be calculated from the time between the message and the last message containing an earlier timestamp and activity type.

If the device logs a Monitoring message every time the activity type changes then your statement:
I suspect the actual interval can be traced back not to the matching activity type but the previous steps report
is correct, this behaviour, however, is not guaranteed.

If the device logs all activity types in an interval into a block as is highlighted in Figure 15-4 then the interval must be calculated by reverse searching through the file for the last message containing a different timestamp and an activity type.

Cheers      
Rank

Total Posts: 2

Joined 2016-09-01

PM

Without that little assumption I have files that count hundreds of steps over intervals longer than ten hours. I can live with it being potentially a little inaccurate as long as I get the counts transferred reliably.

A closer inspection of a day split into remarkably many files shows some files do have a reference point, immediately after monitoring_info and with duration_min set (indicating a summary). That at least means I shouldn't have to worry about the steps not starting at zero, if they're consistent. So the starting points for the counts is zero unless the file starts with summary reports.

My biggest discrepancy between Garmin Connect and Google Fit now is a day when I updated the firmware of the VivoSmart HR, and Garmin Connect discarded the statistics from the files before the update. I reckon Garmin Connect trusted the duration_min field, which went back to midnight rather than boot time (I regard this to be a firmware bug), and therefore overwrote the morning's data. In addition, the time on the watch was reset causing two files around the firmware update itself to end up at 2016-01-01. This caused a combined loss of 1158 steps that day in Garmin Connect, so what I thought was a large error in my parsing turned out to be more correct in Google Fit.

Thanks for your help!