Jagged Speed Graph on Indoor Workout

[fulmar2]

Yesterday, a user reported to me that they experienced a spiky speed graph after using the GOTOES | Strava tools to merge two overlapping files. Here is what it looked like:

Notice the speed graph (blue) spikes up and down erratically

The Problem:


I investigated the files carefully; the original TCX file looked very similar to the original file. It took me a long time to determine the difference, but I finally found it:

Code: Select all

//GOTOES FILE:
<Time>2022-10-09T12:44:07Z</Time>

//ORIGINAL FILE (FROM A WAHOO):
<Time>2022-10-09T12:44:07.467Z</Time>

See the difference? The wahoo records fractional time, but my tool rounds the time to the nearest whole second. Almost all GPS devices record time in whole-second numbers, but for some reason, Wahoo records fractional time. The rounding of the Time Stamp was causing the speed calculation to be incorrect when Strava uses this equation:

Code: Select all

Speed = Distance ÷ Time

HOWEVER, my tool Calculates and Inserts Speed. Also, the tool smooths the speed, so these fractional differences should theoretically be "washed out".

Code: Select all

//GOTOES FILE:
<ns3:Speed>3.875</ns3:Speed>

//ORIGINAL FILE (FROM A WAHOO):
NO SPEED INCLUDED

What I discovered is that EVEN THOUGH MY TOOL IS CORRECTLY REPORTING SPEED TO STRAVA, STRAVA IS RECALCULATING THE SPEED BASED ON DISTANCE ÷ TIME. They even have a support article that explains this. I tried this with TCX and FIT exports - and Strava still ignored the speed inserted in the file. I tried uploading my files to Garmin Connect and Training Peaks, and both of those applications DID respect the speed my tool provided. In other words, of the 3 apps, only Strava was recalculating speed.

Next, I tried leaving out the distance. I figured that this would force Strava to use the speed to calculate distance using the math:

Code: Select all

Distance = Speed * Time

Instead, Strava reported a distance of 0 and a flat-line speed of zero. Remember, this was an indoor workout, so Strava could not calculate distance from Latitude / Longitude... This means that if the submitted file does not have a distance stream, Strava still ignores speed. In other words, I cannot find a way to get Strava to look at the embedded speed field. Instead, Strava seems to revert to ignoring embedded speed and then calculating Speed using the equation:

Code: Select all

Speed = Distance ÷ Time

The Solution:

Because this is an indoor workout, and because the timestamps are getting rounded to whole numbers, we have two choices to solve the problem:

Choice 1:
Stop rounding the time stamps. Unfortunately, for merging files, this becomes exceedingly difficult because with decimals that go out into the thousands, that means there are 1,000 more possible time points per second that would need to be matched with an overlapping file. Frankly, that's just too much math for the tool to handle. Some people upload files with millions of points, and trying to parse out 1,000 points * a million takes us into the billions. This doesn't seem like a good solution for the GOTOES | Strava Tools.

Choice 2:
Make the Indoor workout look like an Outdoor workout to Strava. Since we know that Strava is going to recalculate the speed no matter what, we can "take control" over how they calculate the speed by giving them something else to make the calculation based on: Latitude and Longitude. If we make a "fake" GPS track, we can force Strava to consider the workout to be an outdoor activity instead of an indoor workout. The tool can carefully place GPS points based on the (Distance = Speed * Time) equation so when Strava does the reverse calculation (Speed = Distance ÷ Time) it gets the correct speed. This allows us to use 1-second recording in the final file AND maintain proper speed. Here is how you achieve that in the GOTOES | Strava Tools:

To try and fix the irregular speed issue, please try checking the "Make a Fake Track" option.

After you make a fake track, this is what your activity will look like... notice how there is now a map associated with your activity. The map is essentially a circle out in the middle of the Pacific Ocean. The reason I selected this location is because the entire segment has an elevation of 0 (as to prevent Strava from automatically calculating elevation. By the way, the fake-track feature also can help if your indoor workout isn't showing override elevation properly). Also, because it is in the middle-of-nowhere, it shouldn't affect any real leaderboards.

Also, notice that the speed graph is now correct and much smoother than before:

Making a fake track - essentially making an indoor workout look like an outdoor activity allows us to "take control" over how Strava calculates speed from the activity.

This workaround is a little clunky, but it has already long been implemented by applications like Zwift - they realized that Strava recalculates data, so in order to override the Strava default behavior, Zwift has always inserted maps to force Strava to respect the data in the file.