Why GPS fails for Hikers

Now that everyone and her Aunt Mildred carry a GPS device everywhere they go, the scene at the end of our (temporarily suspended) group hikes sounds a bit like this:

• “I got 8.3 miles. What did you get?”
• “I got 8.7 miles. And you?”
• “7.9”
• “OK, let’s round off to 9.”

Why are these sophisticated devices returning such disparate results? (I take a lot of flak because I’m always, I mean ALWAYS, the party pooper with the “7.9”.)

I think I can explain in this posting (which is long but has lots of pictures and very little Math) a lot of what is going on with some tracks that I collected on a short, steep hike last Thursday with two other senior hikers. We hiked slowly (because I am extremely old); because of the Coronavirus emergency we were careful to maintain a good bit of separation and we stopped several times at wide spots in the trail to chat because it was hard to converse when one of my companions was about 15 feet behind me! (You might be able to guess what we talked about 🙂 )

My usual electronic companion, a handheld Garmin GPS, had been forgotten and left at home so I started up the Polar Flow app on my new iPhone. It reads my heart rate from a photoelectric sensor on my arm and takes position data from the phone’s GPS to construct a detailed picture of my hike – it hasn’t impressed me as very accurate but I do love Data and it would have to do.

The first time we paused to solve all the world’s problems I had the bright of idea of also starting up the GaisGPS app. It would be interrogating the same iPhone GPS data as the Polar Flow so it might be interesting to compare them.

I ended up with a bunch of tracks. When I got home I exported them as GPX files and uploaded them all to Garmin’s BaseCamp software, where I could plot them all on the same map and select portions of interest – I selected out just the portion from the place where I started Gaia to the top of the trail. And I dug out an old Garmin track of the same trail.

Pine & Cedar Lakes Trail – uphill portion

This first map shows the entire hike. All three tracks are present but only my old Garmin track is highlighted (in green); the iPhone tracks peek out (in purple) here and there. The place where I started Gaia shows as a little purple blob at the 800′ contour line, and the rest of the pictures will cover from that point to the south end (at the left).

All tracks

This map has all three tracks highlighted but we can only see two because the iPhone tracks are right on top of each other. The tracks look quite different but please notice that they have the same overall shape. The phone tracks are a lot kinkier – I think the green track looks most like the trail as I remember it. Some numbers that are pretty interesting:

• Polar: 2.2 miles – 4,264 readings
• Gaia: 1.5 miles – 481 readings
• Garmin: 1.2 miles – 211 readings

Now I’ll focus on the Polar Flow track, which is in magenta

Polar Flow track

Notice that the magenta track has several blobs or fat spots, which happen to lie near the 800, 1200 and 1600 foot contours. These are the major places where we stopped and had a chat. I’ll zoom in on the one at the top of the trail, which is the biggest:

20 minute chat at the top of the trail

What happens is that the Polar app cannot tell that we are stopped because the phone’s GPS keeps sending it a location every second and each of those locations is slightly different from the last, because of the inherent and unavoidable errors in the very complex and sophisticated process of divining our position from timing radio transmissions from a bunch of satellites hundreds of miles away. The GPS cannot tell directly if we are moving – it only has an estimate of our position at each point in time.

In fact, the app has recorded about 230 readings during the roughly 240 seconds that we were standing and talking. These readings are all pretty close together, thanks to the pretty good accuracy of the phone’s GPS, but the Polar app does not see anything suspicious about hundreds of readings within a few feet of each other and no sense of progress. All of these spurious little distances add up to roughly a half a mile! And after deleting this blob and the other two, the track loses almost three-quarters of a mile,. So the original track length was high by 45% – and that’s just the worst stuff.

Now the difference this and the Gaia track is that the Gaia app doesn’t accept blindly all the data proffered but the GPS, but applies its own algorithm in an attempt to filter out some of this noise. And it does a pretty good job but it still shows blobs of readings at those same three places – removing them brings the numbers to:

• Polar: 1.5 miles – 2362 readings
• Gaia: 1.3 miles – 327 readings
• Garmin: 1.2 miles – 211 readings

Central portion of hike

Looking at this enlargement of the central portion of the hike, one feature is really striking:

The (faint green) Garmin track is smooth-looking and free of those blobs. The phone tracks have all sorts of wiggles and jukes that just ain’t there in real life, including an actual loop where the trail has just a tight pair of switchbacks. (Very few trails have loops.)

