To everyone with "instant" Speed and Pace issues, please register a support case. Meanwhile, a new data field is now available which uses an alternative algorithm.

And here I have added a green line that shows "Average Lap Pace" based on GPS data (no accelerometer involved). It matches the built-in "Average Lap Pace" really good. Blue (the one based on "Pace") is way off from time to time.

AndersB said:

Which data field is that TobiasLj? 

It is one I originally created for Fenix3 (same discussions in 2015 about instant pace and GPS accuracy...). I've never managed to release it for F6 (rendering on the new screen dimensions doesn't work in all layouts) so I've just side loaded it onto my watch. It is still on my list to release it ;-)

You set the period (or distance) for average:
10s, 20s, 40s, 50s, 60s, 90s, 120s or 1km/mile

You set the peroid for trend average:
5s, 10s, 20s, 40s, 50s, 60s or 90s

The pace average can be calculated using three different methods:
Average of every single speed reading during the period.
The average of every delta distance during the period.
The total distance during the period.

For 1km/mile average it is always calculated using the elapsed distance and elapsed time for the last ≈km/mile.

TobiasLj said:

Do you use a HR strap with running dynamics (or a separate RD pod) or is the cadence based on accelerometers in the watch only?

Only accelerometer in the watch.

I fully agree with conclusions made by AndersB and observe the same pace issues very regularly. And actually even Garmin agrees with that. They have a support case which they mentioned to me when I contacted them about a similar issue - they said they added me to that support case. But whether anything gets done about that is another question.

I have now looked at your .FIT file which used Stryd for Speed and Distance. The "Average Lap Pace" for each 1 km was identical (blue line is hidden behind the yellow line) to the calculated "Average Lap Pace" based on the "Pace". So the Stryd clearly can match those two data types.

When I compared with an own calculation of the "Average Lap Pace" based on GPS data only (green line) I see some differences at km 3 and 4. Stryd measured a slower Pace there than GPS. Otherwise it looks good! 

But it would be better results in the comparison with a shorter Auto Lap Distance. And maybe only measure Speed/Pace by the Stryd and use the watch for measuring the Distance.

Ok, sounds like an interesting data field. Maybe you can put in some intelligence to identify Speed/Pace changes and shorten/extend the averaging depending on running metrics.

Hopefully they correct this in some way. I'm holding my thumbs! 

I did a short walk this morning and tested to manipulate the Pace just by using more arm force while walking. Success. It works, no need to increase cadence. More arm force gives a faster Pace.

Also interesting to see that the algorithm in the watch seems to compensate for the manipulations afterwards. 

AndersB said:

I did a short walk this morning and tested to manipulate the Pace just by using more arm force while walking. Success. It works, no need to increase cadence. More arm force gives a faster Pace.

That isn't hugely surprising if you are trying to infer pace from accelerometer movements.

I think you need to be careful in your approach to Garmin - I think if you include fringe corner cases that people in the real world will never actually do, you don't help your case IMHO.

I agree that a user setting to enable / disable accelerometer input for pace / distance calculations may be useful for advanced users.