Accuracy of Tracks From a Garmin Etrex GPS Receiver: Measured Vs. Waypoints

This is my second analysis of the accuracy of tracks from a Garmin Etrex GPS Receiver. The first analysis compared the accuracy of saved tracks vs. the current track in memory. See that analysis for an introduction to this page. This analysis compares the accuracy of the current track in memory vs. carefully chosen waypoints saved along the current track.

The Etrex software version used for this analysis is 2.05. Note that there are free later software updates, including "improvements in positioning to fix erroneous track logs" in version 2.09. I'll test this software improvement next to see if this has anything to do with my findings below.

In the course of using a Garmin Etrex GPS Receiver over the past six months, it has gradually become clear to me that the tracks give a poor rendition of a hiking trail with tight switchbacks or curves on small scales. Mileages deduced by the Topo! software for such trails have similar inaccuracies that arise from a similar source, albeit from a much simplified algorithm compared to the GPS track computation algorithm.

Because the basic algorithms used to convert individual measured GPS positions to a route have not been made available, one can only guess at what those algorithms do based on analyzing the data they produce. Although my initial impression was that "overall these algorithms do a pretty good job", I have seen many examples now of tracks that are much poorer than they should have been, given the quality of the positions input to the algorithm.

Hence on 31 December 2000, I decided to record a waypoint along the Dripping Springs Trail every time the trail changed directions. In each case, I waited at least 5 seconds before recording a waypoint, to make sure that the GPS had updated its readings to correspond to those points.

Those waypoints therefore defined a straight-line approximation to the trail using lines as short as necessary to accurately follow the trail. The trail was very well approximated by my waypoints, with essentially no "S" curves that were not fit by straight lines between my waypoints.

This comparison is especially interesting in that I don't have to guess what input coordinates the Etrex is using to define the track. The input coordinates have to be those defined by the waypoints and, to within the stated accuracy of the data, a linear interpolation between them. Furthermore, this analysis is independent of any systematic error caused by poor satellite geometry or any other reason, since it simply analyzes how well the computed track fits the input coordinates.

Furthermore, I have hiked this trail numerous times and thus am intimately familiar with the actual small scale twists and turns of the trail. Defining the waypoints in such a fashion also helped to fix these turns in my memory and gives a record of how many such twists exist.

I recorded 90 waypoints in the first ~2.5 miles of trail. The track in memory was defined by 54 points. In order to define so many waypoints, I carried the Etrex in my hand and viewed the accuracy screen regularly. For this trip, the stated accuracy on the screen was virtually always ~20', varying from ~16' to 24' at least 90% of the time. I have no idea whether this is supposed to be a one sigma radial distance, a 95% confidence radial distance, or something else. It appears, from the limited data present below, that this is probably something close to a 95% confidence radial distance.

The following plot shows the comparison of the route defined by the waypoints (red) and the route defined by the Etrex receiver (blue):

plot of route defined by the waypoints (red) and the route defined by the Etrex receiver (blue)

The longitude of the tick mark at the right hand side of the map is -116.9765° (Excel 97 failed to put a label there). A scale is given in the figure showing a distance of 20 feet, both in latitude and longitude, which corresponds to the usual stated accuracy of the coordinates.

The route defined by the waypoints is an excellent representation of the actual trail. This is the area just before, and including, the first set of switchbacks at mile 2.08, heading south along the trail. In particular, point #11 is the westernmost point just south of the middle of the above plot, with the first four switchbacks farther south. This representation not only matches my memory of today's hike, but also agrees well when plotted on the USGS topographic map with respect to the location of the ridgeline which the trail is ascending, which I have carefully noted in the past.

This plot shows dramatically how poor the track approximation is to the data on small scales, as well as how well the track approximation is to the data on larger scales.

On scales larger than ~300', the track is a good approximation of the data. However, on scales smaller than ~300', the track does not represent the data. In particular, there are two points at which the error is ~200', to the left and right of the blue track near the word "Waypoints" on the map. The typical error of the track in many other places on this map is ~50'.

The individual waypoints seem to have positional accuracies with one sigma well under 20'. For example, examine the pairs of points at several of the switchbacks at bottom. These are points separated by perhaps 10', which were taken to help approximate the curves at the very point of the switchbacks. If the one sigma scatter of these points were 20', the red curve would not be so well-defined at these points, especially in the direction perpendicular to the trail. Furthermore, the waypoints falling east of the blue line at top right in the plot have a cross-track position consistency of under 10'. Thus it seems that the quoted 20' accuracy corresponds to something like a 95% confidence radial position error. Further analysis is needed to determine the precise confidence level.

Thus the error of ~50' in many places is well outside the uncertainties in the data. This, together with the two examples of an ~200' error, implies that the algorithm used to compute the track itself has some bias against following a trail to an accuracy better than ~100' in general.

My experience in the past six months has been that the "odometer" reading from the Etrex is typically only ~80-90% of the true mileage I have hiked. The source of this underestimation is now clearly seen to be this "smoothing" of the track compared to the actual trail.

Thus to accurately record trails with an Etrex, one must manually record waypoints every time the trail deviates from a straight line from a previous waypoint.

An error of 100' is suspiciously similar to the error introduced by Selective Availability. Thus I conjecture that Garmin has simply never revisited their track algorithm after the demise of SA.

Please note that the only criticism of Garmin intended here is in not making available the characteristics of their track computation algorithm, especially since it is complex software. The Etrex receiver seems to be an excellent GPS receiver, capable of defining trails to high accuracy. However, it is quite annoying that individual users are left to understand these characteristics on their own, without any guidance from Garmin in the Etrex manual or from their website. It has taken me six months to understand that I cannot rely on the computed track to represent a hiking trail with the accuracy quoted on the Etrex display.

Go to:

Copyright © 2000-2001 by Tom Chester.
Permission is freely granted to reproduce any or all of this page as long as credit is given to me at this source:
Comments and feedback: Tom Chester
Last update: 1 January 2001