I think it is pretty clear that all those extra points (the ads will call it “greater precision”) in the phone tracks do not simply fail to improve the track but actually make it much less accurate – the Garmin track is vastly superior to the others.

Conclusions

• Most phone based GPS programs are junk for serious hiking – they don’t even produce very good results when walking in town. (The Polar company makes heart rate monitors and is focussed on calorie consumption and doesn’t pretend to be an orienteering program.) You’d be better off with a well-calibrated pedometer.
• The GaiaGPS app is much superior. It’s tracks are still jagged and strange looking but the overall distance measure is only a little bit high. But this is true IF AND ONLY IF you remember to pause the tracking manually whenever you stop for even a couple of minutes so the blobs won’t have a chance to form. This is a deal-breaker for me personally because I’m just too forgetful.
• The Garmin GPS units (and probably other brands) can give excellent tracks and distances but NOT if you use them as they come from the factory. They come set up for use in vehicles but you can probably rejigger the settings to get good results when hiking.

This state of affairs is quite unfortunate and unnecessary. Modern phones have enormous processing power, far more than my 5-year-old GPS handheld, and could certainly be programmed to filter out most of the garbage. Gaia has made an excellent start in this direction and I plan to try to get their attention and see if they can do even better. (Several years ago, Garmin gave me the runaround for 6 months and ultimately did nothing. I doubt if Polar would even care.)

I’d like to give some more tips on how to get better GPS results but this post has already gotten way too long. Stay safe and hike responsibly.

Ogallala? Oh, Golly!

On the way to the “Ogallala” trail

Eight hikers, including Carols’ daughter, Renae, showed up on a cool, misty morning in Bellingham for a hike on Stewart Mountain, just east of town. We named it the “Ogallala Loop” because someone, probably a transplant from Nebraska, once carved a wooden sign saying “Ogallala – 1400 miles” and nailed it to a tree near where the trail takes off from the logging road. In the above picture we are approaching the sign location, but when we got to the point I had saved on my GPS there was a small trail heading into the woods, but no sign. A couple of hikers went on down the road for a bit but soon gave up and returned and we prepared to head into the woods.

While we were waiting, the mist turned into a very light rain and we put on our pack covers and other rain gear. I did so mainly to ward off the weather gods, since the forecast called for a cloudy day but very little rain.

Which was completely wrong; it proceeded to rain continuously but lightly for the whole day. This poor, soggy little trillium was emblematic of the day:

The trail has always been on the muddy side and poorly maintained but it has gone completely to seed now. We were lucky that we’ve had a week with almost no rain, for we still had lots of encounters with slippery, shoe-sucking mud. We were clambering over fallen limbs and trees all day, too.

We grabbed a quick lunch up on top of the mountain but we couldn’t see any of the fine views, as we were enveloped by the clouds. The return side of the loop was, if anything, even worse than the ascent, with more mud, seriously steep patches and overgrown undergrowth that made us too dependent on the occasional pink blazes along the trail.

I am just about ready to declare this as an ex-trail – a trail that we used to hike, but now have better sense.

We did a nice round 10.0 miles with 2700 feet of elevation gain. This was only my second hike after missing about a month and I am feeling it all over. But at least we didn’t get lost, no one damaged any important body parts and we returned with the same number of hikers we started with.

Through the Woods

This morning I set out to see if the hike I scheduled for Thursday would be worth doing. The last time we tried this hike we ran into a real mess near a new clearcut – many, many small to medium trees that had fallen across the trail (which at that point was actually an old abandoned road). We struggled through it for awhile but ultimately gave up, not knowing if we were going to be able to get to a better situation. My plan for today was to make a quick hike up to that area and see if there had been any cleanup, now that the logging operation was complete, that would allow us to complete the hike to the top of Stewart Mountain.

The trail was wet from our recent rains but not terribly muddy. I took a picture of a leaf in the trail from a Big Leaf Maple – can’t imagine how they came up with that name!

Big Leaf Maple – the toe of my boot gives scale

As I approached the area of the clearcut the trail disappeared under a bevy of small fallen trees. Not only did they block the trail themselves but they had also bent other vegetation across the trail. I thought it odd that so many trees had fallen, and all in roughly the same direction, but when I tossed one off the trail I noticed that it ended in a clean saw cut. Why had someone cut down all these tress?

The “Trail” is just to the right of center.

My plan for a quick hike to the old road by the clearcut was not working out. But I had brought a pruning shears and a small saw, so I decided to spend a little time cutting my way through – maybe the blockage was only a few yards deep.

