1030 + gradient issue

I find it funny how they are crying they don't have enough data to analyze this but when you specifically offer to do whatever they need they completely ignore you - like they know that this isn't fixable and are trying to sweep it under the rug as much as possible.

lovesickoyster said:

I find it funny how they are crying they don't have enough data to analyze this but when you specifically offer to do whatever they need they completely ignore you

To add a little more clarity to my statements, which I admit I should have done, I last reached out to two dozen users, many of whom publicly posted here that they were willing to help. Only one user responded with any of the requested logs which has unfortunately not been enough to diagnose this yet. 

I am now reaching out to more users who have posted again they are willing to help and I hope they are able to provide the requested logs. 

I am genuinely sorry that everyone here are seeing issues with gradient inaccuracies and lag, but these requested logs are necessary to resolve this. 

It is not clear to me which log files are meant, and what such files are supposed to help anyway. To be able to check the gradient delay, one would have to know the real profile of the track in detail and the gradient display would have to be logged in a file. Neither of these is the situation.
It would be so simple:
Get a software product manager/developer on a bike, let him ride a hilly route and let him observe the gradient display.
Simple as that!

mcinner1 said:

It is not clear to me which log files are meant, and what such files are supposed to help anyway.

I will look back through my messaging but I believe I have been stating what logs/csv files are needed. My apologies if this has not been clear for folks and I will work to address that. Also, I will seek clarification on if any additional info would be helpful but adding the .fit file from the corresponding ride would certainly not hurt. 

mcinner, there is truth in what you say, they are going to have to infer from other data.  I have a file I am going to send that shows me outputting 50 watts whilst doing 13km up an 17% slope!!  What has actually happened is that I have created the hill and so my power is right down but the Garmin still has me on the hill because of the lag.  If I was not running a power meter, and its a Garmin one, then that would not be apparent.  Perhaps their inability to replicate is that they are not cross referencing their data.

I do agree with you though get someone on a bike and they would notice it.

There is lag also at climb pro, climb pro always finish before actual real climb , you have the message "climb finish " but you have to pedal 50-70 m ( i am not sure) , I am afraid that is something corelated with the lag for gradient

krazyeone said:

There is lag also at climb pro, climb pro always finish before actual real climb

I cannot confirm that behaviour. Maybe it is more a problem with the elevation profile of the loaded course.

There is one more thing I've noticed in the last few days, the lag seems to be more extreme at the beginning of a climb and then slowly reduce or go away completely. This creates a very uneven gradient, frequently exceeding 10% at the beginning of the climb as shown on garmin-produced files. Examples below, first two were recorded with a wahoo bolt, the last was recorded with the 1030+ - as you can see the first two are very consistent and the garmin's lags behind until a certain point and then catches up.

I road a large climb yesterday (2000+ feet) and didn't notice the delay getting better as I rode.  I've submitted debugging logs to Garmin and suggest others do the same.