I don't know why I didn't do this before. Ugh. So I did a hill ride yesterday, recording data on my EDGE 1050. I used Garmin's FIT2CSV to pull the second by second data into EXCEL. I zeroed in on the 1/2 mile climb called Sugarloaf. The biggest mountain in Florida LOL. 200 ft of ascent on a continuous climb that averaged about 8%. Looking at my Garmin, the native GRADE hit 15% about half way up.
In Excel I can try many different approaches using the data CIQ sees, to estimate GRADE and balance noise -vs- delay. The ORANGE is the raw grade (change in rise -vs- run). Ouch! So bad. The GREEN is a 15-sec rolling average of RAW GRADE. That looks like that climb feels. 10 sec avg felt too jittery. The climb slowly builds to about 15% then settles into about 8-9%, then eases up to about 5%.
I'm going to implement that and test it on my Forerunner 955, EDGE 1030 and EDGE 1050. I understand Garmin made some significant "improvements" to the native GRADE algorithm in the EDGE 1050, so I'm not sure how this will look on the older devices. But using the FIT2CSV/Excel approach I will be able to quicky work out an optimal method. Rolling averages, Least Square, Kalman Filter, etc. I did get some rows where distance didn't change between readings even though speed never dropped below 4-5mph, and the barometric sensor doesn't always update every second. So some logic to throw out absurd readings before adding data to the queue is needed.
I'll update my findings once I get some decent samples on my 3 different devices.