Pace is not showing correct while running

silentvoyager said:

Let's take a look at the distance, time, and speed fields. What we can see that there is one sample per second. There are 25 samples total and the difference between the first shown sample and the last shown sample is 24 seconds. OK, now, let's look at the distance. The difference in distance is 2731.73 - 2657.7 = 74.03 meters.
The average speed for the shown samples is 74.03 / 24 = 3.08 m/s. Now, look at the speed column and tell me if you see at least one sample where the speed is even above 3 m/s. The fastest I can see is 2.958 m/s in two samples, and the rest are slower than 2.9 m/s. This enchanced_speed is what shown on device as pace during activity. 

And looking at this, I realise we have both made one assumption that throws us both.

Who says that distance is always forward? I.e is it distance from the start point, or distance travelled? If the errors in GPS are truly random, then for each point we say that (Garmin says) that the error is about 4 m. With a one second sample, and an approximate 3m/s speed, some points may show a little backward movement, or at least to the side.

So distance in that fit file may be along this crooked, Brownian path - calculated point to point from each point with associated error.. Whereas the speed calculated may be based on the smoothed path.

As you know the shortest distance between two points is a straight line. SO if the "distance" in this fit file is calculated point to point with positional scatter, it will be not be the same as the smoothed trendline distance. This "longer" journey over the same time will show a faster pace/speed than the smoothed trendline distance over that "straight" line over the same time. 


So for a path like
 /\  /
/  \/

over a second we go 1 second for 6 characters and for

---

we go 1 second for 3,

the pace for the first is 0.16 s/char and the second it's 0.33 s/char. So the unsmoothed, point to point will show a faster pace. That's very much an extreme example, btw :)

The fact the one is called "enhanced" suggests one may be raw and the other processed. That could explain the discrepancy, but until we know precisely how the data is processed, we don't know. The enhanced speed may be straight line, hence only showing 2.8/2.9m/s per point. But using the distance from point to point summed shows a further distance over the same time and yields the 3.08 m/s. This is all conjecture till we know the exact definition of each field of course :)

What we both know is that instant pace gives people migraines :) 

Ɛpsilon said:

What does help is a good algorithm (Fused speed springs to mind) and a good GPS antenna (The Ambits). But FusedSpeed still has its detractors for some people.

Suunto FusedSpeed algorithm is way better than Garmin's in my experience, even on Suunto 9 which has the same Sony GPS chip.

My main issue is not that Garmin's pace isn't precise. What bothers me is that it is consistently biased. So the picture you posted above doesn't in fact reflect the output. If you shift all those dots to one side - that's what Garmin's algorithm produces. As I mentioned, the original data coming from the GPS is accurate but not precise, but Garmin's processing of the data makes it more precise but less accurate.

I understand the problem is complex, and I have experimented with the algorithm myself using a small rolling window of samples to simulate the on the fly processing on the watch. I think the algorithm can be improved. 

If you look at the SDK documentation for the instant speed, it states the following:

Speed is derived from the most accurate source in the following order:

1. GPS

2. Foot pod

3. Accelerometer

https://developer.garmin.com/connect-iq/api-docs/Toybox/Position/Info.html#speed-var

It seems, Garmin's algorithm switches too eagerly from the GPS as the source to the accelerometer. And that I think is the main reason for both the bias and the sudden dropouts when running under trees. I observed that many times myself. My pace may be perfectly good, then I run into some trees, and now, within a few seconds, my pace gets 2 minutes per mile slower. That can't be explained just by the GPS inaccuracy.

Deriving the speed from only one source at a time is the main problem. A more accurate approach would be to continuously fuse at least two sources, in which case the result would be more accurate than either sources. That is called Kalman Filter and the way it could implemented in practice is weighed average of speed estimates from GPS and accelerometer where weights are continuously evaluated and updated based on distribution of recent samples of values from each source. For example, see this post:

https://stackoverflow.com/questions/55813719/multi-sensors-fusion-using-kalman-filter

It is really not a rocket science. The science for sensor fusion is well known. 

Ɛpsilon said:

Who says that distance is always forward? I.e is it distance from the start point, or distance travelled? If the errors in GPS are truly random, then for each point we say that (Garmin says) that the error is about 4 m. With a one second sample, and an approximate 3m/s speed, some points may show a little backward movement, or at least to the side.

If you think that the distance in Garmin FIT files represents the distance between points, that isn't true either. The distance is already smoothed and is always shorter (by up to 5%) than the cumulative distance between points. In fact the points are also smoothed by the GPS chip; otherwise, if every point position was taken independently, tracks would be extremely messy. GPS chips use speed vector to predict where next points should be. If you inspect GPS tracks, seeing points move back is extremely rare and only happens at very low speeds.

silentvoyager said:

If you think that the distance in Garmin FIT files represents the distance between points, that isn't true either. The distance is already smoothed and is always shorter (by up to 5%) than the cumulative distance between points. In fact the points are also smoothed by the GPS chip; otherwise, if every point position was taken independently, tracks would be extremely messy. GPS chips use speed vector to predict where next points should be. If you inspect GPS tracks, seeing points move back is extremely rare and only happens at very low speeds.

Which also highlights another issue, we really dont know what has happened to that \fit data re processing. Would be very interesting to see purely raw data. Also weird that the 5% value seems to also show up in the differences between the large scale pace and individual paces shown within

silentvoyager said:

My main issue is not that Garmin's pace isn't precise. What bothers me is that it is consistently biased. So the picture you posted above doesn't in fact reflect the output. If you shift all those dots to one side - that's what Garmin's algorithm produces. As I mentioned, the original data coming from the GPS is accurate but not precise, but Garmin's processing of the data makes it more precise but less accurate.

I understand the problem is complex, and I have experimented with the algorithm myself using a small rolling window of samples to simulate the on the fly processing on the watch. I think the algorithm can be improved. 

Have you considered liasing with Anders, who is writing his own data field? May be fruitful....

Suggest you guys try out a Forerunner 745, the GPS is a lot more accurate and running pace is stable.

Best explanation yet. Garmin support couldn't seem to answer this. They suggested I use a running pod, then a HRM. I still had inaccurate real-time pacing. This is really frustrating because I depend on real-time pacing during events. I  certainly hope they will be sending out a patch soon. Thank you.