It wasn’t. An hour and a half later, after giving up and starting back down and changing my mind a couple of times, I finally made it to the road I was aiming for, having traveled a distance of about 100 yards!

That road still has a lot of downed trees but it didn’t seem as bad as I remembered. It looked like some hikers or hunters has started stomping out a new way around and through the mess. It was mostly a matter of stepping over trunks lying on the ground, with a few more annoying ones to clamber over or scoot under, but nothing that was difficult or dangerous. In the end, the bad part was less than a quarter of a mile (I measured carefully) and only took me about 10 minutes.

A big portion of the trail that we had used in recent years was completely obliterated by the logging operation, but there is another old road that leads away from the clearcut and accesses an older trail (in who-knows-what sort of condition) that links up with the trail to the top of the mountain. So I pressed on another quarter mile or so to check the out and, with a bit of difficulty, found the old trail and followed it a short distance, just enough to be reasonably sure that it was the correct trail.

Old Trail #6, covered with leaves

The trail seemed to be in pretty good shape but I was still several hundred feet below the top of the trail and kind of pooped, so I headed back to town. On the way down it took me about 6 minutes to pass through the section that had taken me an hour and a half to clear. The whole trip back to the trailhead took less than two hours.

So all in all I think this hike is actually doable. The weather for Thursday looks pretty good.

Fungus Amongus

A Charmed Hike

We thought we’d gotten a bum deal when we went hiking on the Heliotrope Ridge Trail last Thursday. The end of October is generally not a good time to go hiking in the North Cascades but it looked like El Niño was on our side, providing fairly warm enough temperatures to keep the snow away. And the National Weather Service forecast called for a lull in the rain, although it did say that rain was more likely in the mountains than in the lowlands.

You can read all about the hike on D-Jan-ity but, to make a long story short, it was raining very lightly when we started and it stopped entirely after about a half an hour. There were even patches of blue sky urging us onward, but we were flummoxed when we got to the first of three creeks and couldn’t find a safe place to cross. It is pretty commonplace to turn back at the third one but this is the first time that we couldn’t even pass the first one. So we had to settle for a 3 mile hike, getting back to the cars at about noon.

It seems that I was too focused on snow and falling rain to take into account the rain that had already fallen and made its way into the creeks. In fact we are under the influence of something called an “atmospheric river” or “Pineapple Express”, wherein a plume a moist Pacific air from the tropics set its sights on the State of Washington and brings huge amounts (for us) of rain. You can read more about this on Cliff Mass’ Weather Blog.

Last evening my curiosity drove me to look at the data from a SNOTEL (a remote automated weather station) that is located across the road, a few miles from where we were hiking and at about the same elevation. It records the snow depth, temperature and accumulated rainfall at one hour intervals to the nearest one-tenth of an inch – that is pretty coarse, since 1/10 of an inch in an hour is pretty heavy rainfall. The sort of drizzle that fell on us early in the hike  wouldn’t even register on that scale. Anyways, here is a graph of the hourly rain accumulation for Thursday:

 

Notice that, except for the wee hours and the late evening, the only time when that graph isn’t streaking upward is the three hours that we were hiking. And look at the time just before 9AM – over an inch in about 5 hours! So no surprise that Kulshan Creek was raging and we were actually pretty lucky.

Last night in the wee hours we got almost an inch of rain here in town, so I went back to the SNOTEL and downloaded the hourly data from Thursday through 11AM today (Saturday). The arrow points at our hiking time.

That’s some serious rain!

By the way, that accumulation is from October 1, the start of what the weather folks call a “water year”. So the mountains have had considerably more rain in the last 2½ days than in the rest of October.

Local Color

On Thursday, October 1, 2015 eleven Senior Trailblazers struggled up the long, bumpy drive on Canyon Creek Road to the Damfino Lakes Trailhead on a beautiful sunny day. The hike was chosen mainly in the hope of catching some fall color in the North Cascades and it did not disappoint.

Eleven happy hikers in the meadow below Excelsior Pass

Most of  my photos in those meadows were ruined by solar flares, due to shooting to close to the sun. (Sometimes one can get lovely effects from those flares, but not today.) When we reached Excelsior Pass it was getting close to noon, but I managed to dragoon the group into heading a couple of miles east along High Divide in hopes of reaching a favorite place of mine with views into the mountain wilderness of North Cascades National Park. It, too, did not disappoint.

Looking East from High Divide

