FIT LapMessages Not Aligning to actual Laps

I'm trying to create a FIT file and finding some issues in getting the LAP messages to align to actual user presses of the LAP button.

I tried using my own Garmin whereby I just press the LAP Button at like 11s/10s/10s intervals and then loading it into GC (and other web sites) but found out that the Markers (record messages) are not aligning to the workout.

See the below (FIT from Garmin Fenix uploaded to GC and then re=downloaded as TCX file since FIT is binary)

I fully expect that LAP1 should have 11 recordMessages, but it contains 12 (11.2sec - so perhaps it's OK since it's just 0.8s diff)

then LAP2, there should be 9 record Messages (9.49sec, so perhaps can have 10 records) but it contains 11 records. Is this expected?

Finally, I note that there is overlap of the Record messages. The last Record Message from LAP1 (timestamp) is the same as the first timestamp from LAP2. Is this expected?

Top Replies

Ben FIT over 3 years ago +1

I would use the FIT CSV Tool to convert the binary FIT file to a readable text file. That will remove the variable of the FIT to TCX convertor and what "other sites" may be doing. This will show…

All Replies

0 Ben FIT over 3 years ago

I would use the FIT CSV Tool to convert the binary FIT file to a readable text file. That will remove the variable of the FIT to TCX convertor and what "other sites" may be doing. This will show you where the lap was marked relative to records.
https://developer.garmin.com/fit/fitcsvtool/

In the record messages the timestamps are all whole seconds, but the Lap and Session elapsed time values are given to the hundredth of a second. How the records on the boundaries between laps are handled is subjective.

Most sites will select Records belonging to a Lap, or Session like so...

Record Timestamp >= Start Time AND Record Timestamp < Start Time + Elapsed Time

Tweak the either of the comparisons to be inclusive or exclusive and what happens at the boundaries will change. Take that one step further, and if a site is treating elapsed time as an integer and not a float, then things will change yet again.

What is correct is debatable from both a programming logic and perspective. How should you attribute 0.2 seconds of data to the previous lap and 0.8 seconds to the next lap. Does any value being measured change that fast to matter? Is the code complexity worth it?