New Grade And Ascent Metrics

Interesting changes to Garmin's native Grade and Ascent metrics....

I've developed a Grade Field that many prefer to the native grade, which is (or was), noisy and often showing irrational values. I found that quick acceleration/deceleration can cause the native grade to spike even on a flat road, the sampling rate of the barometer causes elevation data to be more of a step function, restarting from autopause or a stop can cause a huge change in reported elevation, etc.

It looks like they may have improved their Grade metric (probably using some of my techniques). But it also looks like they have moved the tradeoff point to introduce significantly more latency in the total ascent metric. My data field should remain unaffected, since I use altitude (really it should be called elevation) in my algorithm. But I'm curious if anyone has compared the two ActiviyInfo metrics: (altitude vs ambientPressure) to derive a near real-time elevation that has less noise. For point to point changes in elevation over just a few seconds, weather induced barometric drift doesn't really come into play, so I can't imagine a scenario where vertical GPS is better than a barometer (unless the barometer isn't available or is broken/blocked). So deriving change in elevation using ambientPressure might be better. Any thoughts? 

The altitude above mean sea level in meters (m). Elevation is derived from the most accurate source: Barometer or GPS

The ambient pressure in Pascals (Pa). This returns ambient (local) barometric pressure as measured by the pressure sensor. The data is smoothed by a two-stage filter to reduce noise and instantaneous variation.

  • But I'm curious if anyone has compared the two ActiviyInfo metrics: (altitude vs ambientPressure) to derive a near real-time elevation that has less noise. For point to point changes in elevation over just a few seconds, weather induced barometric drift doesn't really come into play, so I can't imagine a scenario where vertical GPS is better than a barometer (unless the barometer isn't available or is broken/blocked). So deriving change in elevation using ambientPressure might be better. Any thoughts? 

    The altitude above mean sea level in meters (m). Elevation is derived from the most accurate source: Barometer or GPS

    The ambient pressure in Pascals (Pa). This returns ambient (local) barometric pressure as measured by the pressure sensor. The data is smoothed by a two-stage filter to reduce noise and instantaneous variation.

    This doesn't make any sense.

    It seems that you are implying you think ActivityInfo.altitude uses GPS elevation, even for devices which have a baro. Then you go on to quote the API docs, which say that ActivityInfo.altitude comes from the most accurate source: baro or GPS.

    Maybe it's 100% not clear from the API docs, but I think that means that ActivityInfo.altitude uses the baro for devices which have one [*], which is why it makes no sense to talk about comparing ActivityInfo.altitude (with the assumption that it's based on GPS) to ActivityInfo.ambientPressure.

    Given that ActivityInfo.altitude is already derived from the baro, I'm not sure how using ambientPressure to derive the elevation in a different way would be any better, unless you somehow have a different/better algorithm than Garmin. But then again, even if that were the case, "vertical GPS" should play no role here.

    Also, if you are trying to say that you actually *want* to use GPS elevation in some cases, even for devices with a baro, then I don't think ActivityInfo.altitude is the way to go. If you want elevation/altitude that's guaranteed to be from GPS, then I think you need to look at Position.Info.altitude

    var altitude as Lang.Float or Null
    The elevation above mean sea level in meters (m).

    Elevation is obtained from the GPS. If no GPS is present, then no valid elevation will be returned.

    [*] Further evidence / related points:

    - ActivityInfo.altitude should always match the native elevation field (this could be confirmed by using a CIQ field that displays ActivityInfo.altitude side-by-side with the native elevation field)

    - The native elevation field is saved to the FIT file, but the FIT file also has a separate GPS metadata table with an altitude column. For devices with a baro, these two columns will likely have different values for any given timestamp

    - Elevation corrections are automatically applied to the elevation data in the FIT file only when your device doesn't have a baro.This reflects the fact that when your device *does* have a baro, elevation comes from the baro (and it's deemed to be more accurate than GPS elevation)

    - Given that everyone agrees that a baro is more accurate than GPS for elevation, I think it should now be clear that when the API docs say "Elevation is derived from the most accurate source: Barometer or GPS", it means that elevation is derived from the barometer (if available), GPS otherwise.

  • For point to point changes in elevation over just a few seconds, weather induced barometric drift doesn't really come into play, so I can't imagine a scenario where vertical GPS is better than a barometer (unless the barometer isn't available or is broken/blocked).

    I thought that until an edge case where climbing (and counting down elevation to summit so had on-screen) on a sunny exposed mountain road and a probably-heat-induced dust-devil mini-whirlwind on the road caused my altitude on a 1040 to spike by 50ft instantaneously due to the low-pressure I experienced momentarily. I think Garmin are over-compensating for edge cases like this at the expense of general stability in altitude / grade