The view to the south was dominated by Mount Shuksan. The air was a bit hazy but that can enhance the sense of the depth, as the mountains fade into the distance. It doesn’t show in this picture but if you stared intently enough and really believed (heel clicks optional), you could even make out a silhouette of Glacier Peak (65 miles away) peaking through one of the those dips in the skyline just to the right of Shuksan.

Shuksan, et al., from High Divide

We paused on the way back to soak up some more color along High Divide and at Damfino Lakes. All along High Divide we enjoyed a hazy but excellent view of massive Mount Baker – I only just now realized that I failed to take a picture of it.

Color on High Divide

 

Damfino Reflection

We gained a total of about 2200 feet of elevation in the course of this 9 mile hike.

GPS – Less is better

In my previous posting on the issue of GPS track log accuracy, I made a case that the 500-600 points produced by recording every 6 meters (20 feet) or so should be plenty to give an accurate picture of the average 4 mile hike and that the additional 9000 or so points proffered by Garmin’s preferred (to put it mildly!) “1-second distance accumulation” method should not, assuming that the points are accurate, change the track length by any significant amount.

But we have the simple fact that my friends and I have gotten a substantial discrepancy on every single mountain hike we’ve taken with my new Garmin 62stc device, errors ranging from 10-40% – which I would call significant! So which one is right? Or, I should say, which is more accurate? Because nothing is perfect, after all. This is all about the accuracy.

Accuracy

I want to make it clear that I am not meaning to “dis” the accuracy of the GPS unit itself. The reason I didn’t take the thing back to REI after its first hike was that I could tell that it was handling the challenging conditions of hiking in the North Cascades quite well. It acquires a signal very quickly and holds it even under deep forest cover. It does a good job of tracking the switchbacks, reacting to a sudden direction change much faster than my other models. Each individual reading from the device is quite good, given the conditions.

But there will always be errors. Garmin only claims accuracy down to 2-3 meters (7-10 feet) in the very best conditions. If you are a few feet away from where you thought you were it is no big deal. The problems arise when you combine a whole bunch of slightly inaccurate readings:

• Just how big are these errors?
• Will they tend to cancel out?
• Or will they tend to accumulate?

Looking at the last point first: if the errors were even as small as 3-4 inches, 9000 of them would accumulate to about a half mile! So this is not a trivial question.

Error analysis is difficult, by its very nature, especially when you have no independent means of verification. Nice straight lines just don’t exist in the forests on the sides of mountains. The trails tend to be hidden under the trees and thus not visible on aerial or satellite photos, and I don’t have a ball of twine long enough to stretch along the trail. So there will have to be a lot of guesswork and some hand-waving, but I will try to make the estimates very conservative and give the benefit of every doubt.

Assumptions

• It is very, very conservative to say that you might expect any recorded point along the track to be off by a foot or so from the true path.
• Because of the steepness and roughness of the trails, we are often traveling at only 1 or 2 feet per second; we hardly ever average better than 3 fps (2 mph).

So the  “1-second distance accumulation” method will be recording points only a couple of feet apart, about one for each step we take. (I ask you to meditate for a moment on the wisdom of recording points a foot apart when we only know the position of each point to within ten feet… Now back to the conservative assumptions.)

• So it safe to assume that the errors in these points could easily be on the same order of magnitude as the distances being measured

Here come the numbers

Let me compare this to the situation you have when riding in a vehicle at, say, 20 mph (or 30 fps). In one second you travel about 30 feet and record a point that is off by, say 1 foot.

Sometimes the error in that point may be in the direction of travel, so the estimated distance might be as little as 29 feet or as much as 31 feet; but that sort of error will tend to cancel itself out – if this reading is a foot short, the next will likely be a foot long. This is not a problem since we are just interested in the total.

The sort of error that will NOT cancel is when the estimated point is off the true path to one side or the other. If this point is a foot off to the left, then the next might be off to the right, compounding the error rather than canceling. If the next point is off to the left also, then it might not add to the error, but there is no reason to expect that it would cancel it out. And when you go off the track you don’t have to go off to the other side on the next reading, but you do have to get back to the true path eventually if the track is to be worth anything.

What sort of error are we talking about here? The worst case would be where the estimated point is a foot to one side of the true path – I’m picturing a a right triangle with a 30 foot leg (the true distance) and a 1 foot leg (the error). The GPS will be measuring the straight line distance from the starting point to the estimated point, i.e., the hypotenuse of that triangle. Mr. Euclid assures us that the length of that hypotenuse is the square root of the sum of the squares of 30 and 1, that is, the square root of 901 or 30.0166. So the error is that 0.0166 foot or about 0.2 inch.

