I was suckered into buying a new Garmin GPS handheld unit (GPSmap 62stc) by a half-price offer from REI – Garmin stuff never goes on sale and my old device (GPSmap 60-something) was getting a little long of tooth. I’ve always had problems with large errors that Garmin has never solved (or even fully acknowledged) so I’m not in love with the old one. And the newer model has some cool-sounding features – nothing earth shaking.
The long-standing errors are in the way the device reports distance traveled and elevation gained. For distance it has an odometer that tries to keep track of your total distance as you move, the same as in your car. But it also has a tracking feature (Track Log) that saves your location frequently, and is capable of going back over those saved points at the end of the trip and totaling up the distances between the points. These two measurements should be pretty close but they hardly ever are – differences of 20-40% are not uncommon. Years ago I examined it pretty closely and found that I could fool the odometer at will just by moving very slowly (which we often do when climbing steep trails). I once carried the device a quarter mile, according to the track log, and the odometer showed only 20 feet or so!
Elevation is just about as bad. My favorite example was a hike to Boundary Way where the trailhead is at 4300 feet and the high point of the hike at 5300, a nice round net gain of 1000 feet. There were some ups and downs along the way that added a bit to the total but the device showed a total gain of 750 feet.
I could never get either Garmin or REI excited about these software errors; I got as far as talking to a Garmin engineer who was puzzled and seemed convinced that there was a problem, but he never got back to me and I didn’t have the energy to start the whole process over. REI has replaced the device a couple of times but they didn’t seem to give a hoot, either.
Excelsior Pass

Upward Track – 4.2 miles
My first outing with the new device was a simple hike in Lake Padden Park and the results looked very good. The odometer and the track log were in pretty close agreement and the track agreed closely with tracks I’ve saved from other hikes there, and where they differed the new one looked better. So I was optimistic on our first high country hike of the season. Excelsior Pass Trail is a 4- to 4.5 mile hike that climbs about 3500 vertical feet through the forest from Mount Baker Highway at 1800′ to 5300′ at the pass. We were not going to make it all the way because of the remaining snow but we were aiming for a nice little spot with a view of the pass about 3 miles along the trail at about 4400′.
About that “3 miles”. I have traveled this trail many times (including 2 weeks ago) and saved a number of track logs that all look pretty similar. They range from 4.1 to 4.4 miles long, which I consider to be an acceptable tolerance range. This is a challenging environment for GPS: climbing out of a deep, steep-sided valley through heavy tree cover. Rain would make it worse, since water absorbs microwave signals, but this was a dry day. All in all, I have a lot of confidence in the 3 mile estimate.
I checked the device frequently (which was more difficult that with previous devices since Garmin has really screwed up their system for attaching the device to your person) and the accuracy was staying down in the 20-30 feet range and the new track (the red line on the map) was close to the old one. We had one stop that was a bit longer than usual while we waited for a hiker who wasn’t feeling well, but otherwise we plugged right along, getting to the aforementioned spot just before noon. We hit snow just above 4000 feet and lost sight of the trail near the middle of that east-west-ish traverse (at the word “Mount”).
The map also shows the old track from last fall in yellow – most of it is obscured by the new track, showing 1) we kept close the trail until just before we stopped and b) there was quite a good bit of trail left. The white arrow points to our longest stop, at the Excelsior Flume – more on that later.
The Upshot
And soon as we settled down into the snow for lunch I checked the new device and it showed an odometer reading of 4.2 miles, which was simply absurd. And puzzling – I expect huge errors in the odometer, but they are usually on the low side.
So as usual, I would resort to the track log – which also said 4.2 miles! It was most ironic that the first time these two measures had ever agreed they were both hugely wrong! Most of what I said and thought for the next few minutes is not suitable for a family publication.
I resisted the urge to pitch the thing into the nearby creek, saved the track and continued the track logging after lunch. When we got back to the trailhead the odometer and the track log both read about 7.9 miles, giving 4.2 miles on the way up and 3.7 on the way down, along the exact same trail – on the snow I was even stepping in own footprints. I’ve seen discrepancies like that before, too, and have written it off to the fact that we are traveling a bit faster on the way down (and the devices are known to have trouble with slow travel.) I was eager to upload these tracks to my computer and see if I could make sense of this before I started haranguing Garmin and REI. Again.

Upward half-track – 3.6 miles?
At the Computer
The first thing I tried only added to my puzzlement. I transferred the two tracks,
- upward (4.2mi and 558 points) and
- round trip (7.9mi and 1200 points),
to the Garmin BaseCamp program and, just for the heck of it, I made a copy of the round trip, located the place where I had saved the upward track and split the track in two, giving me another upward half-track and a downward one. Result:
- upward (3.6 mi and 560 points)
- downward (3.3 mi and 641 points)
The last I checked 3.6 + 3.3 is a little shy of 7.9. What the φθψκ is going on? The map on the left shows this upward half-track made of the same 560 (or so) points as the 4.2 mile track – can you see any difference? I can’t.
The point counts are close enough to make it pretty clear that both devices (the GPS and BaseCamp, too) are working with the same raw data and somehow deriving significantly different results in different contexts.

