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

Edge 820 not showing Grade above 16%

Former Member
Former Member
I have an Edge 820 with Firmware 11.0 and a speed sensor which I use when Mountainbiking.

The "Grade" is unreliable around 15% and generally does not show values above 16% - it just shows 0%, or sometimes a few %. The "Totl. Ascent" will increase, but only seems to do that every now and then ... lets say each 15 seconds ... and normally in larger increments (like 5-10 meters). So, overall its accurate.

To me it seems like there are some smoothing algorithms in place, and perhaps I don't ride fast enough on the very steep climbs (8 kph on a 20% climb) for those algorithms to correctly evaluate the Grade.

My previous Edge 510 worked just fine up to and beyond 30%. At that point it might not have been that accurate ... but it was closer to the truth than 0% is!


Any ideas?
  • Even though I'm late, I'd like to contribute to this topic by an observation and a working hypothesis. Observation: My Edge 820 has been with my bike for at least 40.000km and I spend the most part of my spare time in the Alpes. In narrow valleys or on cloudy days my Edge sometimes tells me 'satellite lost'. At the same time the grade field shows '---' (and the corresponding track is a wild zig-zag-polygon, only). Working hypothesis: I suspect that the grade is not calculated from the elevation difference and the distance but known from the current position. If the Edge is unabled to talk to the satellite it doesn't know where it is and hence has no grade information. There might be a switch that allows to choose between calculation and database lookup.
  • Former Member
    0 Former Member over 6 years ago
    Thanks for that info!

    I ride the same climb several times a week, it has gradients between 15-25%. Normally the 820 has inaccurate GPS data on this climb (the speed varies significantly), and the gradient normally does not work (shows a few percent or 0). So I installed a speed sensor, which fixed the speed problem, but did not help with the grade.

    Now, I mention that because yesterday the Grade did work(!), at least for the bit where I saw 20% abut where I expect it. So perhaps you are right? The Grade might actually be calculated from GPS data points (as a reference) and in my case those GPS points are less accurate ... probably the topology of the climbs is a factor, but if the Satellites are in the right position, then I get a better GPS data point.

    If that were the case, I would do this:

    For a new GPS data point, if the calculated speed based on the previous data point is different than the speed from the speed sensor, then the data point is probably not very accurate, so don't use if for Grade calculation.
  • There is a thrid-party Connect IQ add-on called Rgrade, that calculates the gradient from the barometric sensor ( and speed sensor if you have one ). It's very twitchy, but otherwise has never failed give some kind of opinion on the gradeint, even in the Alps. I can't remember where I read it, but I believe the standard gradient field derives it's data from GPS only, and dodgy position information give extremely dodgy gradient data. The Garmin realises when it's likely to be too dodgy and blanks it out.
  • The grade is calculated from elevation change (barometric) and distance traveled. The distance will come first from a speed sensor and if there is no a speed sensor then from GPS positioning. If you are using a speed sensor I would recommend setting the wheel circumference manually rather than using automatic. That way the value is static and does not change.
  • The grade is calculated from elevation change (barometric) and distance traveled. The distance will come first from a speed sensor and if there is no a speed sensor then from GPS positioning. If you are using a speed sensor I would recommend setting the wheel circumference manually rather than using automatic. That way the value is static and does not change.


    Hi Alan,

    Also having similar issues with my brand new 820, especially when mountain biking in the woods (NOT too dense tree cover, though). I do have a magnetless Garmin speed sensor but haven't used it yet with the 820. Without the speed sensor, however, I have been having issues with the grade: basically, it's very slow to react and often switches to 0 during climbs. Now here's the interesting thing: the elevation and speed data fields react much faster than grade (i.e. there is no speed or elevation blanking out to 0 even when climbing forest trails), so the GPS signal, while weak, is still adequate for the 820 to display correct speed (well, slightly less than actual speed, but NOT 0) and elevation changes. Yet, the same GPS signal is not adequate for grade calculation? That just doesn't sound right to me.
    Moreover, I have also tried a Connect IQ app for the gradient data field (not the one suggested by Chrisba above, but another one which also relies on barometric changes) and had a very different experience: it is twitchy indeed, but reacts much faster than Garmin's own default Grade data field (and is quite similar to how my old Garmin Edge 810 would react).
  • The grade calculation does do some smoothing of the elevation data and does compute it over a minimum distance. Not quite sure what that is though, but I recall something like a 200 meter moving average, which is why it lags. The elevation data is quite noisy so it is a bit of challenges to be both responsive and not give crazy values. Garmin over the years have made several efforts on different units to improve the grade handling. I'm not sure what iteration of the grade calculation is on the 820.

    The GPS speed data likely goes through some smoothing before it gets to the UI and it could be that below a given value (speed) that it might be considered too noisy for grade calculation.

    If you have the speed then give it a try and see if it improves the situation. It should, certainly on steep grades where GPS data can under report the distance traveled as it handles movement on the X-axis (horizontal plan) well, but does not handle vertical displacement well. In short when climbing a hill the GPS data gives you the length of the base of a right angle triangle, while the speed sensor gives you the length of hypotenuse of the triangle that is formed by you riding up a grade.
  • The grade calculation does do some smoothing of the elevation data and does compute it over a minimum distance. Not quite sure what that is though, but I recall something like a 200 meter moving average, which is why it lags. The elevation data is quite noisy so it is a bit of challenges to be both responsive and not give crazy values. Garmin over the years have made several efforts on different units to improve the grade handling. I'm not sure what iteration of the grade calculation is on the 820.

    The GPS speed data likely goes through some smoothing before it gets to the UI and it could be that below a given value (speed) that it might be considered too noisy for grade calculation.

    If you have the speed then give it a try and see if it improves the situation. It should, certainly on steep grades where GPS data can under report the distance traveled as it handles movement on the X-axis (horizontal plan) well, but does not handle vertical displacement well. In short when climbing a hill the GPS data gives you the length of the base of a right angle triangle, while the speed sensor gives you the length of hypotenuse of the triangle that is formed by you riding up a grade.


    Thanks a lot for the quick and detailed response. 200 meters sounds about right, as I noticed severe grade lag (or even 0) on short (e.g. 100 meters long), steep climbs. Btw, my 820 has the latest FW (11). The Connect IQ gradient app (which relies on barometric changes as per the description), which I have tested as an alternative, certainly errs on the twitchy side, but it reacts better on short climbs in the woods where the default Garmin grade field would erroneously show 0. On longer sustained climbs, the default Garmin data field seems to be more accurate overall though.
    Oh and yes, speed definitely has to do sth. with it too, as the grade dropping to 0 happens on those steep climbs (in the woods) where I'm relatively slow on my bike.
    But I still find the 810 more accurate than the 820, even though the latter is set to GPS+Galileo (I'm in Europe) as opposed to the 810 relying only on GPS. I wonder if the GPS chip in the 810 is better or is it just the difference in the smoothing algorithm between the two models?
    I'll test it with the speed sensor too
  • The grade is calculated from elevation change (barometric) and distance traveled. The distance will come first from a speed sensor and if there is no a speed sensor then from GPS positioning. If you are using a speed sensor I would recommend setting the wheel circumference manually rather than using automatic. That way the value is static and does not change.


    Alan, how do you set the wheel circumference manually? I've been searching for such feature and can't find it.
  • You need to have an external speed sensor. Once the sensor is paired and in communication with the Edge go to the sensor and then sensor details. You should see an option for wheel size to be automatic or manual. If you select manual it will allow you to enter a value for the circumference.
  • The grade calculation does do some smoothing of the elevation data and does compute it over a minimum distance. Not quite sure what that is though, but I recall something like a 200 meter moving average, which is why it lags. The elevation data is quite noisy so it is a bit of challenges to be both responsive and not give crazy values. Garmin over the years have made several efforts on different units to improve the grade handling. I'm not sure what iteration of the grade calculation is on the 820.

    The GPS speed data likely goes through some smoothing before it gets to the UI and it could be that below a given value (speed) that it might be considered too noisy for grade calculation.

    If you have the speed then give it a try and see if it improves the situation. It should, certainly on steep grades where GPS data can under report the distance traveled as it handles movement on the X-axis (horizontal plan) well, but does not handle vertical displacement well. In short when climbing a hill the GPS data gives you the length of the base of a right angle triangle, while the speed sensor gives you the length of hypotenuse of the triangle that is formed by you riding up a grade.


    Hi Alan, I've just given it a try with the magnetless speed sensor today, and I'm sorry to report that it hasn't really improved the situation. Sure, the speed seems more accurate, but as soon as I enter the woods and hit a steep climb, the grade field shows 0% way too often when the actual slope is, say, 14%. The Connect IQ gradient app data field (which relies on barometric pressure) seems more accurate, though wildly twitchy. But the default Garmin grade field would show 0 when climbing a double-digit trail without rising to the actual (e.g. 12 or 14 or 16 per cent) value, even though the speed from the hub sensor showed accurate speed. Now, this happens on steep climbs (i.e. at speeds below 10 km/h) in the woods (though the tree cover is not that dense). In open fields, or even in the woods (when going downhill at high speeds), the default Garmin grade data field has no problem showing even 15-20%, so it's definitely not a hardware issue. And the Connect IQ app also shows more or less accurate values during slow climbs. So this must be because of some weird combination of poor GPS signal and slow speed. I wonder if sth. could be done about it for a new firmware release.