Which ain’t much. In terms of percentages an error of 0.2 inch in a measurement of 30 feet works out to about 0.057%. This is a very tiny error that explains why Garmin’s strategy works quite well when you use the device in a car, or even a bike.

But this all depends strongly on the fact that the thing being measured is thirty times larger than the error, more than an order of magnitude. If that ratio came down to 10 (one order of magnitude) the percentage error would still be small – about 0.5% – not enough to bother with.

Things go nuts, though, when the error is on the same order as the thing being measured. If the ratio comes down to 2, we get

And it gets quite silly when the ratio is 1:

This is enough to bother a hiker – if you were training for a trip down into the Grand Canyon by making “10 mile” hikes that were in fact only 6 miles long, you could get a nasty surprise when you get to Arizona!

Now I’m not saying that you will always get 40% error on a real life hike. There are lots of reasons why you might do better than this. But back when I was using the default settings on the Garmin I did in fact record some errors of that size. And while the errors are not always that large, they are ALWAYS ON THE HIGH SIDE, just as this analysis would predict. (Again, if an error takes you off the track, you have to make another error to get back on it.)

(By the way, the same discussion applies to the odometer. Assuming that they are using the same method to stoke the odometer, it would explain why I long ago gave up on its consistently, and often laughably, high readings. On one hike the odometer gained a quarter mile while we were sitting down having lunch.)

Conclusion

I know that this does not prove anything. The thing I hope you take away is this: the small errors that are unavoidable in each point of a track will tend to accumulate, which means that sometimes less is better. And given our slow rate of travel and difficult sky conditions, it would be very reasonable to expect the “1-second distance accumulation” method to generate errors on the scale that I’ve observed on the trail.

Ironic Epilogue

The cruel irony is that Garmin’s decision to paste the one-per-second track length into the track log makes almost no difference in most situations, such as in a vehicle. Or when one is power-walking along an urban trail with a clear view of the sky in all directions. So it may not do harm in those situations, it never does any good! This is the easiest kind of cost-benefit analysis:

• Substantial Cost.
• No Benefit. Ever.

In my last note to Garmin, I also made an appeal to their sense of fairness:

If a user believes that the “1 second distance accumulation” is a good idea and gives her good results, then she can choose that option in the track log setup. But if she has a valid reason NOT to sample that many points and wants to make a track with the points spaced further out FOR WHATEVER REASON (but her reason, not yours), then there is currently no way for her to measure the length of that track in the field. You may not like her reason, you may snicker behind your hand that she would want to do something you think is foolish, but it is (pardon the expression) none of your freakin’ business!

 

GPS – Just because you can doesn’t mean you should

After going back and forth since last June with the email support staff at Garmin Ltd I finally received a reply with some substance:

When the user uses anything but the one second track interval the track log is “missing” data.  We are putting a value for total distance in the GPX file in the track stats tag that gives BaseCamp the 1 second distance accumulation ( even if they are not setup for 1 second distance accumulation ).  So when the user removes the first point BaseCamp can no longer use our 1 second distance accumulation value and has to fall back on the old method of summing the delta between all of the points.  The problem is that all of the points are not there, because they are setup to record at a less than 1 second interval.  So when this happens they think they are just removing 1 point, while in reality they are removing possibly thousands of points along the entire track which is why the distance changes.

The substance is that they have finally acknowledged what I have been saying for the last six months and what I suggested in the last paragraph of my first posting on this issue back on June 10, 2014. That’s the good news; the bad news is that they clearly seem to think that substituting in  the “1 second distance accumulation” is a good idea! If it took six months to get them to even admit what they are doing, how long will it take to make them see that what they are doing is just plain wrong?

The Lily and Lizard Lake Trail, Skagit County, WA – 687 points provide a lot of detail.

A Quick Review

After a lot of experimentation, I have my Garmin GPSmap 62stc set up to record a track log point roughly every 20 feet (6 meters). Since we usually average only one or two feet per second when hiking uphill, Garmin’s “1 second distance accumulation” would mean recording a point every foot or so – ten or twenty times as much data. For example, on the first half of last Thursday’s hike I recorded 687 points in roughly 4 miles, at an average distance of about 30 feet, as shown in the picture; the elapsed time was about 2:37 so the 1 second method would have totaled up around 9,400 intervals of about 2 feet each. The total track length (by the 1 second method) was listed as 4.7 miles. When I deleted a single point and forced a recalculation (“losing” almost 9000 points) the length changed to 4.2 miles.