BaseCamp track details
Getting Down and Dirty with the Data
I will be sending this data to Garmin, rest assured. You’d think a track that loses a mile, but not any points, when split in two would get an engineer’s attention. We shall see.
But I just couldn’t let this go. I wanted more ammunition before hacking my way through the telephone trees.
The first issue is “Where does that track length come from?” I’ve always assumed that the software is adding up the distances between each pair of successive points. In BaseCamp you see the display on the right, showing latitude and longitude for each point and the length (in feet) of each “leg”. There are way too many numbers to add up by hand and, moreover, are those distances accurate to begin with?
The latter question is a toughie, since it is not trivial to calculate the distance between two points given latitude and longitude – it involves spherical trigonometry, which I encountered for a couple of weeks in the spring of 1958. But it didn’t take root.

Track details – UTM coordinates
I first found out that the Universal Transverse Mercator (UTM) coordinate system was invented to simplify this very problem. Instead of resorting to extremely skinny triangles based at the center of the earth it uses measurements in meters from standardized reference points. It is much more difficult to describe than Good Ol’ latitude and longitude. It turns out that BaseCamp is capable of displaying UTM, shown in the detail on the left, but it only exports the old style coordinates. I have a picture of that, too.

Track details as exported
But a search on DuckDuckGo (like Google but without the spying and tracking) coughed up a detailed dissertation on the use of the Spherical Law of Cosines for just this purpose. So it was time to build a spreadsheet!
After importing all these points into Apple’s Numbers application and struggling with a bunch of sines and cosines and deltas and phis and lambdas and meters and feet and miles, I had a working spreadsheet that looked almost exactly like the first BaseCamp display above, with the “legs” of the track in feet. I didn’t check all 560ish points, but every one I did check was true to the nearest foot.
And the grand total of all those legs? I have picture of that, too:

Spreadsheet Results
5720 meters or 3.554 miles. So this is consistent with the upward half of the split track, even though the data is from the saved 4.2 mile upward track. Where did that 4.2 come from? I have no mathematical answer for that. The best I can come up with would be an unlikely and deeply conspiratorial attempt to rig the results to agree with the odometer. But they probably wouldn’t do that.

Closeup of the Bulge at the Flume
Had enough yet?
Now 560 points is more than one needs to draw a pretty good picture of a 3 mile trail. Given that all the GPS coordinates have some error (or jitter) in them, having more data might give worse results. So I modified the spreadsheet to skip every other point and this dropped the track to 3.28 miles. Stripping it down to every third point brings it down to 3.00, and every fourth point gives 2.92. At some point just throwing data away willy-nilly like this is going to chuck out some good stuff (for example, it could seriously round off the switchbacks). To do this well one would have to detect places where the track has a serious change of direction and make sure those points are kept, while tossing out points when you are loping along a straightaway.
Another way that those inherent errors can exaggerate the track length is that the device doesn’t do a very good job of handling times when you are stopped. (To be fair, this is a difficult problem for a mere machine: How can you tell if you are moving or not when all you know is your position, and that is almost certainly in error?) What happens when you stop is that the GPS sees these inherent errors as legitimate movements (We’re here. No, now we’re over here! No! Over here!…). Going back to that white arrow on the first map, above, you can see a little bulge in the track at that right turn by the Flume, where we paused for 5 or 10 minutes. (Sometimes I remember to manually turn off the track logging when stopped, but not this time.) The map on the left is a closeup of that spot – there are actually 25 spurious points in that little bulge! In this case I culled almost a mile out of the 4.2 mile track just by deleting obviously extraneous points like these.
There are some settings in the GPS device that might serve to control the numbers of excess and spurious points without losing too much detail, and I will experiment with that. But consider that this is a $500 device which seems to be generally regarded as the best consumer-grade GPS available for hikers, that I was using the default settings and that 99 and 44/100 percent of users are using those defaults.
So the next time someone authoritatively announces what the cheap little GPS in their phone says, I hope you take it with enough grains of salt to gag a buffalo.
Appendix – Later that night…
Just a quick note – it occurred to me that the one difference between the 4.2 mile up-track and the 3.6 mile half-track: the former had been uploaded directly from the device and the latter had been created on the computer. I went back and made a duplicate of the original track; it still showed the 4.2 mile length. But when I deleted the last point, which should have changed the length by 18 feet, that length instead changed instantly to 3.6 miles. As soon as I forced the computer to recalculate the length it got the “correct” length, that is, the length based on the actual point data. So I conclude that the 4.2 number really had nothing to do with the actual track points but had somehow been attached to the track while it was in the GPS device. The conspiracy theory just got a bit more plausible – somehow the track length has been fudged, perhaps to make it agree with the odometer.
I can’t wait to hear Garmin’s explanation…stay tuned.