GAP slower than expected!

I'm still seeing similar results on 18.23:

The mean and totals over all ten intervals look OK, but, e.g., the first interval with no ascent or descent has a 13% slower GAP!
Any thoughts?

I agree with you. Garmin's grade-adjusted pace doesn't make sense. I've just looked at two recent runs, both about 8 miles with 700' of gain (and loss). In both cases, Garmin's average GAP was 6 seconds/mile slower than my actual pace – in other words, Garmin's trying to tell me that I was faster on a hilly course than I would have been on a flat course, all else being equal. That's absurd.

Recorded distance, elevation gain and heart rate for these runs were all quite accurate (I was using a chest-strap HRM, not the built-in wrist HRM). So it's not as if GAP was distorted by inaccurate inputs.

On Strava, GAP for the same runs makes much more sense (Strava has its own GAP algorithm). Strava's average GAP was about 20 seconds/mile faster than my actual pace, with the biggest differences on uphill segments, partly offset by smaller negative differences on downhill segments. That's what you would expect.

The problem seems to be that Garmin's GAP algorithm doesn't give you enough credit for uphill segments, but penalises you quite heavily for downhill segments.

For those that are interested, here are actual numbers for one of these runs. Yes, I'm old and slow, and this was at 5,500' above sea level.

What's double frustrating about these situations is that if you try to contact Customer Support you'll get a reply from what seems like an AI bot that plainly doesn't understand the question and instead directs you to some boilerplate on Garmin's web site.

Garmin doesn't publish how they adjust pace for grade. Strava does publish how they do it:

https://medium.com/strava-engineering/an-improved-gap-model-8b07ae8886c3

There is well known research in that area

https://journals.physiology.org/doi/full/10.1152/japplphysiol.01177.2001?rfr_dat=cr_pub++0pubmed&url_ver=Z39.88-2003&rfr_id=ori%3Arid%3Acrossref.org

The key point here is that a model is developed to adjust the pace for equal Heart rate over regular periods of time (60s for Strava, unknown for Garmin). 

So a couple of things here:

- using 10s to 30s intervals as you did might not work very well

- averages over 60s interval can mask a lot of variation, in particular for HR data

- finally, the GAP introduces accuracy of a third sensor (the barometer). Peaks and valleys of measurment inaccuracies will be masked differently depending on time window averaging,

Therefore, (possibly) different time windows of calculation between Garmin and Strave could explain the differences because the data sets for HR, pace and elevation would be different.

Given all this, I don't think your attempt at validating the Garmin model using the Strave model is correct. Both are estimates using different algorithms.

Note: I am not defending the Garmin approach here. GAP is a model, like running power. It has limitations, in particular on very hilly and or technical terrain. This shouldn't prevent you from using the real time data during a workout to adjust effort for grade, or to use averages to compare runs across multiple courses.

Etupes25 said:

I don't think your attempt at validating the Garmin model using the Strave model is correct. Both are estimates using different algorithms.

You may have misunderstood the point that Ian and I were trying to make. I agree with you that there's no objectively "correct" algorithm for measuring GAP. However, Garmin's GAP fails to satisfy some very basic criteria.

• If you're running a segment with minimal elevation gain or loss, then by definition GAP should be practically identical to actual pace. But that's not the case with Garmin's GAP.
• If you're running a hilly course, then average GAP should be faster than actual average pace. (You're never going to be as fast on a hilly course as a level one, given the same energy expenditure). But Garmin's average GAP is slower than actual pace, not faster.

The reason for posting Strava's GAP is not because I think that Strava's algorithm is necessarily "correct", but just to demonstrate that it at least satisfies the above criteria.

In my example, Strava's GAP is based on the same raw data as Garmin's (distance, time, elevation and heart rate). So that isn't the reason for the difference.

martinleroux said:

If you're running a segment with minimal elevation gain or loss, then by definition GAP should be practically identical to actual pace.

This is a correct expectation, of course.

martinleroux said:

But that's not the case with Garmin's GAP.

On all my runs on flat grounds, the av GAP is almost identical to the the av pace. Here is an exemple where I run continuously, on flat grounds, at an easy pace

martinleroux said:

If you're running a hilly course, then average GAP should be faster than actual average pace.

Yep, this is the way it should work.

martinleroux said:

But Garmin's average GAP is slower than actual pace, not faster.

Not in my experience. Here are some hill intervals. I was running based on power in the upper limit of my zone 4, lower zone 5. My RPE was maximal effort. I was walking/jogging down leisurely.

As you can see the up hill sections have a lower value for GAP than for pace. In addition, the GAP is a bit slower than my threshold pace. I wish it would be a tad faster since I was in the higher threshold zone/VO2 Max zone. So it might not be strictly equivalent to a flat pace.

Note 1: this slight discrepancy could be a running power issue as well.

Note 2: the biggest disappointment for me was the training effect. The same maximal effort intervals on flat grounds gives me an anaerobic TE. This one was just "tempo" :-(

So, then, how do we rationalize your observations? As I said earlier, the main issue with your test is that your intervals are too short. This makes the data prone to altimeter/pace distortions. Strave uses 30s intervals for the calculation. Garmin doesn't say. However, their patent on VO2 Max calculation and heart rate data segment qualification mentions short intervals of 20/40s. So it is possible that an HR value of X with pace Y on the watch is really the most qualified 20 to 40s average HR value of X with pace Y. This is important because the GAP adjustments are assymetrical on climbs and downhills. This means you "slow down" more uphill than you "accelerate" downhill.

Finally, remember this is a model. It has an error rate. As you can see in the strava model, for a gradient of 10% (decent climb) Strave will adjust your pace by a factor of x1.5, but you have a 68% chance for it to be between x1.7 and x1.2

Etupes25 said:

the main issue with your test is that your intervals are too short.

My intervals were 1 mile each! How much longer do they need to be?

OMG! My apologies, I completely misread your table!

Forget what I wrote about the length of your intervals. Several minutes is fine…

In my runs, the intervals are consistently up or down.

Are your 1 milers only uphill or are they a mix of uphill and downhill?

When I simulated a simple but realistic scenario in Excel (running up then down the same way), I found that it would require a massive error to compensate for the assymmetrical nature of the correction factors and end up with an GAP that is slower than the measured pace.

One thing to try is to display GAP and pace on the same screen/graph and check whether the real-time data is reflecting the expected adjustment.

Thanks, Socoursu, I'll be interested to see how GAP and EFP compare, and having a live display might be quite useful!
However, as: 

martinleroux said:

Garmin's GAP fails to satisfy some very basic criteria.

It would be good if Garmin improved things.

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).
Even on the flat (highlighted rows) I get significant GAP variation, both faster and slower, although, again, for only 60 s intervals:

For longer intervals, the GAP seems better.  The next table highlights the rows that have GAP adjusted in an unexpected direction, but, those intervals are either 1 minute or 2 minutes:

I wonder whether there are rounding errors in the distances, times, and maybe the ascent / descent values used as the input to the GAP algorithm.  The voice lap alerts (every 250 m) for me, suggest that the spoken lap time is truncated / floored, rather than rounded, so a lap time of 1'15" is frequently given a pace of 5'04", and sometimes given a pace of 5'00".  That would affect shorter intervals more...