Why my points were 30 feet apart rather than the 20 I asked for is something only Garmin could answer, but it is not a big deal: 687 points is more than enough to make a very good picture of the trail we were on. The track agrees very closely both with my previous tracks (made with different Garmin devices) and with published information and maps of this very popular local trail. We had good weather, we were moving at a good, steady rate with few stops and the device showed an accuracy between 10 and 20 feet (about as good as it gets) every time I checked (which was often).

The Big Question

Pay attention here, as I am pretty sure this is the point where Garmin is going to counterattack (assuming I can get them to respond before I die.)

Even on these winding mountain trails it’s not like we are juking rapidly from side to side as we go along – with the exception of the occasional 179° switchback, you are usually traveling more or less in a straight line. I’ve been paying attention to that this summer – most of the time you can see straight ahead along the trail for 20 or 50 or even 100 feet, then there is a subtle change of direction and you go straight for another stretch. A lot of the trails, including large parts of this one, follow old logging roads and railroads (which are not prone to rapid direction changes) and have only a handful of sharp turns. I think if you joined us on a hike you would agree that if you could accurately record a point every 20 or 30 feet or so you would get a pretty darn good track, and it should contribute almost nothing (except for a whole lot of extra data) to the measured length of the trail to accurately record a few thousand intermediate points along the way.

So this is the first core of the issue – it is all about accuracy. How do we explain that half-mile discrepancy between the “1 second” method and the “20 feet” method? When I have done similar comparisons in town on a nice straight city street with a full, clear view of the sky (and where you can get a good independent verification of the distance) there was no such difference. Garmin is on record with its explanation: when I edit the track I am “removing possibly thousands of points along the entire track which is why the distance changes.”

And I agree completely! Where we differ is that Garmin seems to think that more is necessarily better, that those thousands of additional points must be an improvement. That is a common fallacy – more chocolate is better; more habanero pepper maybe not so much.

I think I made a pretty good argument that those thousands of extra points cannot increase the accuracy by more than few feet in a mere handful of sharp turns, nothing like a half a mile. My argument is that the 1 second method was adding in an additional 9000 tiny errors – that would be a positional error averaging only 3.5 inches per reading, and that on a device that is only claiming accuracy of 10-20 feet.

My Assignment

So my assignment (which I very much do choose to accept!) is to try convince a bunch of engineers who work and probably live in a place with very few hills, very few clouds and very few trees that there are situations where a lot of their precious data is more like pepper than chocolate and is ruining the result rather than flavoring it.

And more poignantly, that this particular kind of pepper never improves the dish – most of the time is does no harm but it can never help.

I intended to dig into the gritty geometric and arithmetic details that support this argument but this is more than enough for one day.

GPS – the adventure continues

Since my last post I have been locked in a death grip with Garmin’s “Help” desk about my new GPSmap 62stc handheld GPS unit. I write in, they respond with a condescending, patronizing reply that picks out one phrase to criticize and ignores the general thrust of my message. I then reply in detail (as I am sure you can believe) and it is picked up by a different “helper” who chooses a different irrelevancy to pick on, and offers a completely different “explanation” or “solution”.

This process started on June 16 and has gone through six or eight iterations. I was going to wait for a some sort of resolution before reporting back to this blog but it is becoming clear that they are so adept at ducking this issue that resolution is very unlikely. But in the meantime, I have accumulated enough evidence to be quite confident that I understand what is going on.

Are you ready?

I my previous post I included this sentence:

 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.

Since that “4.2 mile” hike toward Excelsior Pass on June 5, we have gone to the Church Mountain Meadows on 6/12, the Goat Mountain Overlook on 6/19, a Middle Fork hike on 6/26 and back to Church Mountain yesterday, July 3. I have tried out all of the suggested settings proffered by Garmin and several of my own and gotten the same sort of results as the Excelsior hike every time. And at least twice, we have been joined by Carl sporting his Garmin 62st device, which seems to differ from mine only in that mine has a camera. He has gotten very similar results and has made a major contribution to my sanity (or what remains of it.)

The responses from Garmin have ranged from the merely patronizing to the positively ridiculous. In response to the fact that the device was generating spurious points when we stopped along the trail one respondent made this suggestion:

… try to stop as little as possible.

Another was quite insistent that accuracy could only be achieved by setting the device to record a track point every second – 3600 points every hour. Never mind that a track can only hold 10,000 points, limiting the device to a trip of about 2 hours and 45 minutes. Never mind that a track of that length causes their own BaseCamp software to bog down to the point of being unusable. And never mind that the “every second” track I made coming down on Goat Mountain is every bit as inaccurate as the one I made going up.

