Accuracy of total ascent and descent in Basecamp

I’m not familiar with ViewRanger or your particular device, but I will try to explain how Garmin outdoor devices work and changes that have occurred over the years.  I cannot tell you if the changes have been implemented on your device.

You need to understand the difference between the Trip Computer on your device and a Track Log.  The page on your device that shows current location, distance travelled etc. updates every second.  The Track Log only logs a subset of this data base on device settings.  The more data collected, the greater the accumulated error.  The slower you travel, the greater the relative error over the distance traveled.

Garmin elevation data depends on whether or not your device has a barometric altimeter sensor.  If it does, then elevation is based on the sensor and its settings.  If not, then the device records an elevation based on GPS elevation and an earth model of mean sea level.

In the past, there has been a confusion about why the Trip Computer data differed from the downloaded track log.  Garmin has made two changes to their devices to address this.  One is they made the Trip Computer a little smarter.  It no longer logs every position solution, but only those where it decides the device has changed locations.  This improved the total distance travelled, particularly for those just meandering about.  The second change was to include the Trip Computer summary data with the downloaded Trip Log data.

This second change means that you no longer see summary data based on the data in the track log, but that of the trip computer.  So, the device and BaseCamp agree exactly; but in truth, this is not a good thing to do.

If you are seeing Trip Computer summary data in BaseCamp, you can force recalculation based on the logged track data by deleting a single point in the track or dividing the track and then rejoining the track fragments.  The former removes one data point, the latter adds one data point.  The added point is a duplicate of one of the original track points.

If your map contains a digital elevation model, you can change the elevation data of the track points to that based on the elevation model.  If you map has an elevation model you will see coordinate and elevation data change on the bottom bar/left corner of BaseCamp as you move the cursor around the map when the map window is selected.  If not, you will only see the Lat/Lon data.

You may be able to improve total ascent/descent by altering the frequency data is collected in the track log on the device.

I suggest that you export one of your tracks in BaseCamp.  Then make a duplicate (s)of that track and play around with deleting a point and dividing/rejoining the track to see what changes occur.

I also suggest you read the excellent tutorial on calculating elevation gain in the FAQs section of the GPSVisualizer site which will give you some options to try. BaseCamp also is able to filter the track data in a similar way.

As far as I know, the Etrex25 does not have a barometric altimeter, so both your Etrex and the ViewRanger app are recording GPS elevation data. The app is taking elevations derived from the trackpoint positional data and an internal digital elevation model (DEM) which they call a Map Elevation File before displaying it. Your Etrex is outputting the raw data to BaseCamp where you need to decide how to filter it or use DEM. You can easily do this in GPSVisualiser if your map lacks DEM data.

Just to clarify; Garmin devices without an altimeter record elevations relative to mean sea level based on GPS elevation (relative to GPS ellipsoid) and a Geoid model (hypothetical shape of earth coinciding with mean sea level).

Thanks for the clarification. I tried your suggestion of deleting a single track point in BaseCamp and was amazed by the effect in taking out a substantial amount of the recorded excess ascent.

Do you happen to know what algorithm Garmin uses to determine when to set a track point when the auto option is selected I.e. not using a fixed time or distance interval?

Also ... do you know why Garmin uses a one second sampling frequency for taking elevation data from the barometric altimeter Into the Total Ascent figures as viewed in the Trip Computer and if it has changed what the new frequency or algorithm is?

No, I do not the actual algorithm, but I would assume that there is a time element and a change in course element.  That is a point will be logged after a maximum number of seconds regardless of whether the device determines you to be stationary or moving on the same course.  Additionally, a point will be logged if the there is a change in course that exceeds a certain value.   I doubt that a change in elevation would trigger a point to be logged.

The hardware in most if not all consumer GPS receivers are set to determine a position at one second intervals.  This has the advantage that when the device calculates the distance between adjacent readings, it has also calculated the speed in meters/second. (GPS units are seconds for time, meters for distance/elevation and +/- decimal degrees for lat/lon regardless of your device settings).

If one considers auto-routing, it is easy to imagine problems that could arise if a user could switch the frequency of position determination and set it to say 5 seconds.  At 30 mph, you travel around 200 ft in 5 seconds.  This could cause a device in a city to announce a turn with very little time to change lanes or perhaps a block to early.

Positions consist of 4 elements, time, latitude, longitude and elevation.  The only change that I have ever noticed with regards to the trip computer is that Garmin added an algorithm to determine if it is likely that a change in horizontal position (latitude and longitude) occurred in a 1 second interval.  If not, then trip computer doesn't update distance traveled or ascent/descent data.  I assume this is still in effect.

FYI for devices with barometric sensors, setting the device to fixed elevation will force the device to ignore the sensor and record elevation based on the GPS value.

Thank you - that's helpful.

I wonder why Garmin don't have a "Track Log Filtered Total Ascent" data field that captures the total ascent based on the Track Log device settings? At least that would allowed us to view more accurate total ascent figures on the device. Based on the "delete one trackpoint" method and fitting the track to a DEM, my GPSmap 66st is over-estimating Total Ascent by some 30% in the Trip Computer.

Perhaps they do.  If you save a track on your device, you can bring up track data by selecting it with the Track Manager, choosing View on Map, then press menu to provide an option to review the track..  I don't know if one will see the trip computer header or results based on the log, but it is something you can try.  It might also work on the Current Track.

If anyone from Garmin monitors these forums, it is my opinion is that the decision to add a header to tracks containing trip computer data is wrong.  A summary of a Track Log should be based only on the points actually in the log.

I agree that writing summary data that doesn't match the track data in the same file is very confusing and  a bad idea.

That's a good suggestion about the Track Manager ... unfortunately the on-device review of the information about the saved track simply reads the summary data from the GPX file., as does the review of the recorded FIT file. I have yet to try reviewing the Current Activity screen, but am not hopeful!