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

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

Unread post by Themistokles »

So I did another test, this time using my Oregon 700 (which is also brand new), riding exactly the same route.

And guess what: The Oregon 700 showed the correct total ascent at the end of the ride (in fact, it exaggerated, but not too much so it is acceptable). Furthermore, the Oregon 700's altimeter is very fast compared to the extremely slow one of the GPSmap 66s. When going down a steep descent (e.g 60 height meters) very fast and suddenly stopping at its end, it needs only 1 or 2 seconds to bring the elevation displayed within a reasonable approximation of the real value, and it needs only 5 seconds or so to bring it with within 1 or 2 meters to the real value.

I will never get how the elevation measurement and the total ascent algorithm can be so good on one device type and can be messed up completely on another one. They just should take the respective software part of the Oregon and implant it into the GPSmap 66. I don't think that the pressure measurement hardware is much different in the two ...

However, I still have the hope and consider it possible that the pressure sensor in my brand new 66s simply is defective. But I don't want to return the device just to get it exchanged with another one which has the same problem (which would happen if the problem is due to software).

So would anybody be willing to support me and do the same test as I did? That is,

- Choose a route / track where the total ascent mainly is made up of short descent / ascent pairs of (e.g.) 10 height meters, making up for 200 or 300 height meters of total ascent,

- Wait for stable weather conditions and ride this route with a GPSmap 66s, calibrating the altimeter of the device roughly to the correct elevation at the starting point, and note the total ascent shown by the device at the end of the ride,

- Do the same with another device, preferably an Oregon 700, calibrating the altimeter to the same value as that one of the GPSmap 66s at the starting point,

- Finally compare the both total ascents noted in the previous steps / tell us the figures.

As noted in my previous posts, I am in no way interested in the figures which external software produces (Basecamp, Strava etc.). I am solely interested in the total ascent the devices themselves show after the respective ride.

I would be very glad if somebody could do that test. If it turns out that this guy's (or girl's) GPSmap 66s shows (nearly) the same total ascent as his or her other device, I would know that my GPSmap 66s is defective, and I could return it with the real chance of getting a new one which does not have the problem I've described in my previous posts.

Thank you very much in advance! And of course, I am grateful for any other suggestion ...
User avatar
GPSrChive
Site Admin
Posts: 3882
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 want to do this test, but it may be a little while before I can complete it. I have the required equipment, but a few other things have to line up correctly before I can complete it.
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 »

Thank you very much, @gpsrchive. This for sure will help a lot ... To avoid misunderstandings, I dare to stress again that I have automatic calibration off on both devices :-)

In the meantime, I am thinking about contacting the Garmin customer care (here in Germany) and ask them if they would be willing to send me another GPSmap 66s for testing purposes, which I would give back to them when my tests are finished. But I am quite sure that they won't do this, so I am a bit reluctant with asking them ...
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 Do you already have plans when you could do that test? I haven't used my GPSmap 66s for 3 weeks now because of that problem, so I would be very interested in your results to decide if I should return it because it's defective ...
steerage250
Posts: 98
Joined: Fri Jan 04, 2019 2:48 am

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

Unread post by steerage250 »

So, this information might be interesting - or just totally confuse the picture by adding "noise".

I had seen the title of this thread in the forum, but had not read it so had no idea what the issue was. My wife and I were out on a bush walk (I know - no fast descents etc), and I thought I would pay attention to total ascent (never having looked at it before).

I have attached 2 photos:

1: is an analysis by an old program of the exported GPX track file (recorded at 1 sec intervals). When you look at the min and max elevations, then the amount of "ups and downs" in the elevation, you can almost believe the total ascent/descent of 370/359m is about right.

2: a screenshot from the GPSMAP 66st at the end of the walk. It is VERY hard to believe the total ascent/descent figures it calculated of 796/789m.

My altimeter settings are factory defaults.
You do not have the required permissions to view the files attached to this post.
steerage250
Posts: 98
Joined: Fri Jan 04, 2019 2:48 am

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

Unread post by steerage250 »

During the above walk, I did notice the altimeter readings were a bit "funny", but with limited observation time, hadn't come-up with a theory. Since the end of the walk was all uphill, I was entertaining my wife with the "vertical distance to destination" figure, and noticed that after walking down a small slope, it didn't increase as expected, and vice-versa. A slow response time could be a good explanation for what I was seeing.
User avatar
GPSrChive
Site Admin
Posts: 3882
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 »

How did you get that software to analyze a Garmin GPX file?
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 »

@gpsrchive
Trackan needs the file in OziExplorer .plt format, so you will have to convert it using GPSBabel or similar.

@steerage250

