Instant pace is not accurate and has bias towards slower than actual pace

subra said:

the calculation of instant pace and lap pace are performed with different algorithms

The lap speed is simply the lap distance divided by the lap time. The lap pace is then directly derived from the lap speed. 
Or alternatively, the lap pace is the lap time (in minutes) devided by the lap distance (in km or miles), which is still the same as above.

Of course, I haven't denied this.

Lap pace is
speed_lap = distance_lap / time_lap
pace_lap = 1 / speed_lap

Rather I mean lap speed doesn't need averaging/smoothing, since it is already an average of the samples incl. the GPS position error.

But instant pace is
speed_inst = distance_delta / 1s = distance_delta
pace_inst = 1 / speed_inst

Since the watch always works with a tactrate of 1s, the instant speed is only one sample, which is exactly the distance between 2 lat/lon's incl. the GPS position error. This may be oscillating due to the GPS position error and therefore should be smoothed/filtered.

Garmin's instant pace is certainly not derived directly from the distance delta over one sample. Intuitively is what it should be, but distance deltas are quite noisy. Even something like 10 or 15 second rolling average is still fairly noisy. I have actually done quite a bit experimentation parsing activity files and trying to smoothen instant pace in various ways to see if I could implement a better algorithm for instant pace and perhaps program a custom CIQ field.

There are some methods that give a bit better accuracy (i. e. closeness of values to each other). For example a moving least squares linear regression mostly takes care of the outliers, but it requires a longer interval (more samples). Meanwhile if we do that, pace starts being quite inaccurate around stops or any sharp changes in speed. It is clear that Garmin certainly mixes cadence into the formula.

Bit whatever algorithm Garmin uses, I think it was aimed at walking speeds where the relative GPS error is even higher than when running. That is the reason instant pace is based mostly on cadence. 

I know everyone moans about Garmin pace but grass is not always greener in the footpod world.

For pace, my V800 still takes a lot of beating

Pace from footpod in image below - odd dropouts and very choppy. I ran as usual also with my Polar V800 too and I found the GPS pacing very good - I assume Polar smooth their GPS so with V800 zonelock and pace zones I prefer V800 pacing to Stryd, if you pace via alerts.

The latest screenshots was from a 19.5km @ ~2 hours slow run/jog on a gravel road with some twists, some hills, some open areas and also some tree cover from time to time. But not a trail. 

The deep outliers seems to be caused by short GPS pace dropouts (poor signal) and the pace has hard to recover after the dropouts. This must be a bug in the algorithm.

Yes, more tests and calculations is needed to get a good grip of the issues. Here is some comparisons that I have made.

Lap Pace vs built-in Pace

'

Lap Pace vs Pace calculated by record.distance[m] Delta (RAW)

Lap Pace vs Pace calculated by record.distance[m] Delta (10 seconds rolling average)

Lap Pace vs Pace calculated by record.distance[m] Delta (30 seconds rolling average)

Lap Pace vs Pace calculated by record.distance[m] Delta (60 seconds rolling average)

Lap Pace vs Pace calculated by GPS semicircles (RAW)

Lap Pace vs Pace calculated by GPS semicircles (10 seconds rolling average)

Lap Pace vs Pace calculated by GPS semicircles (30 seconds rolling average)

Lap Pace vs Pace calculated by GPS semicircles (60 seconds rolling average)

And the last one is built-in Pace (blue line) vs Pace calculated by semicircles (60 seconds rolling average) (green line)

So, it looks like the built-in Pace is something like a 60 seconds rolling average from the GPS. But with some occasional odd twists... I will look if I can figure it out later on. Maybe the watch compares GPS speed with stride length/cadence and if the difference is to big it fails over to the best plausible at the moment. And maybe also the GPS signal strength is part of that comparison. Something is clearly not working well.

And here is a comparison between the built-in Pace (blue line) vs Pace calculated by Cadence and Step Length (10 seconds rolling average) (dark red line)

I'm not 100% sure that I understand you correctly but I am analysing the .FIT files which includes some data that I can use to calculate this way. For each second of an activity we have a log for record.enhanced_speed[m/s], gps_metadata.enhanced_speed[m/s], record.distance[m], GPS position (and altitude), cadence, step length etc.

We can use all (or some of) this data to calculate "instant pace" or an averaged pace over xx seconds.

@AndersB am not explaining myself well - sorry

So lets define instant pace - it's the 'real time' pace that is shown on your watch during your run, and as you know it can change very frequently - do we agree here?

So if we are agreed on that point, I am not sure you can say that take a complete file and then go back and with the benefit of a full and complete GPS track retrospectively try to say pace was wrong. Simply because watch 'instant pace' is calculated at one moment in time, whereas you are calculating with the benefit of a full track, so it goes without saying you are going to see different results if you have a full .FIT file to process vs. data gathered in real time during the run.

I am not at my most articulate today, sorry!

We are speaking of the Pace which is shown in the Pace Data Field on the watch and also the Pace diagram in Garmin Connect. Its called record.enhanced_speed[m/s] in the .FIT file which is then converted to Pace. That value is heavily smoothed/averaged and not "instant" in a real way. And sometimes also very wrong compared to real Pace. 

Yes, I can calculate the Pace between each data point in the .FIT file (and of course also smoothed and/or averaged over time). And yes, I can prove that the Pace Data Field on the watch was wrong when the Run activity was done. Its not magic, just plain mathematics :)