Hi everyone,
I am working on the integration of our Decathlon Coach with Strava. We are uploading activities via FIT files.
We are facing a persistent issue regarding how Strava calculates Moving Time versus Elapsed Time, leading to incorrect stats for our users.
The Context: Our users record running activities using our app. Often, these are continuous runs with no pauses (the user never hits the pause button). Consequently, our FIT files contain the trackpoints and the total Elapsed Time, but no specific "Pause" or "Resume" events.
The Problem: Upon upload, Strava ignores the duration recorded in the file and attempts to recalculate the Moving Time based on the GPS data. Because of GPS drift or slower sections, Strava’s algorithm interprets parts of the run as "resting time" and removes them.
The Result:
-
Real Data: 10km run in 1h00 (Pace: 6:00/km).
-
Strava Display: 10km run in 55min (Pace: 5:30/km).
The "Moving Time" is significantly shorter than reality, artificially inflating the average speed. This generates user complaints as the data on Strava does not match their actual performance.
What Support told us We contacted Strava Support, and they confirmed the behavior: "If you do not pause at all [in the file], our server will calculate moving time-based on the recorded GPS data."
The "Race" Tag Workaround We know that tagging the activity as type = race forces Strava to use Elapsed Time as Moving Time. However, Support advised against using this tag for standard activities that are not actual races.
My Question Since we cannot use the "Race" tag for everything, what is the correct technical implementation in a FIT file to force Strava to trust the file's duration?
-
Is there a specific setting or header field in the FIT protocol to disable server-side Moving Time recalculation?
-
Should we inject specific events (even if dummy ones) to trick the parser into respecting the device time?
Any help or documentation on the expected FIT structure would be greatly appreciated.
Thanks!