The run in question is this one Intervals.icu
I was using Polar H10 and Vantage V2.
Another messed up run is Intervals.icu and I now noticed that they both seem to only be synced only from Polar (I presume that’s what this means?)
Could this have something to do with the problem? Both of these runs ARE synced from Polar to Strava too, and seem fine on Strava. Here’s the pace graph from Strava for the run MedTechCD was checking
Looks like Strava reconstructed your run in a pretty clever way by using stride length for the parts where lat/long data was missing. Most watches do this for short parts where GPS data is missing, in the woods for example. But then again, when this GPS errors keep occuring, stride length will be wrong in the end because average stride length is calculated from GPS distance and cadence.
Syncing them from Strava is only a workaround but certainly not the best solution. You should check why satelite data gets lost this often.
Can you see an obvious reason why your GPS data is this errratic? Are you wearing something over your watch for example that could cause satelite loss? Or is the whole run done under thick coverage by trees?
And for what reason is the Power data missing after 28min? Does the Vantage have wrist power or are you using a footpod?
Found some talking on the net that Glonass (Russian satelite system) is regularly being disrupted under the actual circumstances and Vantage is by default set to GPS+ Glonass.
Might be an idea to try and change that to GPS+Galileo? Should be more accurate anyway with the European satelites.
This is all very interesting. Is there a way for me to check whether or not the GPS data is getting lost without diving into the FIT file (which I’m sure I won’t understand)? I mean, these runs seem normal on Polar Flow and Strava so I wouldn’t have been even able to find out this problem had it not been for this pace issue on intervals.icu.
As for your questions, on these runs I wasn’t wearing anything over the watch. There is some tree coverage (not really a proper forest but kind of a forest area) for about one third of the run, but the rest is pretty much wide open.
These extreme cases were only a few runs on intervals.icu as well, but do you think it’s likely that the GPS data is messed up in the remaining of the runs as well, and it just doesn’t show because of they’ve been synced with Strava as well? I run more or less the same route ever time, so I’ve run this dozens and dozens of times this year alone.
Happy to try changing to Galileo, just wondering whether I’ll ever be able to tell if it makes a difference 
You will see the difference if you continue using Intervals. Your data, speed chart, max and avg pace should be “normal” 
But I wonder if you recently saw strange problems/issues when starting your run? Does it take longer then usual to lock a minimum number of satellites before you can start your workout for example?
To get the most accurate data for a run, you need good GPS data. Stride length is ok to fill in some gaps where the GPS data is less good but clearly, stride length isn’t a constant. It is significantly reduced when going uphill…
When synced from Strava and Polar, do you still have the ability to download the “original” fit file in Intervals? If so, someone might know a tool to quickly check the RAW GPS data (the pure lat/long numbers) and not the track already corrected by Strava and/or Polar.
What I did was loading the FIT in Golden Cheetah and then I checked the RAW data. It was immediately obvious that a lot of datapoints were missing the GPS data. The modern tools try to compensate for that and do a really good job. But my believe is that they should notify the user if too many errors need correction, so that you can take action to improve.
Ah, but this is what I was trying to point out Out of perhaps 60 runs even Intervals showed issues only with maybe 5 of them. For the rest the speed chart, max and average pace etc were seemingly correct. Perhaps this is because of the Strava sync (could maybe try to un-sync strava and see how things seem if I only sync with Polar, or analyze the original FIT file) and there’s been issues with all of the runs but if not, it seems to affect only about 10% of the runs so far, and thus spotting whether or not switching satellites helped or not might be a challenge.
I have been meaning to try Golden Cheetah anyway, though, so maybe this is a chance to (try to) have a look. It looks awfully complicated
I haven’t had issues with starting my runs, no. It tends to take maybe 5-10 seconds until the GPS “locks in”. I have to say that I have noticed the speed being a bit “jumpy” in those more foresty areas of the run, but I’m not sure if this area is really the problem. I checked the map and while you said the first 28min or so seem ok, the “worst” area seems to be behind me at that point already. There are some trees surrounding the route after that as well, but not as much, and after 45min it’s pretty much open sky. This feels like a very weird problem.
I wonder if the problem could somehow stem from the conversion of the file? If I have understood correctly, there is no way to export from Polar straight into FIT. I now exported one of the troublesome runs (the one you analyzed on Golden Cheetah) into GPX, opened it in Google Maps, and the route seems fine.
Admittedly I don’t know if this could once again be due to the device compensating the missing GPS data…
I’ve checked the map in GPS Visualizer: Draw a map from a GPS data file and it looks quite good but when you check the lat/long datapoints, there are big gaps. I’ll export that this evening from golden Cheetah to a csv file and will send it to you. Can’t do it now because I don’t have Golden Cheetah on my business PC.
Golden Cheetah has a steep learning curve but it has always been one of the most advanced workout analysis tools. For this basic check, you just Import from file and go to the Edit tab where you have all the columns with data. I have to say that I am only using it occasionally the last 6 months or so, because intervals is getting just as good and is available online
What I’m still wondering, is why there is about 28 min of Power data, and then nothing anymore. The end of the Power data stream is where the errors start to occur. Can you find an explanation for that?
Nope, no explanation for that. On Polar Flow I can see a power curve right until the end, and it seems to roughly match the HR curve as well as the pace curve. But like I said in my first message, I don’t really understand power at all so all I can tell is that it rises and falls roughly at the same time with the other two curves.
I installed Golden Cheetah and have checked a few files now. Presuming that I have been checking the right data (Latitude/Longitude on the Edit tab), I don’t think the GPS data is the sole cause of the problem on Intervals.
On Aug 1st I ran an 18km run, where Intervals reports my Avg speed as 53.2 and max speed as 216.5km/h. According to Golden Cheetah, the Lat/Long information is missing only for about 10 seconds during this run. As a comparison, the 10km run on Aug 3rd has a 40 second gap in the GPS data, but Intervals reports its Average speed as 8.2 and max speed as 22.6km/h. The max speed is obviously too fast for the second example, but there it sounds somewhat accurate considering the longer gap in GPS data whereas in the Aug 1st run the 216km max speed doesn’t make any sense at all.
The common problem with the files that I’ve checked was the missing power data. The files where the speed was completely messed up were both missing the power data for most of the run. I don’t see how this would explain the problem either though, but like I said, I don’t really understand power.
After all this digging I’m now wondering what to do. I’ve now changed the satellite to Galileo and have Golden Cheetah installed so I can keep an eye on whether or not the GPS data seems better. That said, I’m wondering if an easier solution would just be to prioritize HR over Pace. With that I’d know the Loads are more or less reliable.
On the other hand the Fitness graph and the speed-based load do LOOK pretty normal after I turned off the Elevation Correction and the GAP model. But because the speeds of some of the Activities are still messed up, I can’t really even guess how correct the speed-based Load is, and am back to wondering whether prioritizing HR would after all be the better option here.
There is obviously something wrong and the best solution would be to find out exactly what is wrong. The HR load would be just a workaround and leave you with absurd pace/speed data. At the end of the day, pace is an important metric to track performance improvements.
The speed field is normally populated by data from a dedicated speed device, like a an rpm counter on a bike wheel, or in case there’s no such sensor, by a distance calculation based on the GPS data taken every second. I haven’t checked the exact uncorrected plots of the GPS data but the lines with erratic speed fields should have bad GPS data. Bad GPS data is just as problematic as no GPS data.
I’m not giving up yet, there has to be something we are overlooking.
If you check the activity on a Polar app, is the Power data available for the whole run? I have a feeling that both these problems are somehow connected.
There is not that much to understand regarding Power. The advantage of power is that you have a target metric that is independent of incline, wind, terrain… Pace is strongly influenced by those and thus difficult to use as a guidance for intensity during a workout on rough and rolling terrain. HR is influenced by heat, fatigue, lack of sleep… Just look at Power as an intensity metric that is valid and equal in almost all circumstances and thus more easily comparable from one run to another.
The Power data is available for the whole run if I look at the session in Polar Flow and it at least seems accurate as well.
I realized one can import a TCX file on Golden Cheetah as well, so I tried exporting one from Polar Flow and importing it there. The TCX file for the Aug 7 run (the one whose FIT file I sent you) is not missing any Power data or GPS data. Would this suggest there’s something off at the conversion stage or is this Polar trying to fill in the blanks? I’m trying to wrap my head around what is closest to the actual raw data.
The HR, and the Power data (when present) seems to match between the files but the GPS data is a little bit different (for example 62.23267833 vs 62.232429442). I don’t know if this discrepancy in the GPS data is anyhow meaningful.
I’m getting more and more convinced that there is a problem with the FIT files coming from Polar. Polar only started a year or three ago to make the FIT files available through an API. I’m not a Polar user so I don’t know if they have a FIT download available from the Flow app. As far as I am able to find out, the Flow app only gives access to TCX, CSV and GPX. And the devices only support TCX. Meaning that there is some conversion going on at the Polar site to output FIT.
Intervals get’s the FIT from the Polar API. Don’t know which one Strava gets.
What is the data looking like in Intervals when you manually upload the TCX there? Just go to the Activities page, click on Upload and point to your downloaded TCX file. If that looks correct, there must be a problem at the Polar site. But that would be strange since nobody else is reporting problems 
Seems you’re likely right. It looks fine when I upload the TCX.
The Polar synced version:
The uploaded TCX:
The speeds are fine as well. Also, interestingly enough, the Load is the exact same, so I do wonder how we get the same Load with two very different sets of data.
You’re right that Polar doesn’t allow exporting to FIT. I’m also not sure how exactly it’s done with Intervals. At least for the old activities Intervals asks you to submit the download link you can get from your Polar account when you request all data. This data is JSON files, not FIT, so I don’t know if Intervals then converts it somehow or somewhere or if it uses this data to ask Polar to sync the old activities, which it then might do by converting to FIT? I obviously have no clue about the technicalities here, but it is indeed beginning to look like the problem is in the conversion. But I’m also quite surprised this hasn’t come up earlier and/or more often.
Now that looks a lot better .
But unfortunately, it requires a manual import.
There is some more info on the integration here:
You probably should contact Polar support to check the problems with your FIT files.
Ok, so this probably explains it indeed. The “import all Polar data” option is actually there, and is the one that I used, so this explains the messed up speed data. If the problem doesn’t apply to new data, I think I’ll simply continue using Intervals “on the side” and then switch fully here perhaps for next summer.
I’m about to do an actually somewhat planned winter training this year for the first time ever, so I kind of need to be able to use old data for that That should also be plenty of time to get me enough NEW data so that I don’t need the other apps anymore when the summer season begins.
I thank you very much for all your help and for your patience!
Tx @MedTechCD for helping so much with this issue.
Intervals.icu converts the JSON files from the Polar import into FIT files and imports those. I had a look at your 1st August run and the velocity data is definitely off. Thats why the load is crazy when pace load is used.
The automatic sync does get fit files from Polar so there shouldn’t be an issue with those.
If you could get a TCX for 1st August and mail that to david@intervals.icu then I can compare. Tx.
Mailed!
I had a look at my code for this and there is a note:
/* speed data is way off so don't use it */
The speed is calculated from the GPS data. So thats why the import isn’t great. However I did introduce a little smoothing which makes it much closer to the TCX and also fixed a bug that was breaking power import (sometimes).
Tx for reporting this issue.
Thanks for looking into this!