• State Suggested Answer
  • Replies 85 replies
  • Answers 1 answer
  • Subscribers 29 subscribers
  • Views 38263 views
  • Users 0 members are here
Options
Related

Grade Calc - Community Project

DaveBrillhart
2 months ago

I'm still not happy with CIQ Grade calcs. I live in Florida (mostly flat) so I really don't have a lot of real world opportunities to test Grade. On the other hand, these subtle rollers are some of the most challenging use cases to test the algorithm. The problem seems to be that barometric values aren't updated quickly - and then they tend to jump in a step function when they do change.

Even up steeper grades like Colorado passes that I got to ride last weekend, barometric data isn't smooth. A balance is needed between grade being noisey (due to barometric jumps) or slow to respond (due to smoothing out those jumps). I've tried to make the balance factor adaptive. So it detects a slope inversion or a transition to/from flat roads faster.

Even the native grade values are slow to respond. However, Garmin apparently did a lot of work on this problem in the new Garmin EDGE 1050 (according to DC Rainmaker's beta evals) and now the native grade is dramatically better. As soon as you hit a steep grade from a flat road, for example, grade will reflect a legit value, not slowly adjust over 10-15 seconds. Maybe using the accelerometer sensor to assist?

Anyway, Garmin still refuses to expose native Grade to CIQ. So we have to figure this out on our own.

I am thinking about a Community Effort to optimize the CIQ Grade calcs. I'll create a DF that only generates grade, and that writes to the FIT file, with some User Settings for various variables. I'll display the current grade as well as a line graph of grade to show how our algorithm adapts to slope changes, slope inversion, and transitions to/from flat roads. And I can display this and the EDGE's native grade on the same screen to compare.

I'll post the CIQ Code in GIT Hub and allow contributors to check out, and update. I bet we can come up with a barrel pretty quick that does a great job.

This image shows a pretty steep sustained grade (grey is the elevation profile, blue is my current GRADE calc). Now that I write a FIT graph I have more visibility into the dynamics and I clearly need to smooth it a bit more. I had tried a Kalman Filter at one point that also seemed ok, but not good enough.

If you are interested in joining the project, let me know.

  • 0 2 months ago in reply to mcinner1

    does your datafield save these values to FIT?

    I tried a 1040 with 23.09 and an edge 1000 at the same time, the 1000 is very delayed (but gives 1 decimal in grades below 10) and the 1040 that used to be even laggier, more smoothed than the 1000 now responds very quicky.

    no longer you have a positive grade 4s into the descent after the peak, it is very responsive.  otoh you always get an overestimation in the entry of any climb, like 2 3 4 5 4 4 5 6 7, and very obvious on GPLama excellent video; grossly exaggerates the max grade on a climb.  The amount of exaggeration depends on the rider strength apparently, likely due to a temporal "edge sharpening" that is as poorly tooned as a picture with oversharpened edges.

    i am excited about this project. if ciq allows access to garmins raw data, like barometric, accelerometer, gps, their grade and "our grade" can be recorded in FIT it becomes easier to compare, to simulate methods using a database of collected data at different speeds, weather, terrains etc. and come with a better compromise.

    i thought that accelerometer data alone would be the answer but reading prior posts it seems they are even noisier (cant they be spectrally filtered?) but perhaps a combo of sensors can get us something between the 1000 and the 1050?

    on a long climb i know eventually they all converge, and one thing i am always curious about was the max grade of some climbs. a hairpin road curve, a mtb wall. it seems the 1000 gets closer to actual than the old 1040, while the new 1040 (23.09) is WORSE as it overshoots. and will overshoot badly if you have strong legs.

  • 0 2 months ago in reply to flocsy

    i THINK someone at garmin just changed their rolling average or IIR lowpass filter time weights to smooth a little less data,  and/or added edge sharpening to that smoothed data.   basicslly adding a "lookahead" factor, a first derivative component that makes a smoothed step (a ramp) get steeper.

    it seems the case as confirmed by gplama in his excellent video.

  • 0 2 months ago in reply to jrc_
    jrc_ said:
    like 2 3 4 5 4 4 5 6 7

    Either I don't understand what you mean on overestimation, or I don't see it in these numbers. Unless you mean that the beginning should've been: 2 3 4 4 4 4, and jumping to 5, than back to 4 was the over estimation.

  • 0 2 months ago in reply to flocsy

    By „overshooting“ I meant (and have seen in my test rides):

    let‘s say your ride changes from flat to steady 5%. Then the Edge starts very quickly to rise the grade number after beginning to climb. But it rises up to 7% and then goes back to the correct value of 5%.

  • 0 2 months ago in reply to mcinner1

    Ok, I don't see that in the above numbers though.

  • 0 2 months ago in reply to flocsy

    i meant that in the past due to long averages, the value given by the device would be tipically lower than the actual at thecstart of a climb, but the 1050 (snd 23.10 1040) actually give higher values for some time.

    the old one was a delayed curve, lower than actual until grade is constant long enough.  the new one always has this waltz st the entry of a climb, instead of steadily increasing it goes quickly over and then comes back.

  • 0 2 months ago in reply to flocsy

    in my example imagine it was a monotonic actual grade, that reversal 454 should not be there, but just a gradual increase.

    i just made up those numbers to exemplify. i made a video in a ride (cellphone in one hand, edge 1000 and 1040 on the bike, struggling to keep in the frame while climbing a 14% grade) but didnt type down the numbers yet. i also did a screen recording on the 1040 but also didnt digitize as i then found gplama video that demonstrates it beatifully. and his high ftp means even higher first derivativevof actial grade, so higher estimation by the device. a mere mortal wouldn't have seen the 4, 5% extra grade he saw.

  • 0 2 months ago in reply to DaveBrillhart

    Great CIQ, perfect for collecting true data for post analysis.

    I think Garmin doesnt expose grade to CIQ because they are embarrassed how off it is and dont want to leave records  :-)

    Screen recording and typing from the saved screenshots is the only method i figured so far.

    Would you consider using higher contrast colors in gradecalc?  on the 1040 is is a very washed out blue.

  • 0 2 months ago in reply to jrc_
    jrc_ said:
    Screen recording and typing from the saved screenshots is the only method i figured so far.

    : for import values to excel or similar - you could insert println() statements for the values so one could catch them in xxxxxxx.txt in Apps/Logs folder?

    PS: I haven‘t downloaded your datafieldyet  - will do today…

  • 0 2 months ago in reply to mcinner1

    I doubt it would give you useful information, as both the bak and the txt file will be truncated at 4k.