There seems to be some discrepancies regarding elevation gain recorded between Garmin connect and Intervals.
Here is the original garmin:
and here is the one from Intervals
When comparing the elevation gain for the individual laps in Intervals it is higher than Garmin and the doesn’t add up to the total which is the same on both Garmin and Intervals
Intervals.icu uses the total from the fit file which is why that matches up. For intervals it uses the altitude data and if altitude(t) > altitude(t - 1) then the elevation gain for that interval goes up. I suspect Garmin might be doing some more smoothing when it calculates the total and hence comes up with a lower number.
Ok, that’s probably true. However, I compared the same activity in several different web platforms (Finalsurge, Runalyze, Strava with Sauce) and they all showed similiar gain. Intervals almost had double elevation gain per lap
Is it possible to adjust that threshold because now it reads way to high. It would also be great to have elevation loss, both as a field and as a total.
I will have another look at this before I implement pace curves.
any advance? I have the same problem when running
Could you please post a link to a run on Intervals.icu and some stats on elevation gain from other platforms? Tx.
Here is a run from yesterday
Total elevation is correct (164m) but the laps sums to 522m of elevation gain
if you view overview its 164m of gain and the laps sum to 164m of elevation gain in garmin connect
I’m having the same issue and think I found the problem.
I ran a circular course in this activity, but the Intervals algorithm shows the elevation as dropping but never rising to the start levels, while the same does not happen in the Garmin connect register:
I don’t run so not too knowledgeable on this but I have seen settings on my garmin watch for elevation corrections. I believe my watch has a barometric altimeter so it isn’t used but maybe yours doesn’t and thus Connect is “correcting” it?
Link to Garmin FAQ here
Hi, do we any progress on this? I still see wrong altitude data per lap or if I zoom in of a portion of the run. Would be great if we could add elevation loss as well to fields
I suspect that this problem is accentuated when you run into a headwind. I guess Garmin apply some sort for filter for that scenario. Here is a recent run that was 168m of elevation gain but when you select the whole run in the chart view you get 834m
I hope you’re going well.
First, thanks a lot for the tool. I’m a long time user, and I’m enjoying it a lot. With all the improvement these last years, it has now become my main training tool.
I also have the same issue on all my running activities
E.g: today’s one: Intervals.icu
Total climbing is 69m, but when looking at elevation gain of the different intervals, there’s more than 100 meters.
Especially, I ran a 4.5k totally flat section around a water plan:
However, 42 meters of denivelation have been reported on this section
Activity has been recorded with a fenix 3 with a barometer.
When looking at the same flat part on Stryd, 10 meters only are reported, which make much more sense:
Tx. Currently Intervals.icu compares each altitude point to the previous one and if the difference is positive that gets added to the climbing total for the interval.
I tried doing the same with a 30s moving average of the altitude and that gave 11.5m of climbing. But I think 30s is way too long. You could run up and down a decent little bump in that time which could get smoothed out. A 10s moving average still gives 23.6m of climbing.
Any runners out there have an idea how to tackle this?
I think that Garmin and other watch manufacturers apply a filter that removes the small elevation gain errors. For example there need to be at least 3m (not sure about the exact threshold) of elevation gain for it to start counting the elevation gain
I just tried to apply a threshold on the data from my activity.
When putting it at 1.2 meters, I get the same elevation data as sent by Garmin, and the flat part is only 9m of D+, which is consistent with what i can see on stryd.
You can play with the sheet here: Elevation Threshold - Google Tabellen
That is indeed what they are doing and why there are differences in between brands and models. The threshold for a height change that is considered ‘true’ is different for each manufacturer and sometimes even per device type.
Anything below the threshold is discarded and avoids false height accumulation caused by oscillating values.
Thanks so much for this. I should be able to get it implemented this weekend.
I have deployed the fix. You need to do Actions → Re-analyse to update existing activities.
Super, thanks for this!
On this topic, is it possible to add elevation loss to the fields? I often want to know bot gain an loss for a specific section when I a, analyzing a trail run