What about Gradient Lag?

I have read the whole (I think) thread, can't remember any good explanation why the lag for gradient  is there, or I missed it?
Have Garmin officially explained why the lag is there, or do you mean that common forum members have come up with an explanation?

I don't buy that Garmin have planned for this lag on 1040, "Ok, for the new 1040 we want a 15s delay of shown gradient, let's see what HW/SW we should use to accomplish that". I think they noticed this when all was already in production, and the reaction was "Oups, we must come up with a good story to explain this".

Any person that do bike a lot and are interested in the shown gradient can't come up with an idea that "let increase the delay of the shown gradient". I assume that there must be at least some person higher up in the Garmin organization that are using their products while training on bike, and is involved in development.

As I noted above in earlier response to you: the Garmin Tech with whom I spoke said the amount of data gathered and the more complex algorithms are slowing the processing and creating the delay in displayed Gradient. To that I say: build the devices with better processors.

Ok, thanks.

However, I don't think it make sense. There is a lot going on in the same time. Navigating (if you use that), communicating with all sensors, calculating a lot parallel to show all of the data fields. So why should there be a delay only for the gradient caused by "the amount of data gathered and the more complex algorithms". If that is the explanation I think there should be a delay also for all other functions.

As an example, now they have fixed the GPS-speed, it is almost as quick as when you have a speed sensor. The tech guy you spoke with mean that calculating gradient is so much more complicated than GPS-speed, with a factor of let say 30 or more (I think the lag for shown GPS-speed is less than 1 second). No, it doesn't add up. I still think it's just a story they made up.

That’s just bad programming.  Why would anyone release code that slows down device functionality 

To save battery?

, to calculate how meters you have to climb?

because programers are not cyclists ( by how did designed workout page and strava segment page)? And they thought that is nice to have gradient smooth at 20"? As a feature?

i don't know , just a guess  

Cool so you buy new powerful car, bigger engine , but its running slowly that the older one

Just to share some findings from my little test. I compared a few devices on a little hill next to me. Polar M460, Garmin 530, 1040 and epix 2 base. The polar has the incline to the 0.0. It was the fastest to react but the epix was not far behind, if not on par. The 530 was more or less the same with 1040 witch was a few seconds behind the first pair most of the time. Some times more, some less. Soooo. If the gradient lag is none existent on the epix, let's home they can come with some kind of solution for the edge. Although as we know the Outdoors and Sports departments are separate entities at garmin, some only time will tell how they will tackle the problem. On the other hand, 1040 was noticeably faster on the speed department. All the other devices lagged a second or two behind all the time. On 1040 it was almost instant.

Edit..

Just to clarify, all devices were on their most recent FW.

Garmin's solution: Fix Epix gen 2 so it will have the same lag as 1040, then it will also be "within expectation"?

Best comparison would be with the Karoo 2. This was my device before I bought the 1040 (mainly because of the much better battery life and ConnectIQ). Gradient change was always in "real time" with the Karoo 2 and a few months ago they even enhanced the gradient KPI with 1 decimal (which also seems to be very accurate in my opinion). When I find some time I will install a second mount on one of my bikes and try to make a video with a 1:1 comparison.

Beware , Garmin will say that Karoo instant gradient it's not normal, normal is 25 lag delay