Running Distance / Pace calculation is flawed / needs rework

I know that instant pace and instant stride length are recorded in the file.

I just don't think that they form the basis of average pace and average stride length. (i.e. the average metric is not equal to the average of the instant values).

I already tried to explain why.

- It would not be mathematically sound to average the instant values in this way (because of the limited resolution and accuracy of the individual points, and because there is a much better way to do so - by directly deriving the average from the measured distance and time)

- to expand on the previous point, even if we concede that the distance is inaccurate, and we also concede that the instant paces are inaccurate, what's worse: to use the single inaccurate distance value, or to average 100s, 1000s, or 10,000s of inaccurate instant pace values? Hopefully the correct choice is clear here.

[Obviously the total distance is already an aggregate of individual data points, so there's no reason to aggregate *other* individual data points like instant paces, to calculate a metric that's clearly based on total distance. If you do so, you will find that the value will not line up with the total distance and time.]

- indeed you will see that average pace *always* equals activity time / activity distance, and average stride length *always* equals activity distance / (time * avg cadence), but if you were to literally add up all the individual instant values and take the average, you would *not* get the same results, even if you access the original data on the watch without rounding (I've literally tried it as a dev, see below)

- instant stride length was not available on older devices yet average stride length was still calculated

As a hobbyist Connect IQ dev (I'm also a dev irl), I noticed a long time ago that if I had to manually calculate lap pace, it absolutely does not work if you average all the instant speeds/paces for the lap. If you do so, you get an answer that's completely different from what Garmin shows in the built-in lap pace field, and you'll also see that the answer that doesn't line up with lap distance and lap time. But obviously if you just directly calculate lap pace from lap time and lap distance, there's no room for error (ofc you are making the assumption that lap distance is correct in the first place, but if it isn't, there isn't much you can do to improve on it [*]).

To be clear, any metric that can be derived from total distance (or lap distance) is better calculated from the total/lap distance (and probably the total/lap time), as opposed to adding up all the instant values and taking the average of that sum.

And indeed, you will find that things like average pace and average stride length, which can be derived from the measured distance and time, always line up with the measured distance and time, even though they rarely line up with the average of the instant values. This suggests that they are derived from the measured distance and time, and not the instant values.

Another data point for why I think instant pace and average pace are not related in the way you think:

- for very short laps (like strides or sprints), you may notice that the max pace (which is max instant pace) may be slower than the average pace. This obviously makes zero sense unless you consider that instant pace and average pace are calculated in completely different ways

[*] having said that, calculating lap pace from lap distance and lap time is fairly inaccurate at the *start* of a lap. It seems apparent that Garmin actually displays *instant pace* for lap pace at the beginning of the lap (like the first 30 seconds or so), so that's also what I did in my CIQ app

Simple example:

- you know that a runner ran 10 km in 40:00

What's the best way to calculate the average pace?

1) derive it from the known/measured time and distance. In this case: time / distance = 4:00/km

or 

2) add up all the individual instant paces that were recorded during the activity

With 1), you don't even need a Garmin watch or a recorded activity, just a time and a known distance.

With 2), it's very unlikely that you will get the correct answer of 4:00/km, regardless of whether the watch recorded exactly 10 km or not. (Unless again, you have instant value data with infinite resolution and infinite precision). In the case of smart recording, you may not even have data with once-per second resolution.

It's very clear to me from experience that Garmin chooses 1) for things like average pace and average stride length, which are based on measured distance and recorded time. Again it should be easy to convince yourself of this if you just do the calculations yourself and notice that average pace *never* deviates from (activity time / distance) and average stride length *never* deviates from (distance / (time in minutes * average cadence)). (except for small differences due to rounding ofc)

flowstate said:

My point is that I have good reason to believe that average stride length is simply calculated from activity distance (regardless of where it comes from), time and average cadence.

The overall avg. stride length is not used directly to estimate the immediate distance and pace. The algorithm does use the stored calibrated stride length, but in the real time it does not simply multiply the avg. stride length by the cadence. Instead of it, it adds a coefficient, increasing the stride length with the cadence, and especially with the acceleration amplitude.  Unfortunately, the coefficient seem to be way too agressive, meaning that depending on the arm swinging amplitude, or depending on the cadence (or the combination of both), and perhaps also depending on your physiognomy, you end up with quite overestimated or underestimated distance and pace data (both live and total).

When developing some of my analysis CIQ tools, I did many tests, and could clearly simulate greatly overestimated distance and pace, when I either extremely increased the cadence, or started to swing the arms much more violently with great amplitude, while keeping the same cadence (causing so greater peaks of acceleration). And oppositely, reducing the cadence, or the swinging, leads to an underestimated distance / pace. 

