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

maszop

@sky-runner I’ve been using the new algorithm in moderately winds, and it seems to work very well.
As for Strava, in the mountains Strava’s correction is typically underestimated by 20-30%.
The higher the accuracy, the higher the results.

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

sky-runner

@maszop My run wasn’t in mountains but on a suburban streets with mild hills - in general wide open terrain with no tall buildings and no sharp changes in elevation. As I explained above, I was looking at the ascent field and elevation during the run. The elevation dropped several meters in a minute while I was stopped at a stoplight. That is wrong by itself. Then the elevation kept going up over 5 meters while I was running downhill. There was no wind. I’ve never seen Strava being so much wrong on this terrain, so I think the problem is with the new Suunto algorithm. With the previous algorithm, altitude produced by Suunto Race seemed to be over-smoothed, but now it is opposite - it occasionally has these small bumps and sharp changes in elevation that aren’t real.

I suspect the problem is caused by FusedAlti. I’ll look at the JSON data later today and see if I can spot a problem.

duffman19

@sky-runner said in New ascent calculation algorithm is less accurate than before:

I suspect the problem is caused by FusedAlti.

That’d be my bet as well. Maybe Suunto forgot to update FusedAlti to play nice with the new algo. FWIW, I haven’t seen any big changes in altitude readings while on my neighborhood runs and walks (generally flat with some gentle rolling hills). I’ve actually been doing comparisons with my 9P non-Pro and the descent/ascent numbers have been comparable even with this older software.

sky-runner

@duffman19 I’ve just done another short run with the dog where I stopped several times and watched altitude changes on the watch. I have a data screen dedicated to vertical data which includes altitude, ascent, descent, and vertical speed, so I was able to see what the watch is doing.

My conclusion: the existing algorithm is incorrect!

There are two issues that I’ve observed:

When standing still there were several times during a 30 minute run when the altitude dropped very rapidly while I was standing still. At one point it showed a vertical speed of -38 ft / min while I was standing still. A normal altitude drift due to weather should not exceed 1 ft / min, and typically even less. The weather was good today with no wind.
These altitude changes that I assume are due to FusedAlti calibration go straight into ascent and descent. That is wrong!

So there are two sources of altitude data - GPS and barometer. GPS altitude is accurate but not precise, meaning that when averaged over longer intervals it will be true but in a short term it can vary quite a bit. On the other hand, barometric altitude is precise but not accurate. This means that relative deltas of altitude in a short interval of time are very accurate if we ignore the effect of wind gusts. The precision of Suunto barometric altitude is 20 cm. On the other hand the absolute value of barometric altitude is not true and needs calibration.

I think that while GPS should be used by FusedAlti algorithm to correct absolute altitude, these corrections should not be fed into relative ascent and descent changes. Ascent and descent should be calculated based only on relative short term changes in pressure. Furthermore the rapid change of the absolute altitude due to FusedAlti calibration is equally wrong. It should be happening more slowly so that low precision of GPS altitude doesn’t have an effect.

If the algorithm works correctly, we shouldn’t see ascent and descent changes while standing still, or at least they should be below the reasonable threshold of perhaps 1 meter per minute at the worst. That would correspond to the most severe weather changes.

I think Suunto should revert this algorithm and go back to further improving it before redeploying it again.

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.

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)
GNSS altitude vs. barometric altitude from https://smlanal.szmigiel.design/ tool based on JSON data exported from Suunto App:
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.

Selección_5094.png

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.