Instantaneous pace steady but slow (possibly since 19.20 software update)

Thanks for showing the elevation - it helps to have context. i still do not really understand the speed reported from your data field - so looking at the elevation, it shows they are climbing a hill but it had levelled a bit, but still a climb and cadence has dropped.

Intuitively I would expect pace not to suddenly increase at that point as we see 1) rising elevation 2) dropping cadence

So I do not really understand the pace spike - I think device speed is probably truer...is device speed what is reported on the watchface at the time of the run?

Yes, the device speed is what the watch shows (and records to the .FIT file) but it always records the speed in m/s. I don't know the running style for silentvoyager so hopefully he can see what's most accurate later on. It might be GPS position lag which causes this, or silentvoyager take longer strides uphill (intervals?). If you look at the  non-averaged 1 sec GPS speed (the thin grey line) it looks like the speed increases there.

For those spikes I highlighted, you can see GPS speed has distinct two spikes - maybe there was a real sudden speed increase, but I would suspect as it is a very brief spike, it is just the variance between one fix and the next.

My feeling actually is that whatever smoothing Garmin is doing here in this sort of 'spikes' scenario is probably a good thing....if the device was reporting raw or even 1 second GPS speed that would be very annoying if you wanted to use pace alerts!

On this screenshot the spikes are zoomed in better. The first green spike is an increase of about 1.3 m/s (over 9 seconds) and the second green spike is an increase of 0.6 m/s (over 7 seconds) so its not from one second to another. But it might be GPS position lag that causes this and silentvoyager is probably the one who can answer that. There is no information in the .FIT file that I can use to identify that, what I'm aware of.

Thanks, for some reason I assumed I was looking at 1 second spikes, which was silly of me.

Yes, as we didn't run this ourselves, it's hard to comment if they really did increase speed at that point. The cadence certainly suggests they did not, unless they increased stride length at that point.

I think SilentVoyager is on the other side of the Atlantic than we are, so we will have to wait in suspense for their reply :)

5135968 said:

the drop-outs you show there are very clear and obvious - where pace is consistently below your real speed for several minutes that wouldn't be acceptable for me.

That is pretty typical when running on trails in my area. Lowland trails here tend to be in old growth forests with tall evergreen conifer trees (cedars, firs, etc). Also, because it is trail running and pace tends to be highly variable, I think my Fenix 6X has really hard time calibrating the accelerometer based pace, so when it can't fully rely on a good GPS signal, I see pace like this most of the time. Whatever assumptions Garmin makes about calculating pace, they don't work for me at all. But when running on an open terrain, pace is usually acceptable. 

5135968 said:

Intuitively I would expect pace not to suddenly increase at that point as we see 1) rising elevation 2) dropping cadence

So I do not really understand the pace spike - I think device speed is probably truer...is device speed what is reported on the watchface at the time of the run?

Neither device speed nor GPS speed is correct in that place. The part of the run that you highlighted above is where a little climb is almost done and it is fairly flat there. But in fact even in the beginning of the climb where my speed was at its lowest point, I was really surprised to see my watch showing me running slower than 14 min/mile, which is close to 9 min/km. Surprisingly GPS speed agrees with that but I think that is still incorrect and in reality I was running quite a bit faster, perhaps no 11-12 min/mile. I know what 14 min/mile is because I can easily walk that fast.

I think that even GPS speed produced by looking at distances between the logged positions doesn't reflect the true speed. That particular part of the run was in the most densely wooded area of the park. When Fenix fails to refresh GPS position, I think it starts to fake positions using dead reckoning algorithm. What happens next is that that creates a positive feedback loop where previously incorrect speed starts influencing positions and affecting the distance (e.g. positions get closer to each other than they should be), and that in turn starts affecting accelerometer calibration, and that in turn prevents the speed to pick up until there is a good GPS signal. I've seen a similar effect in my underpass example earlier in the thread.

Now if you see that very sharp increase in speed, that is where I existed the wooded area and ran into a clear space with open sky. That, without any change in my actual pace, increased the device pace by 3 min/mile within a few seconds. That is because the watch finally had a good GPS signal and the position jumped ahead more than it should have. Actually, shortly after that you can see the watch overcompensating, with the device speed staying higher than the GPS speed for about a minute.