Most of my time with them has been spent dithering over these inaccuracies, where there is no outside authority to settle any dispute. There are hiking maps and websites, which are notorious for their casual inaccuracies –  it was my word against theirs. So I attempted to focus all the attention onto one verifiable, repeatable, incontrovertible inconsistency:

Why does their own device and their own computer software report different lengths for the same track under different circumstances?

It took a couple of exchanges to wrench their attention away from the accuracy question but last week I finally got someone to admit that there was something questionable going on when the removal of one redundant point from a log of over 500 points caused its length to changed from 4.2 miles to 3.6 miles and that he would have to look into it.

Then … silence.

The intervals between responses had been one or two days, mostly, but a full week elapsed before I saw a new email at about midnight before Thursday’s hike. I chose not to look at it before the hike since most of their responses had been simultaneously irrelevant and infuriating (or, in homage to Stephen Colbert, infurelevant) and I didn’t want to be in a bad mood in the morning.

On the hike to Church Mountain Meadows there were even more interesting results than before. I set the device to record a reasonable numbers of “bread crumb” points and kept a frequent watch on it along the way. I could see that it was doing a good job of following the shape of trail, catching even minor changes of direction and only rounding the switchbacks a tiny bit; I was confident that I had a very good track. I also was carrying my old Garmin 60CSx.

We stopped for lunch at a spot where all my previous experiences on Church told me the distance should be about 3 miles. I took the following readings from the devices:

• 62stc Odometer: 3.55 mi
• 62stc track: 3.4 mi
• 60CSx Odometer: 2.9 mi
• 60CSx track: 3.05 mi

I turned off the track logging on the new 62stc at this point, but didn’t save the track, yet. While I was sitting in the snow for the next half hour or so, I checked the 60stc now and then, watching the odometer go from 3.55 to 3.64 to 3.74 and by the time we got up to start hiking back, to 3.82. (That’s why I had turned the track logging off – so all that spurious junk wouldn’t be added to the track log.) All this time the device was sitting stock still on the top of my pack at 4950′ in an open meadow, showing excellent accuracy of about 2 meters (7 feet). Gaining an imaginary quarter mile in half an hour seems like pretty bad behavior, but long experience has driven my expectations for GPS odometers to be very, very low. But that’s another story.

As we prepared to start down the trail, I turned the tracking back on, saved the track (which still showed the 3.4 miles) and a minute later decided to use the “tracback” feature to show the distance back to the trailhead along that new track. Understand that I still thought it was an accurate track, just that its reported length was off  by almost half a mile.

And Lo! and Behold! The device now showed the distance to the trailhead as 3.0 miles!

When I got home and uploaded the stuff to BaseCamp, I got the usual nonsense: the track length showed as 3.4 miles until I deleted one point, whereupon it also changed to 3.1 miles. I ran the track through my spreadsheet and it gave 3.06.

The Bottom Line

So the old 60CSx track was right on the money at 3.05, and the 3.0 on the “tracback” and the 3.1 in BaseCamp can be chalked up to roundoff error.

All the other numbers reported by the 60stc are sheer bullfeathers.

Back to the Garmin “Help” Desk

So then I was ready to read the response from Garmin that I had avoided. There was some more patronizing stuff, but the gist was contained in this paragraph:

I hope this helps to explain this isolated incident that you were experiencing. This is an extremely rare problem. Unfortunately, the only way to really explain this error is to contribute it to corrupt GPX data on your device.

So, ignoring the fact that this was a brand new device when this stuff started happening and that another person’s device was getting the same results, Kris had come up with an “reason” that conveniently would invalidate all the previous data that Carl and I had accumulated, and attribute it to my not knowing how to disconnect the device from my computer!

[ short pause while the lingering rage gradually subsides…]

At the risk of my declining sanity…

Kris had given instructions on how to purge the dread corruption from the device, but since it works quite well around town, I would have to wait to test the inanity of his/her directions. But I couldn’t wait so on Sunday morning I performed the purge and headed over to Stewart Mountain (a big foothill, actually) to check on the progress of the logging operation that is likely to obliterate some of the trails over there. The conditions there are not nearly so challenging for the GPS as our real mountain hikes, but it might be enough to generate some good (i.e., bad) data.

