Can anyone confirm that speed is a 14 bit number when it's compressed with distance ? I have only one FIT file to base this assumption on.
Can anyone confirm that speed is a 14 bit number when it's compressed with distance ? I have only one FIT file to base this assumption on.
I don't have an example FIT, but if I interpret Profile.xslx correctly, the "Bits" column in "Messages" seems to imply an even split: 12 +12 bits over three bytes. Would that mess up your current numbers? Just guesswork on my end.
EDIT: See row 583 under "Record" (21.47.00 release)
Hi Thanks very much.
Yes, I've come to that conclusion as well and with the one fit file I've got have been able to match zero speed to zero distance throughout the activity.
r
Nick
"12 +12 bits over three bytes" is correct. With speed having a scale of 100 and distance having a scale of 16. Speed is an instantaneous value, whereas distance should be accumulated. Look at the decode.c example in the C SDK. It shows how to unpack the values.
Thanks very much for the scales. Yes, I gathered distances are accumulated, which cleverly solves the problem of registering infintely long distances using 12 bits.