It is easiest to test the acceleration effect indoors, without GPS. If you keep running with the same pace (for example setting a fix treadmill speed), and the same cadence, you'd expect the same pace estimation from the watch as well. However, if you just start swinging the arms more aggressively, while still keeping the same cadence and pace, the watch will be fooled by the greater acceleration peaks, and will increase the immediate stride length, and hence evaluate it as a faster pace (which is finally comprehensible). In the consequence, the distance will be wrong, of course, too.

And it happens outdoors with GPS to a great extent too, and not only at completely lacking signal in underpasses, etc. Using HRM-Pro / 600 / Foot Pod improves this acceleration induced inaccuracy significantly.

That told, the algorithm seems to evolve - for example with my current Instinct 3 it seems to work much better (though still not always accurately without the strap), than it used to with my previous Instinct 2. So there is a hope Garmin continues to tune it up.

Garmin is known not to standardize features / calculation methods / algorithms amongst models and even from one generation to another. They have a track record of fixing issues "on the spot" for the specific model while other models/generations might not exhibit said issue.

So my question is why do you think your experience with the Fenix 7 fully applies to Fenix 8? 

You:

- Don't train with a Fenix 8 - so don't have first-hand experience

- Don't follow an "athletic level" training plan and likely don't do varied training sessions (please prove me wrong if this is the case). 

I'm really starting to question what do you have to gain by trying to disprove our observed hard-data through hundreds of hours of athletic training - with your assumptions based on limited on-field use of a Garmin watch and pure speculation and stubbornness. Is your desire to prove someone wrong and yourself right, blinding you to the ideas / conclusions / assumptions you're obviously married to? 

Can you go ahead and apply your same logic to the activity below? 

Initial distance/pace reported by the activity. Initial Running Dynamics: 

GPS Track distance: 

Corrected activity distance/pace according to the GPS. 

Wouldn't it be a possibility to find a certain course  in a GPS friendly environment, then  using a separate tool like Google Mapsmeasure the distance, and then perform the above test to compare the initial Garmin distance and the RD track distance?

Hello,
that's an interesting issue / question. Even though my experience with the Fenix 8 regarding distance and pace accuracy has always been very good.

GPS accuracy has made huge progress with the fenix 7 (using all GPS and multiband) and still with the Fenix 8. My GPS tracks are always quite accurate, even when sometimes using GPS only.
The new thing with the latest watch models is that the algorithm is able to detect when GPS signal is degraded or bad, and when it is the case, correct it with data available from different sensors - (accelerometer, or even compass maybe). It even has a mode to adapt GPS accuracy to the environment to optimize battery life.

Knowing this, it would be a bit irrelevant to use accelerometer to calculate distance over a full course, considering GPS is the most accurate source. NOW - if you think, as a lot of stryd users do - that accelerometer is more accurate than GPS, it makes sense to use the accelerometer to calculate distance. But I really don't think that this is what Garmin's doing, unless - as I said - GPS signal is lost partially, or totally during the activity.

Eventually, I remember that there is a setting to "smooth" GPS tracks (in data recording settings) and avoid recorded points that "slide" too far out of the track. I don't know if it impacts calculated distance though, but I guess it does.

Maybe try to turn this off to see if you have any improvement.

I never said that you're not seeing issues. You obviously are. I also concede that different generations and lines of Garmin watches can behave differently

I'm not trying to prove you wrong or invalidate your experience at all.

I simply tried to explain that i don't think average stride length means what you think it does. Afaict, average stride length is just simply derived from total distance, total time, and average cadence. So seeing a bad average stride length in your summary does not give you any *additional* information that your run data is bad, beyond the fact that your distance is already bad.

If you bothered to do the math you would see that:

- average stride length in the summary is always equal to (activity distance) / (activity time in minutes * average cadence) (disregarding small differences due to rounding)

- average stride length int the summary is not equal to the average of all the instant stride lengths.

Again, Garmin has provided average stride length long before they provided instant stride length, and the calculation has not changed as far as I can tell.

[1/3]

EDIT:

idk why I'm being downvoted here for pointing out things that can be independently verified or disproven by anyone here. If you think I'm wrong, show me one example, just one example where recorded activity average pace does not equal time / recorded activity distance. Or one example where average stride length does not equal [recorded activity distance in metres] / [time in minutes * average cadence]

On the flip side, I'm fairly certain that if I choose an random activity any Garmin device at all, if I take the average of instant paces, it will probably not be equal to the recorded average pace. Same goes if I take the average of instant stride lengths for any activity - it will not equal the average stride length.

Again this should be obvious by the fact that average stride length was available long before instant stride length, in Connect. If I go out for a run with an old watch like 235 or 935 today and no chest strap, I'm fairly sure I'll get average stride length although instant stride length will be unavailable.