I stopped at a little knoll in an old clearcut when the new device’s odometer just happened to read exactly 2.00 miles; the track log said 2.0; the old GPS’s track was 1.9. I was expecting the “tracback” function to shave a little off that 2.0 mile track length and was disappointed when it didn’t. I headed home.

Back at the computer, however, the old bug reappeared: deleting one redundant point changed the length to 1.9 miles and my spreadsheet came up with 1.895.

I sent this information off to Garmin and finally got the first response that was neither patronizing nor inane:

This problem has been reported. We are still researching this to find out what is causing this and how to correct this. I have added your information/file to the case. We will contact you when we have more information.

Hmm. We shall see.

GPS – a cautionary tale

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.

Some weather tidbits

I had to scrape the rust off this blog this morning – has it really been more than six months? Anyways, here is an olio of weather-related things that popped up this morning.

Mount Rainier in the snow

Today Cliff Mass of the University of Washington wrote on his meteorology blog about the big snows that are hitting the Cascades this week and included this picture of the Jackson Visitor Center at  Mount Rainier National Park:

Jackson Visitor Center yesterday (2/17/2014)

For those of you who have not seen this splendid new building and might be deceived by the scale of the photo into thinking you are looking at something the size of an outhouse, here is a shot I took on our visit last July. It’s a big building!

Jackson Visitor Center, July 2013

Cascades Snowpack

Up here in the North Cascades the mountain snowfall has been below average so far this winter, but not nearly the sort of drought you’ve been reading about down in California, Oregon and even southern Washington. (Down here in the NW lowlands we’ve had modest rainfall and snow has been nearly absent.)

Dangnabbit!! I just lost half of this post! I made an accidental click on a bookmark and the browser left the page without warning. I thought WordPress did some auto-saving but I guess not. Here we go again…

To document the situation, here is a graph that I’ve concocted out of data from a remote monitoring station belonging to the Soil Conservation Service and located at about 5000′ elevation on Lookout Mountain. (No, not that Lookout Mountain! And not that one either! It seems there are as many Lookout Mountains and there are Mud Lakes and Boulder Creeks.) This one is a few miles WNW of Mount Baker near the Heliotrope Ridge trailhead. The graph shows the water equivalent of the snow on the ground – essentially a measure of the weight or mass of the snow. This gives the best estimate of the meltwater that is going to be available to water crops the following summer, which is what the SCS is interested in.

The squiggly red, orange and green curves are for 2011, 2012 and 2013, respectively; the smoother purple line is an average for most of the 15 years or so that the station has existed.

For us hikers, the most pertinent thing is the point where the curve drops back to the axis, indicating that most of the high country hiking trails will be snow-free. Recall that 2011 (red) was the year that the DOT (Department O’Truckin’) could not open the road to Artist Point. And last year (green) there was above average snowfall but it melted so quickly that the hiking trails were available a bit early.

You have to look closely (or expand the picture) to see this year’s dark blue curve – it has been below but very close to the average for the water year so far – you can see a little uptick in response to the recent storms.

The thing that always strikes me first about this graph is the way the curves are clumped pretty close to average until about this time of year. The high snow years didn’t really start moving off average until February or, in the case of 2011, even March or April.

So the upshot is that we are having a fairly average year.  And what does that tell us about next summer hiking?

Nothing. Or maybe less. But talk to me again in April.

WunderMap radar image of NW Washington & SW BC

Rain Shadow

I close with a screenshot from this morning of the weather radar over NW Washington – it gives a vivid picture of the Olympic Rain Shadow. The precipitation pattern looks like a doughnut with a big hole over Whidbey Island and the eastern end of the Strait of Juan de Fuca. The story here is that storms, like this one, tend to come in from the southwest, riding the prevailing winds. The first terrestrial obstruction they encounter is the massif of the Olympic Mountains, which drives the air up and wrings the moisture out if it. Places on the windward flank like Aberdeen and Forks will get massive amounts of rain (100″ per year or more) while spots in the lee, such as Sequim and Port Townsend, receive Arizona-like rainfalls of 10″ or less.

There is another gap in the rainfall pattern directly over the Olympics, but I’m going to put that down to the fact that the radars, being located down near sea level, do not do a good job of seeing rain in high mountains. The main radar station in this area is located on Camano Island and has a clear view out over the water but not up into the Olympics.

BTW this image is from the “WunderMap” produced the weather site called Weather Underground. The name is kind of a snarky reference to the radical 60s group but it’s the best weather site I’ve found. I especially use their link to the Scientific Discussion to get a behind-the-scenes look at the forecast.