In case anyone is interested.... I have a python script that pulls the DEM elevation data for a ride. I also use a FIT field to export the high resolution barometric data (the default is a rounded value). I tried both the raw barometric data and the native 2-pass filtered barometric data. The RAW is very noisy so even thought the filtered data is slightly delayed, it is actually a better source because you'd introduce worse delay cleaning//smoothing the raw data.
I compared a ride I did two days ago on a trail in Colorado Springs. Statistically looking at the DEM vs the Barometric on my EDGE 1050, they were nearly identical, just skewed by 4-6 seconds. Understandable. I also found that I had to maintain a queue of sensor data and perform additional processing and smoothing to generate a usable GRADE, delaying the GRADE metric a little longer. But with speed adaptive and noise adaptive logic (watches are much noisier than EDGE devices due to the barometric port exposed to wind), it is working really well now, other than the metric delayed at the onset of climbs and descents.
Wish Garmin would simply expose the native grade to CIQ!
Here is the result of the analysis (Claude):
Yes, the DEM and barometric elevation match very well on this ride. Overall: correlation is 0.999. On average the barometer reads just +0.3 m above the DEM (median +0.2 m). The barometer lags the DEM by about 4 seconds. Lining them up 4–6 s apart gives the closest match. That’s probably the Edge smoothing its pressure readings, and it shows up as slow grade response at the start of climbs.
