Grade Calc - Community Project

Not convinced. In fact you just convinced me about the opposite: calculating with only 2 values is a) easier, b) more precise (see: you get 10% which is the correct grade, instead of 9.5%)

flocsy  I think you are after a different metric than what we are after. If you want to look for the average gradient of let's say the current lap, you would save the altitude and elapsedDistance when the lap timer is pressed and then take the simple change in altitude divided by the change in distance over the lap so far. But we are after a momentary slope that you are on right now. Altitude data from one second to another is very imprecise (it looks more precise in FIT files than the data handed to your app, that's why it is called "improvedAltitude" in the FIT file). So if you take altitude(now)-altitude(1 sec ago), there is a lot of error. Your grade estimation will jump up and down even on a stable gradient.

turkey-run Thank you for the explanation. Indeed, averaging gradients is not right. However, I am not averaging gradients, I am first averaging the altitude from 8 to 4 seconds ago and the altitude from 4 seconds ago to now. The difference is the average altitude gain from about 2 to 6 seconds ago. I then take the average speed from 2 to 6 seconds ago. I will try to replace the speed data by the distance data, sounds like a good idea. The main problem with my approach is that it 1) does not account for curvature of the slope, 2) estimates the slope from 4 to 5 seconds ago, and 3) requires the lag of the altitude and the lag of the distance/speed to be identical.

In general, if we create a barrel, we may need to account for different devices/sensors. On a Garmin Edge it seems that speed data and altitude data has a lag of 1 second according to the correction Garmin applies to the data at FIT creation.
Phew, that was a long post, so many issues to think about!

But you don't use alt(now) and alt(1 sec ago) :) You use alt(-8) and alt(-4) (and all the others in between) so even though each altitude reading second after second might be jumping because of the wind or quantum fluctuations in the barometer, when you are interested in how much the altitude changed over 4 seconds, then the inpreciseness is relatively small (not bigger than for second by second, while the rider climbed 4 times the height)

9321273 said:

If you want to look for the average gradient of let's say the current lap, you would save the altitude and elapsedDistance when the lap timer is pressed and then take the simple change in altitude divided by the change in distance over the lap so far.

But you have stated before:

Another use case is the average climbing gradient of the ride so far. That would be well estimated by summing over all the positive values in the proposed algorithm.

That‘s what flocsy referred to…

Whether this is better or not depends on the error. If there is noise with high frequency variation (let's say a gust of wind lasting 2 seconds changes air pressure), you can improve the estimate by averaging over nearby data points. If the error is more persistent (let's say 4 seconds), then averaging makes it worse. Error frequency components larger than 8 seconds don't matter. We could figure out the frequency components with a proper Fourier analysis....

I poorly chose my words, what I meant was a "different" use case from what I was focusing on. I fully agree that for average gradients over longer durations Delta altitude / Delta distance is the right approach. Again, for the local gradient, curve fitting as in turkey-run's package or applying rise over run to averaged data might be better.

When running with my FR165, I concerned noise at two points: 20 seconds before and now.

20 seconds is about 60m.(my running)

Has anyone compared fit file data, as pushed by garmin, with fit file data pushed by CIQ, from data handled to it in real time, to verify actual lags?  Ideally with some synchronizing event to 'real world'?

I see how pressure data alone can be 'jumpy' over time, but doing just temporal calculations, samples at fixed time intervals, compounds the error by the variation in speed, sometimes. as you go slower and slower on a climb (by nature of limited leg power or to test algorithms), the small distance in 1s becomes an amplifier of the errors.   A smart algorithm would take that in account as well, perhaps calculating bounds each time, considering observed errors in pressure and in distance, and reporting the 'most likely' not an eventual extreme because speed is small and we happened to get a pressure update that second.

Does anyone know if when you have a 'speed sensor' on the wheel, does that provide actual rotational speed, calculated internally on the sensor near continuously by accelerometer attitude, or simply # of rotations since last transmit, or rotational speed from this quantized data?   Or does garmin use it for distance and some mix of gps and distance sensor for speed?

btw it has been confirmed - flexure on the case or even pressing the screen (say to swipe to next page) generates large disturbances in the 1040 pressure sensor, havoc to grade calculations.  The edge 1000 doesn't suffer from this.