Grade Calc - Community Project

I'm still not happy with CIQ Grade calcs. I live in Florida (mostly flat) so I really don't have a lot of real world opportunities to test Grade. On the other hand, these subtle rollers are some of the most challenging use cases to test the algorithm. The problem seems to be that barometric values aren't updated quickly - and then they tend to jump in a step function when they do change.

Even up steeper grades like Colorado passes that I got to ride last weekend, barometric data isn't smooth. A balance is needed between grade being noisey (due to barometric jumps) or slow to respond (due to smoothing out those jumps). I've tried to make the balance factor adaptive. So it detects a slope inversion or a transition to/from flat roads faster.

Even the native grade values are slow to respond. However, Garmin apparently did a lot of work on this problem in the new Garmin EDGE 1050 (according to DC Rainmaker's beta evals) and now the native grade is dramatically better. As soon as you hit a steep grade from a flat road, for example, grade will reflect a legit value, not slowly adjust over 10-15 seconds. Maybe using the accelerometer sensor to assist?

Anyway, Garmin still refuses to expose native Grade to CIQ. So we have to figure this out on our own.

I am thinking about a Community Effort to optimize the CIQ Grade calcs. I'll create a DF that only generates grade, and that writes to the FIT file, with some User Settings for various variables. I'll display the current grade as well as a line graph of grade to show how our algorithm adapts to slope changes, slope inversion, and transitions to/from flat roads. And I can display this and the EDGE's native grade on the same screen to compare.

I'll post the CIQ Code in GIT Hub and allow contributors to check out, and update. I bet we can come up with a barrel pretty quick that does a great job.

This image shows a pretty steep sustained grade (grey is the elevation profile, blue is my current GRADE calc). Now that I write a FIT graph I have more visibility into the dynamics and I clearly need to smooth it a bit more. I had tried a Kalman Filter at one point that also seemed ok, but not good enough.

If you are interested in joining the project, let me know.

  • This is the sort of thing that looks like it might need a higher order fit than quadratic. Maybe try a cubic regression using Crout LU Decomposition. I have an example I wrote as part of a SQL script for a six sigma project decades ago. Most of it is already unrolled, you would only need to loop through the data to calculate the sums of the powers of x. It wouldn't take much to convert it to Monkey C if you're interested.

  • If the above "community" algorithm uses barometer as input then it should be able to test it also on a watch and steps?

  • Hi Andy - interesting! The challenge is figuring out the optimal balance for a messy barometric metric. Distance is a higher quality variable. But altitude is less predictable, being updated less often and then in steps/jumps. So the slope algorithm will have to smooth the grade metric over several barometric sensor readings. I need to test my EDGE 1030 and my Forerunner 955 to check the barometric sensor sensitivity and rate of change. And when I get my EDGE 1050, see what has changed. Do you think your code might do a better job in working with that kind of data? 

  • Once I played with the raw barometric pressure and it was chaotic. But if I remember correctly then raising my hand with the watch on it from the floor to standing height and then to over my head did show the expected elevation change (though a few seconds later) I think you'll need to debug this, and probably record Garmin's elevation, grade, air pressure, and some smoothed out accelerometer data to see what can you do with them. It will be even more interesting if you'll be able to record both on an older edge and the 1050 at the same time to see both how Garmin improved grade detection and where your algo fits in (between them or even above 1050 maybe?)

  • remember, the pressure can change if you stand in the same place long enough.  Say there is a front moving in

  • I never stood in a twister (or in the perimeter of it?), I guess that would change the pressure fast enough to possibly change the gradient :)

    Contrary to what Garmin is trying to do (not very succesfully lately) to record the elevation over an activity that can span hours, for the gradient it's enough to look a few seconds (maybe a minute) back, so even if you're in the middle of a front that would probably only skew the gradient calculation by a tiny amount.

  • Counting floors is also done with the baro, and I've seen "floors" if I'm in front of a vent when the AC kicks on.

  • a vent is probably like the eye of a twister, but even the strongest "just" storm won't drop the pressure fast enough in 1 minute to be mistaken for a -0.01% grade IMHO.

  • I've submitted a v1.0 to display and record several values to the FIT file that I can then model in Excel to play with sensitivity of various pressure and altitude metrics -vs- distance and time. That should help me workout an approach for various rates of grade changes, inversions and flat road detection. I use the known formula to convert change in pressure to change in elevation. I'll work on this and see what I end up with.

  • true and that impacts elevation but not grade, since grade is based on rate of change and weather-induce pressure changes are slow enough to not matter.