GPSMAP 66s/st: Total ascent way too low (by 20% - 30%) [Bug 148]

Discussion related to the Garmin GPSMAP 66s/st GPSr
Themistokles
Posts: 45
Joined: Sun Jun 30, 2019 7:47 am

GPSMAP 66s/st: Total ascent way too low (by 20% - 30%) [Bug 148]

Unread post by Themistokles »

Hi all,

I have decided to open a new thread for my problem because my problem is the opposite of what I have read so far (here and at other websites):

While other people report the total ascent shown by the device or in Garmin Connect or Basecamp etc. to be too high, I am having the opposite problem. I use the device for mountain biking and have tested it several times while riding one of the smaller of my standard routes. I know this route exceptionally well because I have ridden it over 1000 times with several other GPS devices and because I have manually computed the total ascent using precise paper maps.

That route happens to have a total ascent of nearly exactly 250 height meters. This is confirmed by several other GPS devices like the Garmin GPSmap 62s and the Oregon 600; both of them always show a total ascent of 250 hm plus / minus some deviation (lower than 8 height meters). But the GPSmap 66s reports a total ascent of 213 height meters, which is an error of about 20%.

I have done some investigation on the issue and found two problems:

1) The altimeter itself is incredibly slow. The ride I am talking of has quite a lot of small descents (for example, 10 height meters) which are immediately followed by small ascents of the same magnitude. Now, when having gone down such a descent completely and already having done the half of the following ascent, the elevation shown in the display still counts down.

I haven't seen such misbehavior on other Garmin devices so far. It's clear that the device won't show the correct total ascent if it is not even able to show the correct elevation. It probably misses the lowest elevation when going down and then immediately going up some height meters.

2) To make things worse, I am constantly observing that the device does not sum up the differences in elevation correctly. For example, the elevation shown changes from 580 m to 585 m, but the total ascent only increases by 3 height meters.

The total ascent is nearly correct if and only if your route only has big ascents / descents (e.g. 100 height meters). The device will miss the first or last height meters with bigger ascents / descents as well; however, the relative error caused by this will be smaller the bigger the ascents / descents are.

I am a big fan of the GPSmap 66s - finally, a real quantum leap in the GPSmap series. I don't need that connected stuff, but the accuracy / reception is excellent, many, many annoyances in the UI have been fixed, and the bigger display alone for me was a reason to buy it.

Unfortunately, when mountain biking, I under no circumstances can accept a total ascent which I can't trust. 213 height meters instead of 250 is a deviation of about 20%. On a ride with 4000 height meters in unknown terrain, that makes up for 800 height meters. All other mountain bikers around here surely will agree that we need a precise total ascent to calculate the remaining ascent to decide how to use our energy and what to do if we get into trouble (sudden physical problem, weather, etc.).

Due to this reason, the device currently is unusable for me (and probably other mountain bikers). Can somebody else confirm or explain this misbehavior?

Thank you very much!

P.S. To avoid misunderstandings: I only care for the figures the device itself shows, i.e. this post is not about Garmin Connect, Strava, Basecamp and the like. Furthermore, I am sure the problem does nothing have to do with my altimeter settings (variable elevation, auto calibration off) - I have tested multiple times in multiple weather conditions, and my settings are the same as these on the other devices which correctly compute the total ascent.
User avatar
GPSrChive
Site Admin
Posts: 3881
Joined: Fri Jan 20, 2017 11:29 pm

Re: GPSMAP 66s/st: Total ascent way too low (by 20% - 30%) [Bug 148]

Unread post by GPSrChive »

What firmware version is your GPSMAP 66 running?
Spiney
Posts: 65
Joined: Thu Apr 04, 2019 9:35 am

Re: GPSMAP 66s/st: Total ascent way too low (by 20% - 30%) [Bug 148]

Unread post by Spiney »

Also, please will you share your altimeter calibration settings and the GPS accuracy you normally see on the ride.

My understanding is that Garmin used to calculate the summary statistics displayed in the Trip Computer using data captured at a frequency of once per second. Sometime more recently they changed this data capture to less than once per second using a proprietary algorithm which decides if the device has changed locations. This might account for your observations?

It might be worth you trying your ride again with the recording settings set to capture data at an interval of once per second and see if the Ascent increases to match that reported by your other devices.
Themistokles
Posts: 45
Joined: Sun Jun 30, 2019 7:47 am

Re: GPSMAP 66s/st: Total ascent way too low (by 20% - 30%) [Bug 148]

Unread post by Themistokles »

gpsrchive wrote: Sun Jun 30, 2019 5:07 pm What firmware version is your GPSMAP 66 running?
Of course, the newest one (3.00) :-), with GPS software 2.6.

