• Replies 47 replies
  • Subscribers 24 subscribers
  • Views 10416 views
  • Users 0 members are here
Options
Related

GRADE Calc - Filtered and Fit

DaveBrillhart
over 4 years ago

I carefully watched the GARMIN Edge 1030 barometric sensor data on a ride yesterday.

Riding in Florida on an essentially FLAT road, the floating-point altitude metric bounces around +/- up to 2.5 feet each second.

The problem is that most even strong climbers, climb less than 1 foot per second. That is about a VAM of 1000 (1000 vertical meters per hour).

So the "noise" in the barometric sensor data can be twice as much as the typical climb rate. In other words, half the time, the "next" altitude reading suggests you are going down when you are on a steady steep climb.

I tried running a least squares line fit over 10 data points to get the GRADE "trend" that hopefully ignores the sensor noise. I didn't want to use more than 10 seconds or the response to changes in the road's grade would be too slow. But I still got a GRADE metric that bounced around too much.

So I just applied a "median value" filter, and that works great. I take the MEDIAN value of the last 4 plus the current altitude reading, as the altitude. Using the median does a good job of ignoring noise. And then I apply a least squares line fit to the last 10 filtered altitude values.

Anyway, if anyone is trying to create a useful GRADE metric in their CIQ apps, this seems to work well.

Since, for some reason, Garmin doesn't want to let us have access to the device's GRADE value.

  • over 1 year ago in reply to SpitRider

    I sanity-check the altitude values, before sending to the Kalman Filter for the grade calc.

    Here is an example of an ignored value (1200) where I apply the prior altitude, and an example where the barometric change was too quick so I smoothed it out using a max change value that is speed dependant (eg: a fast downhill would see a much larger change per second than a slow climb)

  • over 1 year ago in reply to DaveBrillhart

    Thanks, your idea is absolutely clear to me now and makes a big sense, especially when atmospheric conditions are very unstable or when you are riding a short steep "down and up" road section.

    I just analyzed the FIT file from my yesterday's semi-mountain ride consisting of 13k points and found only 2 points where the instant raw grade was >25%. But the Kalman filter can easily smooth such points.

    Also, additional post-processing with a simple averaging filter after the Kalman filter helps to smooth values that differ from their neighbors by 1%, like 10% in sequence [9, 9, 10, 9, 9]. It roughly costs for 1s delay for 3s averaging filter, and 2s delay for 5s averaging filter.

    So I guess it makes sense for me just to add an optional configurable setting for the post-processing averaging filter and test it for some time on different routes and in different weather conditions. And then try to implement some similar logic to yours in case if results are unsatisfactory.

  • over 1 year ago in reply to SpitRider

    I live in Florida, so my testing of my Grade algorithm, unfortunately, is only under the highly challenging conditions of mostly flat roads and trails near sea-level with some overpasses that have maybe a 5-7% grade for just 50 meters or so before I summit. LOL. I do have some better testing grounds in Clermont, about a 45 min drive to Florida's hilly terrain. There we can get climbs up to about 100m above sea-level on grades up to 10-12% that last 800m or so. In those conditions, the response time feels too slow and the barometer seems to not update the reading every second, and then all of a sudden suggests the altitude jumped from one reading to the next, by an unreasonable amount. On a nice sustained mountain climb I think it would work really well... and TBH I don't really even look at the grade in Florida.

  • over 1 year ago in reply to DaveBrillhart

    BTW do you use a wheel speed sensor? I have the Edge 1030 and speed sensor, and so far I noticed a strange behavior with the native grade field only in two cases:

    - when riding a fast down-up section, especially with a heavy wind, the grade may show higher values than real, i.e. 15% when the real value is less than 10%.

    - when riding a flat gravel or cobblestone section and looking at the grade field combined with map view, it may jump from -3% to +3% every second. However, if I switch a page to the non-map view where the grade field is also present, everything works fine. Weird

  • over 1 year ago in reply to DaveBrillhart

    Strange, because the barometer on my fenix6 seems to work. I can put my arm to the floor, see the altitude/ambient pressure, and then hold my arm above my head and see both numbers change according to what's expected.

  • over 1 year ago in reply to SpitRider

    I have a speed sensor on my MTB for single track, but not needed on my road bike, where I have been watching grade. Interesting.

  • 4 months ago in reply to DaveBrillhart

    there is some evidence that garmin might be using accelerometer data also as input to their new 1040/1050 grade cslculations.

    is accelerometer raw data (or some derivated) available to CIQ?  could you add it to the FIT logged data?