New ascent calculation algorithm is less accurate than before (Potential FusedAlti issue)

[soisan]

@sky-runner I think you overestimate the importance of your observations. I’m sure the new algorithm is based on a much bigger database of activities under a much greater terrain and weather conditions variation that yours. As is the case with the visibility of the trails in the maps of your area, your experience is just a small part of the whole picture! For me, under comparable terrain and weather with your case (rolling hills, stable conditions), the new algorithm works very well.

[sky-runner]

@soisan Perhaps I should change the title of my post. As I observed, perhaps the problem is not with the algorithm itself but with the fact that FusedAlti makes very rapid altitude changes that are not based on reality and that these altitude changes feed into ascent and descent calculation.

Would you agree that if someone stands still, the altitude should not start suddenly and rapidly change and that these changes in altitude should not impact ascent and descent? If I am standing still, I shouldn’t be getting extra ascent or descent at a rate reaching 12 meters per minute. That’s what I’ve observed.

If you haven’t observed any of that, it doesn’t mean that the algorithm is correct.
I’ve done a few dozen runs with with the new software. On most of them ascent and descent were fine. But there have been at least 3 runs already where the ascent was significantly exaggerated by as much as 20-30%.

Also, there is another thread that discusses a similar perhaps related issue:
https://forum.suunto.com/topic/14423/getting-too-much-ascent-descent-on-flat-routes

[GiPFELKiND]

Here is the first tread about this Problem.

https://forum.suunto.com/post/183088

[Dimitrios Kanellopoulos]

@GiPFELKiND that first post was a sensor issue analyzed

[Dimitrios Kanellopoulos]

Could you please provide a suunto app link in email so we can analyze the raw data and improve this ?

[sky-runner]

Here is a bit more analysis related to my original post at the top.

1. Here is the entire altitude profile overlayed with cadence to make it easier to identify points on the graph (this was a run with dog so a lot of stops)
   

2. GNSS altitude vs. barometric altitude from https://smlanal.szmigiel.design/ tool based on JSON data exported from Suunto App:
   

3. Altitude profile from Strava after altitude correction:
   

A few things to notice. For the most part, these are paved suburban streets so there are no sharp changes in altitude. The Suunto altitude graph looks way too “noisy”. Strava corrected altitude looks much more realistic to me based on my knowledge of this area where I run almost every day. The GNSS altitude looks more realistic too.

Looking at how noisy the barometric altitude is makes me realize that perhaps the barometer port got dirty and needs cleaning. I recall a having a similar issue once in the past and it got better after cleaning. Could that be the case? I’ll give that a try.

[jjpaz]

@Dimitrios-Kanellopoulos said in New ascent calculation algorithm is less accurate than before (Potential FusedAlti issue):

Could you please provide a suunto app link in email so we can analyze the raw data and improve this ?

I cand send you an activity, flat, running along a seafront promenade in which Race2 measured ~70m+/~70m- and Vertical around 85m+/85m- adding little +1m ascent changes during the run.

Maybe the algorithm is now very sensitive to those little ±1m changes, or maybe I’m wrong and I have acummulated 70m+ running close to the sea.

[sky-runner]

So today I ran the same route as above with Suunto Race S that still has 2.48.16 software. The result is the following:

Race S (2.48.16): total ascent: 393 ft, with adjusted elevation in Strava: 414 ft
Race (2.50.xx): total ascent: 563 ft, with adjusted elevation in Strava: 426 ft

As you can see Strava numbers are fairly consistent and the previous algorithm that I still have on Race S is a bit conservative, but reasonably close. That is consistent with what I have observed before.

Next, I am going to upgrade Race S to 2.50.28 to see how that change the numbers on the same route. Also I’ve just soaked Race in water to clean the barometer port in case it was dirty. I’ll repeat the test afterwards.

[duffman19]

@sky-runner I’ve only noticed a very slight increase in ascent/descent on my normal routes, which is to be expected if the tolerance is more sensitive now. I haven’t noticed any drift while standing still, although I haven’t paid that close attention. I also have an elevation specific data page for most of my activities. I’ll try to keep a closer eye on it to see it I spot anything fishy. (I’m using an SV1 and 9PP, though.)

On a positive note, I have documented several instances where the decreased threshold has resulted in a more accurate addition of altitude gain/loss. A regular hill repeat route of mine has an interesting profile. The turnaround point is not at the apex of the hill, but another ~150m farther with a very slight downhill with 3-4m vertical loss. So the profile (pictured below) has a little dimple at the tops instead of looking like a clean up-and-down. Previous software would rarely register those little dips, but the new one correctly captures it as shown by the numbers highlighted in blue.

I’m glad they made the adjustment to the threshold since I recall we both complained about it in the past, but judging by yours and @jjpaz experiences on more flat terrain, it looks like it still needs a little work.

[maszop]

@sky-runner I think you’re slightly overestimating the capabilities of a watch’s altimeter. No device can accurately measure altitude.

Barometric altimeters are the best at this, but even they aren’t foolproof. Sometimes all it takes is a slight gust of wind, a more exposed section of the route (a mountain summit or ridge, a wide crossroads in the city) for slight pressure changes to be interpreted as changes in altitude. Especially now that the altimeter in Suunto watches has become more sensitive.