I sometimes think that this perhaps is the problem. I have read here and elsewhere that they had problems with spikes in the altimeter measurements in previous firmware versions. To solve the problems with the spikes, they probably have implemented a smoothing filter and messed up its parameters. Although it would be interesting to downgrade and see if that theory is right, I currently don't want to do that.

Thank you very much!
Themistokles
Posts: 45
Joined: Sun Jun 30, 2019 7:47 am

Re: GPSMAP 66s/st: Total ascent way too low (by 20% - 30%) [Bug 148]

Unread post by Themistokles »

Spiney wrote: Sun Jun 30, 2019 9:44 pm Also, please will you share your altimeter calibration settings and the GPS accuracy you normally see on the ride.
This information is in the last part of my original message (which is longer than needed as I have to admit :-)). I prefer to turn off auto calibration and to manually calibrate the altimeter at the starting point of each ride, and this is how I have done the tests so far. But I am quite sure that this does not have anything to do with the problem.
Spiney wrote: Sun Jun 30, 2019 9:44 pm My understanding is that Garmin used to calculate the summary statistics displayed in the Trip Computer using data captured at a frequency of once per second. Sometime more recently they changed this data capture to less than once per second using a proprietary algorithm which decides if the device has changed locations. This might account for your observations?
The misbehavior could be due to two reasons:

First, as you are suggesting, the measurement might happen too rarely. However, when riding down one of those descents, I am changing location at a rate of about 10 meters per second. If the measurement rate is based on the change in location, it should measure quite fast in those situations, probably even faster than once per second (if implemented reasonably).

The previous rate of 1 measurement per second would be sufficient in my eyes (meaning: I could live with it, although faster would be better). I am generally wondering why they have changed the measurement method at all. As far as I can tell, the device does not have any issues with CPU power. So why did they decrease the measurement rate and mess up the altimeter?

Secondly, as I have speculated in my previous post, Garmin might have implemented a smoothing filter into the altimeter / total ascent measurment algorithm of firmware 3.00 to solve problems with spikes they obviously had, according to other reports on this forum and elsewhere. They might have messed up the filter parameters in doing so; in this case, a faster measurement wouldn't help.
Spiney wrote: Sun Jun 30, 2019 9:44 pm It might be worth you trying your ride again with the recording settings set to capture data at an interval of once per second and see if the Ascent increases to match that reported by your other devices.
This is a good idea, and in fact, I already have thought about that, too. However, I have come to the conclusion that this setting should only influence how the track is captured (i.e. the FIT / GPX file), but not how the device computes the total ascent.

Of course, I will try your suggestion and report back. I know the older devices (up to the Oregon 600) quite well, but don't have much experience with the newer ones, so I really hope that I'm wrong. I've got an exceptionally persistent and tough 3-week-long cold and have just absolved four subsequent training days since last Thursday, thereby testing the device. Now I need to recreate some days; I expect that I can report back at the end of the week.

By the way, I already have done some other tests in the meantime (during the past four training days): In the recording settings, you can choose an activity, and I was wondering how that would impact the recording of tracks of the computation of trip computer data. After thinking about it, I had the hope that it might change the settings of the filter I have mentioned above, since this indeed would make sense: For example, if hiking, the filter should (could) smooth heavier than if mountaineering.

But obviously, I was wrong: Choosing another activity in the recording settings changed exactly nothing with the height measurement / total ascent. I have tried "Cycling", "Mountaineering", "Hiking" and "Other" without the problem getting better or worse.
Themistokles
Posts: 45
Joined: Sun Jun 30, 2019 7:47 am

Re: GPSMAP 66s/st: Total ascent way too low (by 20% - 30%) [Bug 148]

Unread post by Themistokles »

Spiney wrote: Sun Jun 30, 2019 9:44 pm It might be worth you trying your ride again with the recording settings set to capture data at an interval of once per second and see if the Ascent increases to match that reported by your other devices.
Here we go: I did another ride yesterday on exactly the same route.

During the first half, I had the recording setting as-was (i.e. "Automatic"), but had changed the recording interval from "Normal" to "Most often". This did exactly nothing.

During the second half, I had changed the recording setting to "Time" and set the recording interval to one second. Again, this did exactly nothing.

In both cases, the altimeter still had a huge lag. Again, it needed 20 seconds or so to show the correct elevation to an accuracy of 1 m after a fast descent. And again, the total ascent was computed incorrectly as described in my previous posts.

Actually, this is exactly what I had expected. In my understanding, the recording settings tell the device how to record tracks (as the name implies), but not how to internally compute the current elevation or total ascent. The experimental results support my theory that there is some sort of filter in place when the device calculates the current elevation and the total ascent, and that this filter is implemented the wrong way.