I've seen a lot of other evidence that the GPS positions logged by Fenix are heavily processed / interpolated. Often I see the logged track entering turns several seconds earlier than where an actual turn goes. In one recent example I saw it turning 8 seconds earlier, which I estimated based on my speed and distance to the actual turn. I think, considering, unreliable GPS reception, Fenix starts buffering whatever positions it can get from GPS and then every second it generates an interpolated position which is on a direct line from a position buffered several seconds ago to whatever the recent position it has.

Here is another evidence that device GPS positions are interpolated. Consider the precision of coordinates - the number of decimal digits in the latitude and longitude.
Here is an example of coordinates produced by Suunto 9:

<trkpt lat="47.6833710" lon="-122.1057350">

And here is an example of coordinates from Fenix 6X:

            <Position>
              <LatitudeDegrees>47.52973096445203</LatitudeDegrees>
              <LongitudeDegrees>-122.0239807292819</LongitudeDegrees>
            </Position>

Do you think that kind of precision is realistic coming from the GPS chip? I don't think so.

See this discussion: https://gis.stackexchange.com/questions/8650/measuring-accuracy-of-latitude-and-longitude

• The tens digit gives a position to about 1,000 kilometers. It gives us useful information about what continent or ocean we are on.
• The units digit (one decimal degree) gives a position up to 111 kilometers (60 nautical miles, about 69 miles). It can tell us roughly what large state or country we are in.
• The first decimal place is worth up to 11.1 km: it can distinguish the position of one large city from a neighboring large city.
• The second decimal place is worth up to 1.1 km: it can separate one village from the next.
• The third decimal place is worth up to 110 m: it can identify a large agricultural field or institutional campus.
• The fourth decimal place is worth up to 11 m: it can identify a parcel of land. It is comparable to the typical accuracy of an uncorrected GPS unit with no interference.
• The fifth decimal place is worth up to 1.1 m: it distinguish trees from each other. Accuracy to this level with commercial GPS units can only be achieved with differential correction.
• The sixth decimal place is worth up to 0.11 m: you can use this for laying out structures in detail, for designing landscapes, building roads. It should be more than good enough for tracking movements of glaciers and rivers. This can be achieved by taking painstaking measures with GPS, such as differentially corrected GPS.
• The seventh decimal place is worth up to 11 mm: this is good for much surveying and is near the limit of what GPS-based techniques can achieve.
• The eighth decimal place is worth up to 1.1 mm: this is good for charting motions of tectonic plates and movements of volcanoes. Permanent, corrected, constantly-running GPS base stations might be able to achieve this level of accuracy.
• The ninth decimal place is worth up to 110 microns: we are getting into the range of microscopy. For almost any conceivable application with earth positions, this is overkill and will be more precise than the accuracy of any surveying device.
• Ten or more decimal places indicates a computer or calculator was used and that no attention was paid to the fact that the extra decimals are useless. Be careful, because unless you are the one reading these numbers off the device, this can indicate low quality processing!

Looking on your graph, the one dropout I have just described is at 1033 on x-axis. There is a small dip in the altitude graph at the same time. The trail goes into a small ravine, makes a sharp turn, then continues to climb uphill. This is close to my home so I can repeat that part of needed. But as I recall I always see pace dropouts there.

I guess I should add a FIT parser to my experiments. I used TCX because it is more convenient as a text based format. My end goal is to make a custom field similar to yours, but for now I have been experimenting with a python script on a historical data. I am actually an experienced software developer, but between work and running I lack time for this project. Perhaps during winter vacation I'll make some more progress.

Thanks for describing how the place looks. I've only looked and the numbers (not a map) and I can see some connections with the heading/bearing and the dropped pace. It looks like the pace often changes (mostly to a slower pace) when turns (faulty or correct) occurs. 

How is the view to the sky at the place at 1033? Is it a clear view to the sky in two directions (backwards and forward perhaps) and then blocked sky view to the sides? Its a real pity that Garmin doesn't give us developers better GPS accuracy/precision data to work with. This had been so much easier to solve then. Also accelerometer data seems to be blocked to use in data fields, otherwise that could have given clues on what's going on. I have a similar place like you on my standards run course so I don't think that I need more samples from the actual place.

Yes, a FIT parser or conversation tool can help you out I guess. You will get more data to work with. It will be interesting to see what you build later on. I'm also a developer but this project is more of a hobby for me and I work with it in the spare time. Its really interesting to dig into this, and hopefully we will learn something from it.