A user and friend contacted me asking about how devices store distance, time, and speed in FIT files. He pointed out that it is redundant to have the speed stored if you already know the distance and time; you could simply calculate speed later from the distance and time. He posited that because the FIT file format is so compact, they must be omitting redundant data. That is indeed NOT the case. The FIT file format is compact because of the way that data is structured. I was trying to explain to him that speed (and so many other values) are stored within the FIT file format. In fact, my tools only address FIT file values that are of interest to endurance athletes... but a FIT activity file can indeed store information like ball speed and dive depth... and so much more.
I've known that the instantaneous speed shown on your device is partially "smoothed" so you don't get erratic second-by-second numbers for speed. Moreover, second-to-second distance is never 100% accurate. GPS technology is absolutely amazing, but it is not perfect. As such, when these devices are recording values on a second-by-second basis, there may be a small differential between the speed calculated as "distance over time" vs device reported "speed."
Anyway, my friend had to do his own analysis to prove to himself what I was trying to explain. He eventually came up with a very eloquent graph that displays the concept perfectly. Moreover, he included two different methodologies of measuring: with and without a wheel sensor. I found the graphs to be quite interesting and with his permission am sharing this with you! For the majority of people, this granularity of information is not important (even for my own activities, I don't care about this). Nevertheless, for people who like to geek out on data and get a "behind the scenes" look at how the data is being recorded, this is something I'd like to share.
- Effect of wheel sensor on how speed is calculated.
Please note that my friend chose two options:
1) Calculating Speed from distance between GPS Coordinates / Time (This is what GOTOES does when you select the "Calculate Distance" option).
2) Calculating Speed from embedded distance (This is what GOTOES does when you select the "Use Existing Embedded Distance" option).
All four of these graphs were created with Garmin's 1-second recording.
- These are the "Calculate Distance" and "Use Existing Embedded Distance" options I am referring to above.
Below, we see what happens if we use Garmin's "Smart Recording"; I find this very interesting:
- Time Distance/Speed correlation with Smart Sampling
There is also a 3rd option that he did not plot (because it would have been redundant, but I still want to mention because it has relevance to the GOTOES tools):
3) Use Garmin embedded speed to calculate distance. (This is what GOTOES does when you change the global setting to use "speed to calculate distance" vs using "distance to calculate speed"). It turns out that this option was needed for a rare set of GPS devices that only records distance in 50m or 100m increments. This can happen in rowing or swimming files. I understand why it might happen with swimming - it has to do with the completion of a lap. When the accelerometer detects that you completed a lap, it increments the distance by 50m. The rowing is a bit more puzzling, but it seems to happen on indoor rowing machines. Oddly, even though the rowing machine recorded distance every 100m, it recorded second-by-second speed... that is why I added this feature to "backwards calculate" distance using the speed values from the FIT files!
- This is the "Calculating distance from speed" I am referring to above.
I hope the geek-out crowd enjoys this post.