Sorry for trying to explain the actual significance of things like average stride length and average pace. There actually is no significance, other than that they're informative metrics which are straightforwardly derived [calculated] from other metrics which are measured, like distance, cadence and time.

Average stride length is just as good or bad as the distance, time and cadence that were measured.

Average pace is just as good or bad as the distance and time that were measured.

Since we are fairly certain that Garmin is great at measuring time and ok at measuring cadence (better if you have a strap or footpod for cadence), the main thing that makes your average stride length or average pace look bad is having bad distance.

My point is everything comes down to distance that was incorrectly measured. Bad average stride length and/or bad average pace are symptoms of the problem, not the cause.

Similarly, average pace is not derived from instant pace in the way that you think.

Even if it could be mathematically sound to add up all the instant paces to get the average pace, it does not work that way in practice. Another consideration is that things like instant pace are based on sensor data that has been filtered/processed. You're not getting the "raw" data. This is another reason that it's not feasible for average pace to be based on instant pace.

Again if you do the math you will see that:

- average pace in the summary is always equal to (activity time) / (activity distance)

- average pace is in the summary is *not* equal to the average of all the instant paces

[2/3]

Again if you take very short laps while you stride or sprint you will see that max instant lap pace can be lower than average lap pace, which again suggests that one is not derived from the other. If average lap pace were simply the average of the instant paces for the lap, it would be impossible for the max instant lap pace to be lower than the average lap pace.

If you really want to compare Garmin's idea of the GPS speed to the instant speed that's in the activity graph, to see how they differ, you could always export the FIT file and open it in fitfileviewer.com. There's a table called GPS Metadata which has the GPS speed ("enhanced speed" column) at each point of the activity. You can compare it with the Record table, which has an instant speed ("enhanced speed) column. Record is also full of "instant", timestamped activity values [like time, distance, HR, cadence]. I'm pretty sure that measured activity values which are changing from second to second are recorded here.

For me the instant GPS speed and the instant activity speed are quite different at every point, which points to things like:

- the accel possibly being used to augment instant speed

- filtering/processing algorithms being applied to the GPS speed that's recorded in the file

I don't know if that will help much (as I don't think you can average all the speeds to get the activity speed and therefore the distance *), but it might be interesting.

(*) I also don't think activity distance is derived from average pace but I think it's the other way around

Speaking of how GPS is inaccurate for short distances, I sped up a bit at the end of my easy 12k run yesterday. Nothing special, just ran at 3:30 - 3:45/km for a few seconds. The Record part of the FIT file more or less reflects this pace (but ofc it's in the original units of m/s). But the max speed in this part of the file is about 3.8 m/s (3:15/k) while Connect reports a max pace of 3:37/k. This proves that even the data in the Record table is filtered by Garmin.

The GPS metadata table shows a max speed at the end of about 4.467 m/s (~2:47/km) which I know is a lot faster than my max pace for that run.

This is an example of how the raw GPS data is not directly used for speed, but it's filtered/processed somehow. (And I'm sure you would all agree with that).

But actually, in this case at least I think the (processed?) instant speed in the Record table is more realistic than the GPS speed in the GPS metadata table. And the speed from the Record is closer to what Connect displays.

Another example is that the relative speed changes in the Record table lag behind the speed changes in the GPS table by a few seconds.

All of that is to say that there are at least two concepts of instant speed/pace recorded in the FIT file (instant speed from GPS metadata and the instant speed in the Records table). The speed in the Record table is closer to what Connect displays, but it's still not the same.

Can you see why it's not sound to add up up all the instant speeds/paces to get the average speed/pace? These values are already heavily filtered/processed. And again, if you were to add up all of the instant speeds in the Record table and average them, you would find that it's not equal to the average speed/pace reported by Garmin. But the average pace reported by Garmin is always equal to the activity time / distance, which is actually pretty sensible to me.

Adrian s said:

- Don't follow an "athletic level" training plan and likely don't do varied training sessions (please prove me wrong if this is the case). 

I'm not a good runner (best HM is 1:34), but ofc I've done varied training sessions like long runs of easy to moderate intensity, long run workouts (e.g. long run with tempo segments), easy runs, straight tempo runs, and intervals (e.g. track workouts with reps ranging between 100m to 2 miles, hills, etc.)

So I've seen data for realistic instant paces and activity/lap paces ranging from about 2:30/km to 6:30/km.

Yeah, obviously I've seen cases where the data is obviously wrong. Particularly I've seen many cases where my instant pace / max instant pace is way too fast, usually due to GPS error (like running under a bridge).

I'm just saying I don't see systemic inexplicable differences like you do, where the GPS track length is wildly different from the reported activity distance. Since you're seeing that, it seems like something is very wrong.

[3/3]