Related
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?

keoltag
over 2 years ago

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

  • 0 over 2 years ago in reply to djwalker1260

    @djwalker1260 is right. The grade lag in the examples in this thread are outlined in our FAQ: Why Does the Grade Percentage Lag on My Edge Cycling Computer?

    If anyone has any examples of longer lag or a video, I would be happy to review it.

  • 0 over 2 years ago in reply to djwalker1260

    @djwalker1260

    re. “Clearly the altitude and distance parameters can be fiddled with and I imagine that Garmin has done work to optimize speed while not having a lot of false changes.”

    Well, clearly the problem exists STILL, and clearly the problem did NOT exist in the Edge 1000 - therefore clearly, they have not been “fiddled with” enough by their engineers, and clearly, you may be satisfied but clearly, so many others of us customers are not satisfied with what they’ve done to-date with the 1030+ and 1040 Edge units re. gradient change responsiveness and altitude reliability/validity!

  • 0 over 2 years ago in reply to Garmin-Matthew

    @Garmin-Mathew.

    If you really believe that 10-15 seconds delay is considered “normal” - as the official statement from Garmin is trying to force-feed customers, then what does that say about my Edge 1000, which responded almost immediately all these years to any slightest gradient changes??

    Btw, Wahoo and Hammerhead Karoo do not consider 10-15 seconds delay in responding to gradient changes, anywhere near “normal”…

  • 0 over 2 years ago

    No it doesn't, it's sometime embarrassing how long it take to 'see' a large change in gradient.

    Where I live I have often some rapid descent and followed by rapid climb, for rapid I mean 15/20 sec of descent and 40/60 sec of climb that can reach 12/16% of slope, in this time my 1040 reach the correct value at the end of the climb and anly if it islonger than 40s!!!

    With also a gyroscope inside the 1040 now, Garmin have to improve this damn slope!

    Anyway as I got some time to produce a video or picture I will post here on the forum and on youtube to stimulate the attention from Garmin, and I would suggest to all people there can take some time to test their unit to do the same.

    The 1040 cost too much to have this ridiculous problem, and should be improved as a flagship for cycling from Garmin.

    Thanks.

  • 0 over 2 years ago in reply to gigas10

    I agree with you, there are some pretty vicious speed bumps in France, but nothing that would cause that.

    Looking at the maths: a 1M rise @ 5% would be a distance of 20m travel. Subsequently at 24Kmh, that would take 3secs (or 2secs at 30Kmh+). - Hope the maths are correct, update if not.

    This is ample time/distance to update the 1040 gradient. I think most people would be Ok with a 2-3sec delay for it to see/calculate and update the data field.

    Garmin and the apologists haven't really got a leg to stand on, especially as it's the same as my 1000 - i.e. they've had at  least 8 years to sort out the top-of-the-range GPS for this much reported annoying issue.

  • 0 over 2 years ago

    I currently have a wahoo element (full size) a karoo2 and now a 1040 solar.  as of the 12.14 release the 1040 solar still has a ridiculous lag as compared to the other two.  I really don't care too much, as what the screen says and what I'm actually doing with my legs really doesn't matter as only the effort counts, but the lag is laughable at best and stunningly bad at worst.  Just last week after the 12.14 beta I was laughing because I was easily a minute past the 14% and solidly on 6% when it was still showing me 14% and I was on flat 0 percent for a very long time while it was still showing me 6%.  The initial 14% was showing 3 for a very long time

    so yea, my best take on this is, for the largest most expensive unit on the market today from one of the oldest most respected companies, this is an emabrrassing issue that should not exist.  ESPECIALLY since it was known on the last unit.

  • 0 over 2 years ago

    I decoded one of my .fit files. from the other day. The section below is from the top of my home hill that then immediately descends:

    timestamp 1025103957 s distance 45409.33 m altitude 604.4 m speed 3.2 m/s cadence 62 rpm
    timestamp 1025103962 s distance 45425.74 m altitude 604.8 m speed 3.042 m/s cadence 65 rpm
    timestamp 1025103965 s distance 45434.61 m altitude 605 m speed 2.781 m/s cadence 0 rpm
    timestamp 1025103972 s distance 45459.96 m altitude 605 m speed 4.507 m/s cadence 0 rpm
    timestamp 1025103979 s distance 45502.23 m altitude 605 m speed 7.595 m/s cadence 0 rpm
    timestamp 1025103984 s distance 45549.83 m altitude 604.2 m speed 10.693 m/s cadence 0 rpm
    timestamp 1025103988 s distance 45594.5 m altitude 603.2 m speed 11.15 m/s cadence 0 rpm
    timestamp 1025103989 s distance 45605.49 m altitude 602.8 m speed 10.973 m/s cadence 0 rpm
    timestamp 1025103990 s distance 45616.2 m altitude 602 m speed 10.721 m/s cadence 0 rpm
    timestamp 1025103992 s distance 45636.57 m altitude 601 m speed 9.947 m/s cadence 0 rpm
    timestamp 1025103994 s distance 45655.17 m altitude 599.4 m speed 8.967 m/s cadence 0 rpm
    timestamp 1025103996 s distance 45671.47 m altitude 598.6 m speed 7.912 m/s cadence 0 rpm
    timestamp 1025103997 s distance 45678.73 m altitude 597.8 m speed 7.259 m/s cadence 0 rpm
    timestamp 1025104000 s distance 45697.08 m altitude 596.6 m speed 5.57 m/s cadence 0 rpm
    timestamp 1025104001 s distance 45702.25 m altitude 596.6 m speed 5.169 m/s cadence 0 rpm
    timestamp 1025104006 s distance 45721.41 m altitude 596.4 m speed 3.21 m/s cadence 62 rpm

    At 605M you can see I stop pedalling at the top and just freewheel down. The speed picks up and you can see the is a reasonable downhill gradient. However the GPS stays at 605M for at least 14s. This is of course not possible. There are also 2x7sec delay in taking a data sample. Garmin states that it takes a sample, among others, "on change of speed", that is obviously not the case here.

    The second highlighted sections is about where the descent bottoms out and starts to slightly ascend again. However the data samples don't show the bottom out altitude for another 13-15secs, (The next data sample, not included, goes up 596.6M.)

    I have the GPS+ setting, so the GNSS chip appears not to be as good as made out. 

    Another interesting point and bug, is that the Timestamp is the year 2002 and 2022 (which starts with 16). I have reported this to Garmin as it is obviously and bug and not like the gradient, which works as defined.

    I will set my data recording to "1sec"  and not "auto" for the next ride as a test and see if results are more accurate. I assume this will use more battery, but the 1040 has ample.

  • 0 over 2 years ago in reply to MikeF-Swiss
    MikeF-Swiss said:
    I will set my data recording to "1sec"  and not "auto" for the next ride

    Yes please, your data are a good start point in my opinion, but the 'Auto' data recording it's very inconsistent for this kind of sample.

  • 0 over 2 years ago in reply to zivadaddy

    MikeF-Swiss,

    Many thanks for so simply, clearly, eloquently and objectively showing from fit.files, that there is indeed a 15 second delay BUG in Altitude change reporting.

    That’s crazy and completely unacceptable.

    Similar issue for gradient changes!

    Garmin continues with their hutzpah spin-doctors to repeatedly express it’s acceptable / within their expectations / works as defined … according to them.

    And yes, a 20-year fit.file time-stamp difference (2002 vs 2022) is indeed another flaw.