While this def looks like a bug (especially if it coincided with a firmware update), couple of things that haven't been mentioned:
- I don't think Garmin calculates lap average pace (or activity average pace) by literally averaging all the current/instant pace values [*]. I think they calculate average pace by dividing time by distance.
[*] I actually tried to do this for one of my first Connect IQ data field apps, when I had to manually calculate lap average pace, since it's not provided by the CIQ API. I quickly found out that method doesn't produce a result that's the same as the native lap average pace, but dividing lap time by lap distance does.
So if your have 1k auto-laps (for example), I would expect your lap pace in min/km to always be exactly the same as your lap time (disregarding rounding). Similarly, if you ran 5k in 20:30, I would expect your activity average pace to be 20:30 / 5 = 4:06.
BTW, you can do math with times and paces in Excel or Google Sheets, as long as you enter times/paces with a leading "0:" when the hours value is not present. e.g. In Excel or Google Sheets, 0:20:30 / 5 is 0:04:06 and 1:30:00 / 21.2 = 0:04:15. So you could use a sheet to verify whether your lap / activity average paces are being calculated properly, especially for any lap distances which aren't equal to 1 km / 1 mile (depending on whether your units are km or mile).
For the activity in the OP, I would be very interested to see the lap times and distances.
If the lap paces aren't equal to lap time divided by lap distance, I would say it's def a bug with lap paces. If the lap paces are correct, then the instant pace values must be wrong.
- OTOH, current/instant pace is estimated every second by the watch (from GPS or accelerometer). Notice how the current pace data field on the watch is always rounded to the nearest 5 seconds (e.g. 4:35, 4:40, 4:45). This is because Garmin doesn't consider current pace to be very precise.
That's why if you have very short intervals (like 15s strides or sprints), you'll sometimes see nonsensical stats like best pace for a lap that's lower than the average pace - because instant pace isn't being estimated properly in that case, and best pace is the best instance pace.
That's also why I don't think it would make sense for Garmin to average all the pace values - if you actually did this for an activity, you would probably never get an answer that's exactly equal to time divided by distance (as I found when I tried it with a CIQ app)
And notice how the lap pace and (activity) average pace data fields are *not* rounded - they're displayed to the nearest second (e.g. 4:35, 4:36, 4:37). This makes sense in light of the assumption that they're calculated from time and distance, and not by averaging all the current paces.
- It's also possible to get distance, speed/pace, or both from an external sensor, like a footpod or a Garmin HRM-PRO chest strap.
I'm fairly sure that if you use an external sensor for speed, but not distance, then your distance (and therefore average pace, which is time / distance) will still come from GPS or the internal accelerometer, but your instant speed/pace will be estimated by the external sensor.
As a contrived example, if you run indoors with a footpod, but you only set the footpod to provide speed but not distance, there's a possibility that the footpod will provide much better (or worse) speed estimates compared to the internal accelerometer's distance estimates, meaning that you might see an inconsistent lap pace vs instant pace graph like in the OP. I'm not saying that's what's happening in the OP, especially since it only started happening with a firmware update.
But I can think of a way someone could easily force the problem to happen (assuming that my assumptions above are correct): just enter a wildly incorrect calibration value for a footpod or HRM-PRO chest strap, and use the footpod/strap for speed, but not distance (use GPS for distance and run outdoors). If you do that, you should instance pace that's egregiously bad, but your average activity pace and lap pace should still be correct, leading to a weird graph similar to the OP.
(sorry for the multiple replies, the forum is still acting up - it's blocking posts which are too long)
