<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://forums.garmin.com/cfs-file/__key/system/syndication/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>New Grade And Ascent Metrics</title><link>https://forums.garmin.com/developer/connect-iq/f/discussion/423276/new-grade-and-ascent-metrics</link><description>Interesting changes to Garmin&amp;#39;s native Grade and Ascent metrics.... 
 I&amp;#39;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</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Wed, 01 Oct 2025 22:04:25 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://forums.garmin.com/developer/connect-iq/f/discussion/423276/new-grade-and-ascent-metrics" /><item><title>RE: New Grade And Ascent Metrics</title><link>https://forums.garmin.com/thread/1979165?ContentTypeID=1</link><pubDate>Wed, 01 Oct 2025 22:04:25 GMT</pubDate><guid isPermaLink="false">a9571b57-dd57-479e-8763-8f8a603e40aa:37620a79-92e1-47a1-8555-e35012248f03</guid><dc:creator>crispgarmin</dc:creator><description>[quote userid="43945" url="~/developer/connect-iq/f/discussion/423276/new-grade-and-ascent-metrics"]For point to point changes in elevation over just a few seconds, weather induced barometric drift doesn&amp;#39;t really come into play, so I can&amp;#39;t imagine a scenario where vertical GPS is better than a barometer (unless the barometer isn&amp;#39;t available or is broken/blocked).[/quote]
&lt;p&gt;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&amp;nbsp;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&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: New Grade And Ascent Metrics</title><link>https://forums.garmin.com/thread/1979038?ContentTypeID=1</link><pubDate>Wed, 01 Oct 2025 15:53:03 GMT</pubDate><guid isPermaLink="false">a9571b57-dd57-479e-8763-8f8a603e40aa:de91ae94-e6c4-43ec-8cd7-d841c6a1b9fb</guid><dc:creator>flowstate</dc:creator><description>[quote userid="43945" url="~/developer/connect-iq/f/discussion/423276/new-grade-and-ascent-metrics"]&lt;p&gt; But I&amp;#39;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&amp;#39;t really come into play, so I can&amp;#39;t imagine a scenario where vertical GPS is better than a barometer (unless the barometer isn&amp;#39;t available or is broken/blocked). So deriving change in elevation using ambientPressure might be better. Any thoughts?&amp;nbsp;&lt;a href="https://forums.garmin.com/members/garmin_2d00_matthew" class="internal-link view-user-profile"&gt;Garmin-Matthew&lt;/a&gt;&lt;/p&gt;
&lt;h3 class="signature" id="ambientPressure-var"&gt;&lt;/h3&gt;
&lt;p&gt;The &lt;strong&gt;altitude&lt;/strong&gt; above mean sea level in meters (m). Elevation is derived from the most accurate source: Barometer or GPS&lt;/p&gt;
&lt;p&gt;The &lt;strong&gt;ambient pressure&lt;/strong&gt; 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.&lt;/p&gt;[/quote]
&lt;p&gt;This doesn&amp;#39;t make any sense.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;Maybe it&amp;#39;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&amp;#39;s based on GPS) to ActivityInfo.ambientPressure.&lt;/p&gt;
&lt;p&gt;Given that &lt;strong&gt;ActivityInfo.altitude is already derived from the baro&lt;/strong&gt;, I&amp;#39;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, &amp;quot;vertical GPS&amp;quot; should play no role here.&lt;/p&gt;
&lt;p&gt;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&amp;#39;t think ActivityInfo.altitude is the way to go. If you want elevation/altitude that&amp;#39;s guaranteed to be from GPS, then I think you need to look at &lt;a href="https://developer.garmin.com/connect-iq/api-docs/Toybox/Position/Info.html#altitude-var"&gt;Position.Info.altitude&lt;/a&gt;&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;var altitude as Lang.Float or Null&lt;br /&gt;The elevation above mean sea level in meters (m).&lt;/p&gt;
&lt;p&gt;Elevation is obtained from the GPS. If no GPS is present, then no valid elevation will be returned.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;[*] Further evidence / related points:&lt;/p&gt;
&lt;p&gt;- 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)&lt;/p&gt;
&lt;p&gt;- 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&lt;/p&gt;
&lt;p&gt;- Elevation corrections are automatically applied to the elevation data in the FIT file only when your device doesn&amp;#39;t have a baro.This reflects the fact that when your device *does* have a baro, elevation comes from the baro (and it&amp;#39;s deemed to be more accurate than GPS elevation)&lt;/p&gt;
&lt;p&gt;- 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 &amp;quot;Elevation is derived from the most accurate source: Barometer or GPS&amp;quot;, it means that elevation is derived from the barometer (if available), GPS otherwise.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>