[Solved: sensor malfunction] New ascent calculation algorithm is less accurate than before

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

[Chris_Dx]

@sky-runner I had the same problem with the calculation of positive and negative elevation gain. I sent my Suunto Race to the Suunto repair center to have the barometric sensor checked, and they replaced it because it was faulty. Since the repair, the calculation of positive and negative elevation gain is excellent, with very small differences compared to Strava, for example. The problem likely stems from the barometric sensor and the altitude measurement when you’re at home. If the value isn’t stable, the sensor needs to be replaced.

[sky-runner]

@Chris_Dx Yes, I have now realized that is the case.

Today I’ve done a run with another Suunto watch that I own - Rase S. I have just upgraded it to 5.20.28 and it worked correctly - no observable issues with how altitude tracking and ascent calculation works. I’ve repeated the same route again and the watch has measured 404 feet of ascent, which is consistent with Strava adjusted elevation gain and a tiny bit more than what I had with the 2.48.xx software.

@dimitrios-kanellopoulos, feel free to delete this thread. It is now clear that the issue that I reported above was caused by a sensor malfunction.

I’ll figure out if my Race Titanium needs repair. I’ve already tried cleaning the sensor port and that has been insufficient.

[Mff73]

@sky-runner it remembers an old experience with my Spartan Ultra. Searching a lot with the community why it would have strange baro / altitude behaviours, while after repairing it was so perfect. It happens unfortunately that HW is just the cause. (fridge test was the eye opener in my case).
It is also why it is important that when issues are raised by some (not you specifically ), Community users should also answer “no issue in the same circumstances”, to orientate the analysis.
Good luck with repair / warranty.