The explanation for the difference between the 66st and the Trackan figures is straight forward - see the earlier thread entitled "Total Ascent Figures". Essentially Garmin writes the summary data seen on the GPSr into the GPX file based on all the positions it records during the activity, however it only writes a subset of the position data as track points according to the preference you set in the Recording Settings menu.

When you upload the GPX track to a track analyser such as Trakan, it is recalculating the data based on the recorded track points and ignores the summary statistics. In your Trackan screen shot, you have the vertical filter set to 15m. If I'm not mistaken, this setting further filters the data from the track file (eg try resetting it to 1m and you will see the total ascent figure increase).

Also I noticed that it was raining when you were out. The hole that lets air into the barometer can become clogged with water which may also affect the reported altitude. This is also mentioned by gpsrchive in the earlier post.

It is a different question as to how accurate the total ascent figures recorded by the 66 device actually are. This is a multifactorial issue centred around the higher error in vertical accuracy compared with horizontal accuracy complicated by everything that degrades this accuracy on the day eg poor position of satellites (high dilution of precision (DOP), ionospheric effects, presence of tree canopy (especially if wet), multipath reflection errors, signal attenuation by your body or by water, differential wind speeds affecting the barometric altitude reading (higher wind speed gives lower pressure and higher apparent elevation), differential temperatures (inside building vs outside vs in car) as altimeter is not temperature corrected etc and the recorded frequency of data points. We are usually comparing our data to topographic maps or digital elevation mode which have their own inaccuracies anyway, so it is tough to work out the correct figure.

There has been a lot of debate about the calibration of the barometric altimeter.

These two threads support the use of first calibrating manually to a known altitude and then using autocalibration (which is generally how I use mine in the UK):
https://forums.geocaching.com/GC/index. ... -treatise/
https://forums.geocaching.com/GC/index. ... -evidence/

Garmin explain some of the background to this in their 2007 patent application which is worth a read - look at Fig 3 - the total ascent we see recorded is summing all the errors in trace B or C compared to the actual data in trace A. https://patents.google.com/patent/US20070040732A1/en
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 »

@steerage250

At first, thank you very much for your contribution and your effort.

As @Spiney has explained correctly, each software will give you a different total ascent figure for the same GPX track. This is because each software applies some sort of filter to smooth the height curve.

It is similar to the coast line paradoxon: A coast actually is infinitely long if you first go down to the rock or stone level, then go further down to the sand grain level, then delve into atomic or sub-atomic level, and so on. However, you have official figures of how long a coast line is, based on smoothing methods (i.e. filters) which most people (and probably some expert committee) have agreed to be reasonable.

The same applies to height measurements. One of the key points here is that even the device itself does smoothing before storing a value to the track. Otherwise, you would have erroneous values in the track (due to outliers and reproducibility of hardware sensor values). Then the device applies further filters to compute the total ascent (because otherwise it would measure every trunk of a fallen tree which you climb over on your way).

When you feed your track to external software, that software applies its own smoothing filters to compute the total ascent. Further problems arise when you let the track convert by GPSBabel or similar software; depending on the software and its settings, track points might get lost or might even be added (interpolation), and further (smoothing) filters might be applied.

That is exactly the reason why I wrote in my first post that I am not interested in what external software does. I am solely interested in what the GPS device thinks the total ascent is. After all, when doing my sports, I don't carry a laptop with me, so I have to rely solely on my GPS device, and the total ascent is one of the most important figures to me; actually, when being in the mountains with my MTB, it is the most important one:

From my knowledge of the total ascent of the planned trip, I can easily compute the remaining total ascent when I know the total ascent I already have made. The remaining total ascent in turn decides what to do if I get into trouble (injury, bonk, thirst, heat stroke, other weakness, problems with the heart and so on - all sort of things already seen with other people).

So your problem is interesting, but different to mine. I still have the problem that the total ascent the GPSmap 66s shows is way too low compared to the figures which a reasonable person would get if computing the total ascent manually, and compared to the figures other Germin devices (Oregon 700, GPSmap 64s) show.

Therefore, I still very strongly would like to know if only my GPSmap 66s has this problem or if this is an error in production which affects each device. My Oregon 700 does it right. Actually, it slightly exaggerates, but basically shows the same total ascent values as my older devices (GPSmap 62s, Oregon 600) for many different routes. In contrast, the GPSmap 66s shows a total ascent which is too low by at least 20%.
steerage250
Posts: 98
Joined: Fri Jan 04, 2019 2:48 am

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

Unread post by steerage250 »

gpsrchive wrote: Sun Aug 11, 2019 4:26 pm How did you get that software to analyze a Garmin GPX file?
I import the GPX into OziExplorer, then export a .PLT file
Post Reply

Return to “GPSMAP 66s/st”