This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

What about Gradient Lag?

Can anyone report if Garmin have fixed the issue that the 1030+ has with ridiculously long responses to changes in gradient?

  • It does not, the gradient shown while riding is not saved in the track. Even if it were, we have no way to know that it's saved in the track at the same time it is displayed.

  • Hey , I saw you downvoted some of my postings, one of them with appr the same as a post from camillo.vezzoli which you upvoted. You are of course free to do that, but I'm a little curious what it is you don't like?

  • Tried a few, they were faster but highly inaccurate. Moreover, gradient is shown by Garmin in various places (like in ClimbPro) and this field would not show in those places

  • Just syncing a video to the recorded GPS track unfortunately isn't going to demonstrate the issue most people in this thread are complaining about. What you actually see on the the Edge screen while riding. You need to use the technique GP Lama (Shane Miller) uses in his videos, it's possible to continuously capture a screenshot of the Edge head unit  every 2 seconds I believe these are saved on the unit (Hundreds of files). You then have to extract them from the unit and sync them with your GoPro footage and and GPS data from the Edge unit, put it together so the screenshot "sequence" is an overlay on your video and you can demonstrate what you would see on the Head unit while riding in relation the video footage. A time consuming process that I admire GP Lama does very effectively for his YouTube audience.

    The only problem I believe is the secret command needed to to get the screenshots capturing every 2 seconds is only available in Beta Builds not the GA released software.

  • Screen capture is at 2 Hz

  • Sorry an off-topic question - is it possible to stop the daft "top replies" thing from showing up? It makes reading these threads a total mess.

  • Your first point I totally get. I would assume the 2nd we would have to take on trust but it's a moot point if the data isn't even there and that is being calculated after the fact.

  • You need to be a little careful when comparing across different generations of products and trying to extrapolate that.

    The current generation of watches and Edge units (FR955, FR965, Fenix 7, Edge 1040, 840, 540) basically all write out the elevation value you see displayed on the unit. There should be limited in any elevation lag.

    There was a period on some of the older models where the displayed and the saved value could differ as there was some background filtering going on with the value being written out.

    Because of the above you need to be quite careful how you process those older FIT files as there are actually two different elevation data values being tracked.

    For the basis of this thread the current units display what they store and there should be no noticeable lag in the change of the elevation value.

    If you are are comparing the elevation plots across multiple Garmin products and see a marked difference in the shape of the elevation profile or an offset on the X-axis when plotting elevation over time/distance then there is good chance you have some type of hardware issue on one of the units.

    This could be a barometric port blockage that is preventing the pressure level equalizing quick enough as the pressure changes. This would give an x-axis offset, but the elevation values would eventually align if you stayed in one location long enough.

    The second issue could just be a faulty barometric sensor. If the temperature reading is way off that could also indicate a barometric sensor issue as they are part of the same chipset.

    If anyone would like to share comparative data collected on 2 or more units on the same activity I'm more than happy to take a look.

    As an example here is my ride today using a 1040 and FR955. The units track closely and the values are within an expectable variance.

  • <5% seems within tolerance for consumer hardware to me