What about Gradient Lag?

I'm lost. What is this thread about? Gradient lag or elevation accuracy?

Gradient comes from elevation. There is an elevation lag which couses gradient lag and total ascent shortage

Michael_Kalina, one of your complains is about the elevation/gradient lag, I watched one of your videos.
You have a 20-30 secs lag for gradient? That is how it was for me, and some other, last autumn (don't remember the SW version). It was fixed for you with 17.x but is back again with 18.x?

That is strange. For me (and some other in this thread?) I think it's 3-5 secs lag for gradient with 18.x. I think there must be something bad with your unit. I don't know how the algorithms work for elevation and gradient. But if DEM-data is involved perhaps that works different depending on where you are biking?

The longest lag I have now is when I reach a flat after a descend, it seems to be rather slow before it finally shows 0%, that is not a problem for me since I can see I'm on a flat. I don't look so much on elevation/total elevation, the dynamic gradient is what matters for me on an ascend, and there I think it's good/quick enough. It can be better, but it's acceptable IMHO.

The fact that you get a noticeable difference between the units total ascend and when you let GC adjust the elevation data is understandable. In my diagrams you can see that the elevation is recorded with decimals, you can see changes less than 1 meter. I think the unit takes that in account but when "adjusting elevation" from some data it's not that sensitive.

I thought we knew that DEM data is not involved in gradient calculation? But agree that elevation sensor lag wasn't the reason for the long lag being discussed in this thread - it was a design choice to smooth out and increase accuracy... which only worked on medium to long climbs.

I personally don't pay much attention to gradient, I only ride roads and can tell roughly what it is to within 1-2%. It's sometimes of interest on a new road or if you sense you're on a false flat. But I still think 15 seconds lag was crazy. Haven't tried it on 18.32 myself yet.

I know, DEM data shouldn't be involved. But as you wrote, the lag before it was fixed was totally crazy. It just can't take that long, up to 15 secs, to "smooth it out" I think no matter how bad they write the algorithm, something else must have been going on. And as you can see in my diagram from last autumn Fenix7 didn't have the same problem with the big lag.

That's the reason why I thought that maybe 1040 was checking data from the barometer(?) with DEM data before it dared to show it on the unit. The even more crazy thing is that before when there was this problem it was adding another up to 15 secs lag to show the gradient, as it was doing all the calculation again for that. I had 20-30 secs lag for gradient, compared to 3-5 secs now.

I will look at the profiles, but as RobCCC posted those values are within what would be consider an acceptable range between units. 

This thread did get hijacked from a discussion on gradient lag to one on elevation lag. If a unit where to have elevation lag it would make the gradient lag appear much worse.

@Michael_Kalina Based on the number of posts you have made on this forum about this I'm assuming that you have been in contact with Garmin and that this is high priority for you. Looking at the data and the level of pain that this is causing you I would say that if Garmin were to offer you a replacement unit then take it. Even if you don't think it is hardware issue taking the unit eliminates that possibility. To me it looks like a problem with the unit you have that will not get addressed by software updates.

Perhaps you have tried this, don't remember all posts. But have you tried "Device reset"? Perhaps something went wrong in some update. I think it can be worth trying, even if it's a little chance that it helps. I don't like such advice myself, to solve something on my PC, cell phone or whatever, but since returning the device isn't an option so...

One reason to test it is that it's very strange that you had no problem with 17.x, but now with 18.x you have it. If it's a HW problem it shouldn't have worked with 17.x.

Regarding missing total elevation. The latest test I showed in a diagram (page 52) was very short, with "quick" changes in elevation. The bottom of the hollow is only a few meters, and so is the top of the heights. But 1040 is showing pretty much what the total is, 22 meter. Fenix7 is showing 16 m, and 800 20 m. So my 1040 is more accurate than my Fenix7. As it shows in the diagram Fenix7 have almost the same elevations recorded as 1040, but for some reason it only have total ascending of 16 m. And I know it should be 22 m +/- some meter.

I also tried the "adjust elevation", that resulted in only 5 m in GC, and 16 m in Strava (same for Fenix7 and 800).