is total ascent/descent (altitude) in session data barometric enhanced?

I know GPS based altitude is poor on most watches and is a technical limitation (maybe GPS2 will help fix someday).

But I've noticed the total ascent/descent in the (type 18) session data (and type 19 lap data) on my fenix is far more accurate than the point-to-point "record" altitude data?

Is it silently enhanced by the barometer? Does this not happen on garmin watches without?

Example run:

elevation	up	down
-22.97	29.53	52.49

but when I carefully do the math on the point-to-point record data for the entire run and sum it I get

elevation	up	down
-22.31	765.75	788.06

(this is meters converted to feet)

Unless I screwed up my code somewhere the massive up/down is just GPS being stupid, it's interesting it self-correct as I return the starting point. Also interesting how close the two are. I do altitude correction before each run from a known starting point at a known height.

(but I find it humorous both the summary and record data show the return to start has a net drop which is impossible regardless of route)

So anyway, I am curious if the altitude is silently correctly by the barometer and there is no way to realize this without a model table.

(yes I know I can correct altitude with databases, several to choose from)

Maybe I am handling altitude wrong but it seems pretty clear, for each record that's the estimated altitude for that point in time, so if a previous point is lower that difference is ascent and if higher then descent.

Hmm maybe the formula is the elevation only counts if you've gone over or below the previous highest/lowest point. I'll try that algorithm unless this behavior is documented somewhere.

Top Replies

bricerosenzweig over 5 years ago in reply to RinseRepeat +1

I don't know if Garmin will disclose, but one way to calculate elevation gain that makes more sense is not necessarily fix sampling but to consider an increase or drop only for a specific threshold of…

All Replies

0 RinseRepeat over 5 years ago

Aha! It's the "coastline paradox" - learn something new every day.

Where sampling rate makes many angles/curves add up to a much longer distance.

https://en.wikipedia.org/wiki/Coastline_paradox

I am using the sample from every second.

Garmin obviously must sample far less.

What's interesting though is why the laps data adds up less, this is in comparison from every quarter mile.

Summary	distance	elevation	up	down
summary	7.02	-22.97	29.53	52.49
every second	7.02	-22.31	765.75	788.06
laps sum	7.02	-19.69	29.53	49.21

Which means Garmin must sample more than a quarter mile for the total. I wonder what the trigger is, maybe 400 meters since everything is natively calculated in meters but I think it has to be time based and not distance, not sure.

Will Garmin disclose? What is your sampling rate for altitude to elevation totals?

0 bricerosenzweig over 5 years ago in reply to RinseRepeat

I don't know if Garmin will disclose, but one way to calculate elevation gain that makes more sense is not necessarily fix sampling but to consider an increase or drop only for a specific threshold of change, For example, only consider a gain if the altitude is higher than 5 meter difference since the last considered altitude.

I use this technique in ConnectStats and for GPS tracks from garmin in practice I found a threshold of 5 meters seem to work pretty well. (https://github.com/roznet/connectstats/blob/master/ConnectStats/src/GCActivity%2BCachedTracks.m)

This page give a very good over view of the technique around computing elevation gain

https://www.gpsvisualizer.com/tutorials/elevation_gain.html

0 RinseRepeat over 5 years ago in reply to bricerosenzweig

threshold idea is very good thank you for suggestion

I already had code in place to limit the results to "sane" numbers so I simply tried adjusting the restricted values a bit

look at what happens when I set it to 1.75 meters as an allowed trigger range

Summary	distance	elevation	up	down
garmin	11.11	-9.84	167.32	177.17
my code	11.11	-9.84	198.82	208.66

(results converted to miles/feet)

notice how the difference is EXACTLY the same, very interesting but also much much closer

I just can' t get the total values to match but that may be either a sampling rate or some other variance that we can't deduce without more clues from Garmin

also the lap sum is different but that may be dropped data between the lap breaks where they use a different starting altitude for the lap

I've also come to the conclusion that ALL the altitudes/elevations in the FIT file are barometer enhanced because I looked at an old vivoactive FIT without barometer and the altitudes from GPS are way off, like 1000+ feet (probably also no calibration)

I don't see barometric pressure stored in the FIT file anywhere even on a Fenix, that's disappointing though could be added with a CIQ datafield of course but only two of those available.