GAP slower than expected!

Ian the Morris Dancer said:

To be fair, my intervals were short, 30 s, but I would still expect to see faster GAP for uphill, and slower GAP for downhill (I'm not running down anything very steep).

Yes indeed. I would contact Garmin support and share your data with them. 

I looked through my running data. First thing I noticed is that GAP is not calculated in the track running profile.

For the run below, the terrain is pretty flat. As you can see, when no change in altitude, GAP and Pace concur. For most of the intervals, the GAP is estimated in the right direction of adjustment except interval #17.

Maybe we are just seeing normal standard deviation error in the model by construction and/or noise from the altimeter data within the interval.

Etupes25 said:

For most of the intervals, the GAP is estimated in the right direction of adjustment

Indeed, much better than mine.

Etupes25 said:

Maybe we are just seeing normal standard deviation error in the model by construction and/or noise from the altimeter data within the interval.

I assume that the ascent and descent reported come (primarily) from the barometer, and compose the altimeter values that are inputs to the GAP model; and so the GAP direction should concur with the reported ascent and descent, whether or not there are errors in the measurement.  I understand that the model will report a mean GAP, for which there is a confidence interval, as per the graph you showed, but that mean will be in the expected direction of GAP adjustment.

I can also contribute with my observation: the following table shows a run on a track (thus perfectly flat, but I was using normal run activity and not track running).

The following conclusions can be drawn from that table:

The shorter and faster the interval, the bigger the error (which also seems logical to me as rounding errors in the measurement already contribute a lot to a wrong calculated GAP).

For the warm up and the cool down with consistent speed and a duration of about 20 min, the GAP is exact, as well as for the average of the whole run (bold numbers at the very bottom), for the sprint intervals (20 s at high speed) the error is large. For me that means the the GAP is only valid for longer runs and not really useful for short (especially sprint) interval training.

To me, it feels like another example of Garmin prioritising the development of gimmicks such as Hill or Endurance score over the monitoring and improvement of core metrics like this.

I think for those very short and fast intervals you just cannot expect more accuracy. In my case sometimes the altitude difference for an interval was shown as 1 m (due to air pressure changes, whatsoever - for me absolutely ok) even if it should be 0 on a track. But this 1 m has of course a much stronger impact on the calculated slope for a distance of like 120 m than for a distance of 1.2 km (factor 10!) - same for distance: if you have a GPS error of 2 m for 120 m distance its impact is much higher than for like 1.2 km (and I do not think that the GPS distance error is proportional to the distance, but rather an offset of a few meters)...

TomL said:

I think for those very short and fast intervals you just cannot expect more accuracy. In my case sometimes the altitude difference for an interval was shown as 1 m (due to air pressure changes, whatsoever - for me absolutely ok) even if it should be 0 on a track

Right, but as Ian the Morris Dancer said, there’s two separate issues:

1) accuracy/precision of measured altitude difference

2) the quality of the GAP calculated from the measured altitude difference

Of course we want the altitude difference to be accurate and precise, but also we want the GAP algorithm to work a certain way given the measured altitude difference that we have, *regardless* of how good the altitude data is.

For example, if you look at Strava and runalyze (which have their own GAP algorithms that are different than Garmin’s), you’ll see that GAP behaves as you’d expect in the following cases:

- In a lap/interval with positive net altitude difference (“uphill”), GAP is faster than actual pace

- When altitude difference is 0, but altitude gain and altitude loss are non-zero (“hilly”), GAP is faster than actual pace (this makes sense because the extra energy required to climb a given hill is always greater than the energy saved by going down the same hill, so a hilly course will always be slower than the equivalent flat course)

- When altitude difference is negative (“downhill”), GAP is slower than actual pace

The actual GAP values that Strava and runalyze calculate are different from each other, but they seem to follow these rules.

OTOH, with Garmin, sometimes if I run an uphill or hilly lap/interval, Garmin tells me my GAP is slower than my real pace, which is clearly wrong. This doesn’t seem to happen with Strava or Runalyze. Given that all 3 algorithms are presumably working with the same altitude data as input (my device has a baro), it’s a red herring to say “well the altitude data might be wrong!”

