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?

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

Yeah I'd like to refine this to auto-calibrate the noise floor. I can detect a flat road if the barometer returns values between X and Y, where (X-Y).abs() is a small number (say < 15 ft) and the values bounce above and below the average every few seconds. Grade is important to cyclists. Garmin's grade actually doesn't work that well, isn't provided to CIQ, and isn't written to FIT. I want to provide it on my custom screen, improve on Garmin's version, and write it to FIT for post ride graphing. Also, one of my clients is now using GRADE to inform a new metric called Relative Power, so it is important to be accurate.