Strava Drama: The most accurate way to sync with Strava
Hi, I'm superkrups20056. I recently solved my issue with Microsoft Health not syncing to Strava here. At the end of that post I detail how Microsoft Band still suffers from inaccuracy issues when syncing with Strava. If anyone regularly uses Microsoft Health to sync with Strava then they know that Strava constantly cuts off 0.1-0.5 miles off their GPS runs/bike rides. This messes with your time markers and most importantly your split mile paces. It makes it difficult to track your improvement on Strava's website as a result.
The syncing inaccuracy occurs because of how Microsoft Health packages the TCX file it sends to Strava. The problem was described in a post that Elle Anderson, a Strava employee, detailed on January 4, 2016. The year long issue thread can be found here. This is what Elle said:
Hello -
I've done some investigation for you MS band users.
I've taken Paul Hardy's most recent 5k run and downloaded the original file that was sent to Strava from Microsoft Health. The format is TCX. At the beginning of the file is summary data, and throughout the file are data points recording the lat/lon, time, and accumulated distance for each point.
For example, the summary lists the total distance:
<Id>2015-12-25T09:23:51.4752752Z</Id>
<Lap>
<TotalTimeSeconds>1557</TotalTimeSeconds>
<DistanceMeters>5015</DistanceMeters>
<Calories>359</Calories>
<Intensity>Active</Intensity>
<TriggerMethod>Manual</TriggerMethod>
However, the very last data point in the file list the distance differently:
<Trackpoint>
<Time>2015-12-25T09:49:51.4752752Z</Time>
<Position>
<LatitudeDegrees>54.9497731</LatitudeDegrees>
<LongitudeDegrees>-1.6156602</LongitudeDegrees>
</Position>
<AltitudeMeters>29</AltitudeMeters>
<DistanceMeters>4910</DistanceMeters>
<HeartRateBpm>
<Value>170</Value>
</HeartRateBpm>
</Trackpoint>
So, here is what I think is happening.
When Strava processes the file, it does not simply take the summary data (correct distance) and plug it into the activity page - instead, it parses each data point to make the graphs etc. When it parses each distance point, the total distance for the activity as seen by this data is 4.9km. This is seen by the final data point above that lists the cumulative distance at the final point.
Strava has an admin tool where I can override the distance data in a file and recalculate the distance by measuring between the GPS coordinates. If the GPS coordinates are used to calculate distance, the distance totals a correct 5.0km.
If Strava were to simply process all MS data using distance calculated by GPS coordinates, then the distance would be correct. However, by default, Strava instead reads the raw distance data in the file.
In my opinion, this is problem stems from the file generated by MS - if the file had the correct distance data written into the data points, then this wouldn't be an issue.
I don't have a solution for you folks at this time, but I hope to shed some light on the situation and I'll make sure the rest of the Strava team is aware.
From my understanding and investigation, what this means is that the TCX file that Microsoft Health sends to Strava has 2 important distance values:
-
A summary section where it lists the total distance of the GPS enabled run.
-
A final data point's total distance, which is the last point the GPS gathered when tracking the run. Therefore, if you end your run after your Band records it's final GPS point, the final GPS point's recorded total distance will be slightly less then that of your run's total distance.
When Strava receives the TCX file, it does not use the full distance from the summary section. It uses the distance from the final GPS point instead, causing the inaccuracy. One can observe this inconsistency themselves by downloading the TCX file that Microsoft sends to Strava through Strava's website with the StravistiX Chrome extension and viewing the TCX file using Notepad or TextEdit. Now why can't we just edit the final data point's distance in Notepad to match the complete distance? Well, this leads to an abnormal spike in pace at the end of the run, because now you are saying that you ran from data point 99 to data point 100 in the same amount of time, but covered way more distance.
The (hopefully temporary) fix that was suggested for this issue by Elle Anderson in the issue thread was to export the run as a GPX file off of Strava, delete the run, and reimport it. In this way, Strava recalculates the distance and somehow comes up with the right answer:
Paul, the outcome when exporting the GPX from Strava makes sense to me. This is because I know that we recalculate the distance in the GPX file based on the GPS coordinates, not the original data.
In the meantime, I'd recommend this as a possible workaround. It's a little bit of extra work, but until a better solution comes along as least you can get the correct distance up on Strava.
Kobus - I think the GPS accuracy is fine - I think how the MS software processes the distance in the file that they send to Strava is where things mess up. This can be a problem with Garmin files too.
What I don't know is how the MS band calculates distance and why the total in the last point is different from the summary value.
So this is what I had been doing every single day I ran...I'd been syncing to Microsoft Health, exporting to GPX on Strava, deleting activity on Strava, and re-importing on Strava. It's been a hassle, but for the most part it's been kinda accurate. Not perfect, but not horrible either. The times it has been super inaccurate has been when the Band drops GPS coverage for a minute or two. This REALLY screws with the data and causes the exported GPX file to be just as much of a mess when re-imported into Strava. In order to figure out a way to properly get these dropped-GPS runs read accurately by Strava, I came across a SUPER ACCURATE way of importing ALL Microsoft Health runs into Strava.
- Sign up for a free acount on www.fitnesssyncer.com
- Connect your Microsoft Health account and force a sync.
- After it's done syncing, go to the "Stream" tab to view all your recent Microsoft Health data. The runs will be downloadable in GPX, TCX, KML, or FIT file types.
I found that downloading my recent run from fitnesssyncer.com as a TCX file and importing this file into Strava was the most accurate. The following are split times from a 5-mile run that I did today in which the GPS dropped out for a minute while I was going up a hill. Take a look at how accurate the Strava split data is when compared with Microsoft Health!
They are all dead on or within a second! Now, I know Strava uses moving time, not elapsed time, when calculating pace, so that could be a reason why Strava paces are always different compared to Microsoft Health. Even knowing this, there are times when the Strava paces are still kind of off using the old "re-import the GPX" method. Importing the TCX file downloaded from FitnessSyncer, on the other hand, yields super accurate pace results. But why?
It seems that FitnessSyncer's TCX file is different from Microsoft Health's TCX file that it sends to Strava. For some reason, the final data point FitnessSyncer's TCX lists is the very end of the run. That means that TCX's final data point lists the complete distance! And this is why importing FitnessSyncer's TCX file into Strava yields the most accurate results.
TL;DR: Just get down on both knees and beg u/devbent and Elle Anderson to fix Strava syncing soon.
Posted Feb 22, 2016, 5:30 AM UTC · edited