Garmin Intentionally Handicapping CIQ?

I'm trying to develop an accurate and responsive GRADE metric in CIQ. It isn't as easy as you might think. Elevation data bounces around especially on grades that are relatively small like in the 1-3% range. You have to smooth out the bad data over several readings, but also need a quick response to slope changes.

Garmin does a good job with their internal GRADE metric. They obviously use features other than Elevation and Distance. We know GPS elevation is not useful, so it must be something else. Maybe the accelerometer? For example, I might be starting up a climb and for a few seconds, the barometer shows no change or might actually bounce down a foot or two for the first reading or two on the new climb. But the Garmin GRADE metric accurately shows I'm on a 1-2% grade almost immediately.

So three questions:

1. Do we know if Garmin intentionally hamstrings CIQ in some areas? Not exposing GRADE in the Activity.Info is just one of a number of native metrics that would be very helpful but not given to CIQ developers. There might be valid business reasons to hold back some capabilities - but I can't think of any.

2. Does anyone know what Garmin might be using to generate an accurate GRADE metric?

3. Since barometric data and distance doesn't, by themselves, provide the accuracy and responsiveness needed to produce a GRADE value that can match the performance of Garmin's internal GRADE value.... is there something else we can tap into via CIQ to help improve that metric?

Top Replies

All Replies

DaveBrillhart over 5 years ago in reply to subra

That would be clever and easy. Auto calibrating. But no, tilting the device doesn’t alter the internal grade metric.

TobiasLj over 5 years ago

DaveBrillhart said:
Garmin does a good job with their internal GRADE metric. They obviously use features other than Elevation and Distance. We know GPS elevation is not useful, so it must be something else. Maybe the accelerometer? For example, I might be starting up a climb and for a few seconds, the barometer shows no change or might actually bounce down a foot or two for the first reading or two on the new climb. But the Garmin GRADE metric accurately shows I'm on a 1-2% grade almost immediately.

Do you use the simulator to test your algorithm or do you side load the DF and test during a ride on your device? Reason for asking is that I've seen problems with data in the simulator when loading a FIT file from an activity and use it. One of the most annoying is that distance increases much faster than it should, in the end when the timer stops increasing (because you are at the end) the elapsed distance is about 12-13k for a 10k run. Perhaps there are problems with other info as well, such as altitude.

I'm quite sure that Garmin holds an array of info and use that in their algorithm, I remember that I had the elevation DF from Garmin visible during one ride this summer and it works but there is a latency before grade changes. Probably around 10-20s.

DaveBrillhart over 5 years ago in reply to TobiasLj

I do both - I just developed 2 CIQ grades - one from the altitude and one from the pressure data in Activity.info(). Pressure is documented as passing thru a 2-stage filter to reduce noise. I've just sideloaded it and will test it today and see which data element provides a better GRADE - compared to the native GRADE value. I see much better response on the Edge device to grade changes, than you are seeing of 10-20 secs.