Problem of cumulative elevation gain

Here is an illustration of how Suunto 9 ignores a lot of smaller climbs even though they exceed the 3 meter (10 ft) threshold. This is a screenshot of elevation profile from my today’s short run with a dog. Just to be clear, this is exactly what the watch barometer has captured, so I am comparing the watch absolute altitudes to the total ascent that it counted for the same run. All altitudes are in feet:

Screen Shot 2019-10-20 at 8.17.43 PM.png

Here are elevations at a few points into the run where the vertical direction has changed in excess of the 3 meter threshold:

Start: 203 ft
1’22: 187 ft
4’16: 205 ft (18 ft gain)
5’08: 193 ft
6’16: 216 ft (23 ft gain)
10’54: 128 ft
12’14: 140 ft (12 ft gain)
22’38: 110 ft
26’32: 195 ft (85 ft gain)
27’22: 185 ft
End: 214 ft (29 ft gain)

Adding all small gains the total comes to 167 ft.

The watch shows only 112 ft total ascent. I think the watch has counted only the final climb from 110 ft to 214 ft and perhaps a part of the climb in the beginning. For comparison, Strava shows 187 ft, which is too much but still closer to the reality than the Suunto’s low number.

freeheeler

@silentvoyager
I never noticed this before as I normally go one bigger uphill, then downhill… looks like s9b can’t handle intervals up/downs not consistent

stromdiddily

@silentvoyager so it’s not necessarily a problem with the +/- 3m threshold but rather the way the algo is actually handling the changes?

Brad_Olwin

@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.

PatBess

@Brad_Olwin In the S9B diary, the elevation is not right, so it’s the watch, not the app. Should an algo correction improve cumulative elevation accuracy ?
How can we explain the issue to Suunto ?

freeheeler

@PatBess
I’m not 100% sure but I think @Dimitrios-Kanellopoulos knows this kind of issue already and might have forwarded it to the developers. It’s not a brand new discussion for my info. We’ve had in mainly for non Baro watches where the offset is much bigger

suzzlo

@TELE-HO yes, it has been discussed, and someone (sorry I could not remember who) give some ideas for improvements… I think it has been passed to developers, but how knows… anyway it seems to be not so easy to include this little up/downs… for me it’s annoying, because my Suunto has no baro, so there must be ¿7m? of elevation to accumulate it…

Ahh now I could remember that some of us, say that we will be happy signing a NDA and testing new FW with changes for this issue

BR

@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.