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

OK - It's obvious Garmin can improve on 'instant pace' as this it's clearly a lot worse than what other manufacturers manage.

Can your finding be used to improve real time pacing? Could it be implemented in a CIQ Datafield?

Have you sent your findings to Garmin support? I know a lot of people say this hoping to shut down discussion over controversial issues, but I mean this genuinely, as you are doing interesting stuff, especially if it's can be used to improve real time results.   

The Pace also seems to work different on different devices. On my old Forerunner 310XT its much better than on the Fenix 6X Pro. It is not as heavy smoothing on the 310XT but then its also fluctuating more.

Yes, there are good possibilities to get a better working Pace from this. But I dont know if Garmin wants to put effort to it. Most people seems to accept this built-in bad working Pace.

And yes, it would be possible to create a CIQ data field with better accuracy than the built-in Pace. A developer with knowledge about Monkey C should be able to do it. I am a developer myself but have never developed in C so i have a learning curve to do it myself.

No, I have not yet contacted Garmin support about my findings but i will as soon as i think that i have enough info and data.

The Pace Pro function is really good in theory but its impossible to use on my running tracks due to these issues.

I have downloaded the API and learned about it a bit. It seems developing a simple data field should be very straightforward. A simple data field doesn't need to deal with UI or graphics, or anything like that. It just needs to produce text output when invoked by the watch, and it gets access to all the underlying metrics collected by the watch - time, distance, cadence, altitude, etc. So yes, implementing a rolling average should be fairly trivial. In fact there is already a CIQ field like that called Rolling Average Pace.

https://apps.garmin.com/en-US/apps/28fdec7f-3807-4d24-b85a-4c86b40501f4

But a problem with a simple rolling average is that it is less accurate in more dynamic scenarios like starting and stopping, or switching between walking and running - it takes awhile to settle. 

It needs to have some intelligence if it should work in different conditions. A basic rolling average will not be good enough if we should handle GPS dropouts, sharp turns, 3D Pace, starts/stops etc. Its doable, but a simple averaging will not be enough. I can do the math, if you do the coding ;)

@silentvoyager ,  @AndersB 

I could give you some support if my time permits this. OTOH there is much support available in the developer/discussion forum.

So I suggest to try it, it's not so hard. There are many samples available which are included with the sdk for the first steps, which can be modified or extended. And you've access to many metrics to experiment with.

silentvoyager, do you have possibility to answer some quick questions?

Do you use GPS Only, GPS+GALILEO or GPS+GLONASS?

Do you have "3D Speed" and/or "3D Distance" enabled / On?

How do you wear the watch? Left or right wrist? Outer, inner or upper wrist?

Which type of HR strap do you use?

I can see some differences in my own statistics when I have tried different settings and also between how I wear the watch. 

AndersB said:

Do you use GPS Only, GPS+GALILEO or GPS+GLONASS?

Do you have "3D Speed" and/or "3D Distance" enabled / On?

How do you wear the watch? Left or right wrist? Outer, inner or upper wrist?

Which type of HR strap do you use?

GPS+Glonass

Both 3D Speed and 3D distance are off because I don't think it matters that much, and I remember reading that using 3D speed does further increase post-processing on Garmin side. On average I get about 100-200 ft of climb per mile (20-40 m per km), so the difference between having 3D metrics on and off should be well within 1%.

I wear the watch normally on left wrist, on top of wrist bone. When I run the watch face tends to be positioned somewhat skywards. GPS tracks actually don't look that bad.

HR strap is Polar H10, and I use it on more than 90% of my activities. The remaining ones use the built-in optical sensor.

Ok, thanks for the information.

When i look back in my stats it seems to have been less pace issues when wearing the watch on the inner left wrist. 12-o-clock pointing to the sky. 3D off and GPS+GALILEO. I use a Hrm Run strap.

But i have rather few activities with that settings and wear of the watch. So, i will try that on the next run to see if it have impact.

Most of my latest runs i have had GPS+GLONASS, 3D On and weared the watch on upper left wrist (on the wrist bone, watch face towards the sky).

I have also seen that the Vertical Ratio % seems connected some way. Im thinking that it might be problems with stride length or something.

GNSS preference depends on geographic location. I am in NW part of USA, so Glonass is supposedly preferred in this location and Galileo coverage is supposedly not so good. I can try GPS only and see whether that makes any difference. I used both GPS only and GPS+Glonass with Suunto 9 before and haven't noticed much difference.

Vertical ratio is a running dynamics metric which I don't have. I'd guess when this ratio is higher, stride is bouncier and stride length is shorter. Perhaps Garmin relies too much on stride length in their pace calculation which makes the pace drop. But I suspect the higher vertical ratio is just another indicator of the same underlying issue. Perhaps it is the stride length which is determined incorrectly, and that makes both the vertical ratio too high and the pace too slow. 

silentvoyager said:

erhaps it is the stride length which is determined incorrectly

I have no idea what they do, but I wouldn't be surprised if stride length isn't just distance over x-amount of time, divided by cadence. I don't see how you measure it from the wrist with any sort of certainty....?