Although I am really excited about that device (it would definitely be my favorite one if it wouldn't have that problem), I'll probably return it as defective. I just can't use it with that crappy elevation software (the rest of the software works without flaws as far as I can tell, at least the parts which I am interested in).

Too bad ...

Any other suggestions?
User avatar
GPSrChive
Site Admin
Posts: 3881
Joined: Fri Jan 20, 2017 11:29 pm

Re: GPSMAP 66s/st: Total ascent way too low (by 20% - 30%) [Bug 148]

Unread post by GPSrChive »

I left my GPSMAP 66 v310 (gps 270) recording a track log yesterday, all day long, for a round trip drive of nearly 150 miles. When I arrived back where I started, I paused the track log recording and saved it. I also captured screens from the Trip Computer and Recording Controls pages for later comparison.

I imported the saved *.GPX files into BaseCamp and observed the track log statistics compared to what was reported on the GPSMAP 66.

On the GPSMAP 66:
Ascent Total: 2931 feet
Descent Total: 2822 feet
(total difference = 109 feet, or 9 inches per mile traveled)

In BaseCamp:
Ascent Total: 2930 feet
Descent Total: 2822 feet
(total difference = 108 feet, or 9 inches per mile traveled)

After removing the first track point in BaseCamp:
Ascent Total: 2964 feet
Descent Total: 2859 feet
(total difference = 105 feet, or 9 inches per mile traveled)

I am not finding any issue with the Total Ascent or Descent here.
Spiney
Posts: 65
Joined: Thu Apr 04, 2019 9:35 am

Re: GPSMAP 66s/st: Total ascent way too low (by 20% - 30%) [Bug 148]

Unread post by Spiney »

That’s interesting - were you using the Auto recording option to capture your track?
User avatar
GPSrChive
Site Admin
Posts: 3881
Joined: Fri Jan 20, 2017 11:29 pm

Re: GPSMAP 66s/st: Total ascent way too low (by 20% - 30%) [Bug 148]

Unread post by GPSrChive »

Spiney wrote: Sun Jul 07, 2019 2:38 am That’s interesting - were you using the Auto recording option to capture your track?
Auto, More Often.
Themistokles
Posts: 45
Joined: Sun Jun 30, 2019 7:47 am

Re: GPSMAP 66s/st: Total ascent way too low (by 20% - 30%) [Bug 148]

Unread post by Themistokles »

@gpsrchive

At first, thank you very much for that test and for taking the time!

But actually, as stated in my first post, I'd prefer to not take Basecamp and other external software into account here. The main reason is that such software also uses filters to smooth the readings before calculating the total ascent. The total ascent value strongly depends on the filter settings. I even remember a software from a GPS device manufacturer that I've been using in former days where you could set the strength of the smoothing filter by dragging a slider in the UI. That way, for example given a real total ascent of 1000 height meters, I could make the total ascent reported by that software anything between 300 height meters and 2000 height meters ... Unfortunately, I can't remember any more who provided that software, so it is very well possible that it was not from Garmin.

However, for that reason, I am taking my other devices as a reference when evaluating the correctness of the total ascent shown, plus my own manual calculations which are based on precise paper maps. I didn't test my new Oregon 700 and Montana 610 yet, but my older GPSmap 62s and Oregon 600 show the correct total ascent (i.e. about 250 height meters on my test route), which is very close to the "theoretical" result from my manual calculations, while the new GPSmap 66s shows a total ascent of about 210 height meters. So there clearly is something wrong here.

Furthermore, it isn't a big surprise that Basecamp shows a total ascent close to the value the device shows. The main problem of the device is problem 1) described in my first post, i.e. the extreme slowness of the altimeter; problem 2) makes thing worse, but problem 1) is the dominating one. I am nearly sure that during recording it is exactly the elevation value shown in the display which is written to the GPX / FIT file. That means that the wrong (i.e. extremely lagged and filtered) elevation values go into the recording in the first place, which surely will make Basecamp compute the wrong total ascent the same way as the device does.

In other words, if I would let my Oregon 600 and my GPSmap 66s record that ride in parallel, and if I would feed both recordings into Basecamp and let Basecamp calculate the total ascent for each recording, the result would be different in the same way the total ascents shown in the devices' displays would be different.

So because Basecamp will operate on the elevation values recorded by the device, even if they are way off, we can't use Basecamp or any other external software as a measurement tool here.

Do you have steep descent nearby where you could confirm the slowness of the altimeter? For example, 50 height meters (about 150 ft, if I am right) which you could go down in 20 seconds or so?

If you would do that and suddenly stop at the end of the descent, you could observe how the altimeter needs 20 seconds or the like to show the correct elevation (unless my device is defective and yours isn't). And if you would turn at the end of the descent and immediately begin to go uphill in the opposite direction (instead of just stopping), you could observe that you already have gained several height meters (probably about 20 ft) before the device starts to count up the elevation again.

Something is heavily going wrong here ... something which does not go wrong on my older devices (GPSmap 62s, Oregon 600).
Post Reply

Return to “GPSMAP 66s/st”