IOW, I want the GAP algorithm to work as outlined above, at a minimum. The question of whether the input is valid is important, but it’s a separate issue. (Then ofc there’s the question of magnitude of the difference between GAP and real pace, for a given altitude change.)

Sure, the measured altitude difference may be less accurate for shorter intervals. I’ve seen the same problems with an entire one hour activity.

For me, Garmin GAP is useless. (Not like GAP is really that useful in the grand scheme of things, but it is fun to look at.)

TomL said:

For me that means the the GAP is only valid for longer runs and not really useful for short (especially sprint) interval training.

This seems to be the case, yes, but it doesn't justify the situation. Garmin lets you select GAP as a real time field, so this makes me think the intent is to have an accurate GAP within a few seconds.

TomL said:

I think for those very short and fast intervals you just cannot expect more accuracy. In my case sometimes the altitude difference for an interval was shown as 1 m (due to air pressure changes, whatsoever - for me absolutely ok) even if it should be 0 on a track. But this 1 m has of course a much stronger impact on the calculated slope for a distance of like 120 m than for a distance of 1.2 km (factor 10!) - same for distance: if you have a GPS error of 2 m for 120 m distance its impact is much higher than for like 1.2 km (and I do not think that the GPS distance error is proportional to the distance, but rather an offset of a few meters)...

I have noticed a "delay" of about 5s for pace data (probably some short-term smoothing of the sensor data). So, if Garmin is calculating GAP every 5 seconds, noisy data from the altimeter could throw off the estimates in the real-time data which add to the smoothing of the pace, and that could remain visible after averaging for short intervals, but much less for longer intervals.

I am using Stryd for pace.

FlowState said:

The actual GAP values that Strava and runalyze calculate are different from each other, but they seem to follow these rules.

To be fair, Strava doesn't have to show you the GAP in real time, and the calculation is off-line. This provides the Strave engineering the space to do more data validation and filtering.

FlowState said:

For me, Garmin GAP is useless. (Not like GAP is really that useful in the grand scheme of things, but it is fun to look at.)

Same here. I just don't use this value. I tried for hill sprints and GAP is not responsive/accurate enough. I use power and it is better, but not perfect on steeper hills or technical terrains by far (whether Garmin or Stryd power)

Etupes25 said:

To be fair, Strava doesn't have to show you the GAP in real time, and the calculation is off-line. This provides the Strave engineering the space to do more data validation and filtering.

That’s a good point, but there’s no rule that says lap/activity GAP (after the fact) has to be based on real-time GAP at all. Same as how lap/activity stride length is available (in Connect) even when instant stride length is not, and how lap/activity pace isn’t necessarily congruent with instant pace (if you take the average of all the instant pace values, the result will almost certainly be wrong.)

I would be happy if lap/activity GAP was calculated using a better algorithm than instant GAP. Personally I only look at GAP after the fact.

Do you know where to find the GAP data in the fit file? I tried to export the fit file of one run to excel using an online tool, and I don't see the GAP data? Maybe one of the fields is the adjustment factor?

Also, apparently Garmin removed GAP for track running. Maybe because it was showing issues as well:

https://forums.garmin.com/apps-software/mobile-apps-web/f/garmin-connect-web/317843/grade-adjusted-pace-on-a-level-track

I looked at the graphs at some runs and I can see that GAP suffers from hiccups, in particular during the 5 1mn/30s intervals; you can see the GAP slower than the pace by about 20s/mile there. 

FlowState said:

That’s a good point, but there’s no rule that says lap/activity GAP (after the fact) has to be based on real-time GAP at all. Same as how lap/activity stride length is available (in Connect) even when instant stride length is not, and how lap/activity pace isn’t necessarily congruent with instant pace (if you take the average of all the instant pace values, the result will almost certainly be wrong.)

I would be happy if lap/activity GAP was calculated using a better algorithm than instant GAP. Personally I only look at GAP after the fact.

True! That is a good point.