Grade

The question is if this noise is device family specific (i.e all fr955 will have around the same level of noise you saw) or is it device specific (i.e if you test another fr955 it can have different noise level)? But even if it's device family specific, how will you know what constant you'll need to use for each family?

Thinking about it further maybe you should add a way to calibrate it. Maybe tell the user to go on a flat road (or velodrome?) and start "calibration mode" (not in the system settings, but in your app) and look at the min, max values during the calibration, and save the difference, and then use that stored value for X in max-min<X.

(BTW I'd also recommend to test this: 1. do the same test on a flat surface, 2. calibrate the barometer (in the system menu), 3. do the same test in the same place again. Does the calibration make it better?)

DaveBrillhart said:

So what worked really well to eliminate spurious grades (flat road detection) was to maintain a queue of the last N elevation readings, generate a max/min value and assume a flat road if max-min < X.

I'm gonna ask the obvious (rhetorical) question here: won't this algorithm also have the effect of incorrectly returning a grade of 0 for a gentle, short slope?

(Note: I don't really care about the answer, the point is for you to think about it)

Also, what flocsy said.

You seem to be on a years-long obsession with grade. I get that it's important for cyclists, and I guess even Garmin recognizes that because they're apparently trying to refine their algorithm.

Do you think you can really create an algorithm that works better than Garmin's algorithm *in general*, not just for your edge case of cycling in Florida with FR955 and Edge 1050? Garmin has access to a mountain of data from millions of activities in a ton of different conditions.

As a runner I care about hills too, but when I see obviously incorrect elevation data in Connect and/or clearly bad grade-adjust pace, I kinda just shrug my shoulders.

As long as my total elevation gain over time (like weeks or months) is roughly accurate, I'm good. In general I just want to run faster, and I use what data I have to look at trends, without obsessing over it *too* much. (I def obsess more than others though.)

I mean, I obviously know when I run up and down a hill, and my training effect is the same whether or not Garmin tells me the correct grade/elevation for the hill. When I do hill repeats (speedwork in disguise), I don't need Garmin to give my correct stats in order to derive the physical training benefit.

I guess others may care a lot more about this stuff than me tho.

Yeah, I totally agree.

I think Garmin could throw 10,000,000 FIT files from different devices and ride styles and counties at AI or any competent University Camps I researcher and get a really good parametric equation out... but evidently have not. So I'm glad there are others trying to solve the problem as when I'm riding and it feels harder and looks down and see it's 6% that makes me feel better. When I look down and it says minus% (Garmin ) or is really laggy (others) then I think there must be a better way.

If the API would allow access to actual course data at ride-time then we could also use dynamic third-party services to predict the route upcoming regardless of poor on-device DTM or low-quality height info in route-builders. That's my wish