GRADE Calc - Filtered and Fit

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)

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.

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.

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

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.

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.

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?