Problem of cumulative elevation gain

@Brad_Olwin said in Problem of cumulative elevation gain:

@TELE-HO @silentvoyager @stromdiddily I have noticed this issue on smaller ascents/descents as well. I normally do much bigger climbs and descents, on the larger ones the S9b does a very good job. Would be interesting if it was the app and not the watch.

The error is proportional to a number of climbs rather than the total ascent, and my estimate that it is on the order of 3 meters per climb. So if a run consists of one or two big climbs the error is relatively small to not be noticeable. But if a run goes on rolling terrain with constantly going up and down the error accumulates quickly.

In my custom trail running mode for small to medium runs I have total ascent next to the current altitude on the same screen, so I often watch the two metrics together.
I can tell you that the total ascent increases in chunks and with a noticeable delay. For example I keep going uphill and I see that the altitude goes up but the total ascent stays the same for awhile, then increases by 10-12 feet (3-4 meters). If I crest a hill quickly it doesn’t capture the last few meters of the climb. But I noticed that if I stop at the top and wait for about 5-10 seconds then the total ascent may go up.

So it is definitely the watch itself that does some sort of delayed averaging in addition to the threshold to filter out small pressure changes. But I think the way watch does that is overly conservative.

suzzlo

@silentvoyager yes I think it’s 3m for baro, and 7m for non baro units (or something similar)…

suzzlo

@silentvoyager ehh,m you were the guy that proposed new algo https://forum.suunto.com/topic/3078/let-s-talk-about-elevation-gain-counting-on-suunto-watches!!!

freeheeler

@suzzlo
yep and i was happy that suunto does not count the meter when i adjust a skiboot buckle or something similar… but the truth or the target for good ascent calculation is somewhere between these 3m and bending down to pickup a snack out of the backpack on the ground

Maryn

@silentvoyager I also did notice same behaviour

@TELE-HO said in Problem of cumulative elevation gain:

@suzzlo
yep and i was happy that suunto does not count the meter when i adjust a skiboot buckle or something similar… but the truth or the target for good ascent calculation is somewhere between these 3m and bending down to pickup a snack out of the backpack on the ground

@TELE-HO, read the post linked above. I don’t advocate for removing the threshold. Bending to tie laces isn’t a big deal. The real issue is windy weather. Even with the threshold wind gusts may produce a lot of false elevation changes. But the algorithm could be improved to more accurately track the changes once the threshold is exceeded.

freeheeler

@silentvoyager
how its solved will be up to the developers i guess… last week i thought of maybe letting fusedalti check more often or filter too fast climbs? maybe not for paragliding…!

Brad_Olwin

@PatBess Suunto is aware of issues with altitude but it is a difficult one as arm movements for example need to be filtered out of the altitude gains. My altitude has been fairly reliable with the S9b, most of the time FusedAlti is activated and my gains/losses are close to those I have obtained with other watches.

@Brad_Olwin It isn’t a difficult issue at all. I’ve described the algorithm in details in my post (linked above) and it can be described in just a few sentences. By the way, I am a developer in a very well known software company myself.

Brad_Olwin

@silentvoyager said in Problem of cumulative elevation gain:

@Brad_Olwin It isn’t a difficult issue at all. I’ve described the algorithm in details in my post (linked above) and it can be described in just a few sentences. By the way, I am a developer in a very well known software company myself.

I know you are and I am not a software developer so definitely out of my league here. I agree that the averaging may be overly conservative as you posted below. However, if less conservative do you believe it would then be more accurate? I know enough about the testing to suspect that different averaging approaches were likely attempted.

Typically I watch total gain and elevation on long climbs that are not very fast so I do not see the delay in averaging. In non-baro watches the situation is much worse. Unless I am doing a big climb the elevation gain/loss is typically well below the actual value.

stromdiddily

@silentvoyager can you walk me through how your proposal would handle a point to point route of 3m up, 2m down every 10m over 100m run?

Unless I’m reading it wrong, you’re suggesting that the “going down” calculation doesn’t kick in until you’ve triggered the min threshold from your “recent high” reading. Wouldn’t this end up with 0m descent over my example run?

@stromdiddily Do you think the current algorithm would produce non zero descent? It would be good to try but I doubt the result would be any different.

@stromdiddily Just to give you one specific example - not exactly what you are asking for but something that I’ve actually done. I once had hill repeats on a very small hill where I went up and down about 5 and half meters - that was the difference between the high and the low points based on the elevation profile. I didn’t have any better hills in that area. I went up and down 30 times. My Suunto 9 counted only 90 meters of total ascent and 90 meters of total descent.

freeheeler

@silentvoyager
I’m not a software developer either, pure mechanics… but would it be possible to count every meter, store it and smooth the graph later with doublecheck of the independently stored gps alti graph?

Fiox89 · Suunto Spartan Sport FW: 2.8.24 SA: 4.17.7 beta

On a recent excursion I noticed that the watch (suunto spartan) correctly records the right total elevation, but when it goes to synchronize the track on the application this is different. Also, the track log on the watch shows a different measurement, once the activity is interrupted, the same as the app.

From what I understand, the problem occurs when the recording of the activity is interrupted, so it is in the post processing of the data. Can anyone confirm?

Dimitrios Kanellopoulos

@Fiox89 no post processing of data is done at all

freeheeler

@Dimitrios-Kanellopoulos
then smoothing the graph isn’t possible either as I understand…
there will be different options.
Suunto teams will solve that, I’m sure

FredMt

@silentvoyager

Yes i think your right, i practise running stairs. I have stop using elevation by suunto 9 baro because it was permantly under the reality. I used to do it by myself on movescount web site…, but now with Suunto app, it s impossible, elevation fields are not accessible in modification…

Also I suspect that on Suunto 9 FusedAlti makes the total ascent and descent less accurate. I think that when FusedAlti kicks in and adjusts the altitude, that isn’t properly reflected in ascent and descent calculations and may artificially increase or reduce ascent / descent numbers.

There is one run near my home that I tend to do a lot. That is a short 3.2 mile loop (just over 5 km). I ran it over 50 times - with Suunto 9 and earlier with A3P.

Looking at Suunto 9 Ascent / Descent numbers I see that the ranges or ascent and descent are greater and the difference between ascent and descent for any particular run is also greater.

More specifically ascent ranges from 188 to 246 ft, descent ranges from 184 to 259 ft, and the largest difference between ascent and descent in the same run is 50 ft (~ 17 meters).
The explanation that I’ve heard before is that due to the weather change.

However when I looked at earlier runs with A3P I’ve never seen a difference between ascent and descent for runs on this route greater than 10 ft (~ 3 meters).
The values in general seem to be distributed more tightly (with fewer outliers) and over slightly smaller ranges: ascent - 197 to 236 ft and descent - 197 to 246 ft.

freeheeler

@silentvoyager
and the question is: will Suunto be able to improve this?