Black Coffee (Deprecated)

The Case Against Garmin

Whether good, bad, or indifferent, I'm saddled with a Garmin eTrex Vista GPS. I think Garmin did a lot of things right in the Vista's design. The interface mostly does what I'd expect, and on rare occasion I've even been surprised to find exactly the feature I was looking for in exactly the place I would expect to find it.

That being said, the Vista and MapSource, its ugly cousin, are not without their problems.

The only interface for downloading data is serial.

The use of a serial interface limits the device to quite slow data transfer speeds. Fortunately the interface supports up to 115Kbaud, but that means transfers will never exceed about 11KB/s. To put that in perspective, downloading 24MB of map data will take at least 30 minutes. That's a long time to wait.

The obvious solution is to provide a USB interface. The only downside to this approach is that Garmin may feel compelled to also provide a serial interface so that the GPS can interoperate with other NMEA compliant equipment. I think a good compromise would be to either provide both interfaces, or provide only the USB interface and offer a USB to serial dongle as an accessory.

They do provide a "turn GPS off after transfer" option, so that you can initiate a transfer and then walk away from the system without worrying about the GPS sitting their gobbling batteries long after the transfer is complete. This at least makes the best of a bad situation.

The protocol spoken over the serial interface is ridiculously slow.

When I recently downloaded 24MB of map data to my Vista it took 55 minutes, almost two times longer than should have been required for the 115Kb connection. I suspect that the protocol being used is woefully ineffecient -- perhaps each byte is sent in duplicate as a sort of retarded checksum.

To force the use of a slow serial interface for downloading data is bad enough, but to then not make every effort to use that interface as efficiently as possible is just insulting.

MapSource won't tell me how much data can be downloaded to the GPS.

MapSource provides a selection tool that allows you to select a subset of the CD map data and download it to a Garmin GPS. As you select the map area MapSource displays a running total of how much total memory will be required in the GPS.

When I recently selected a large number of maps, perhaps totaling 36MB of data, and tried to download it to the GPS I got a popup dialog from MapSource telling me that the selected area would not fit into the GPS, and I should select a smaller area and try again. I was given no information as to how much map data would fit in the GPS, simply that 36MB was definitely too much. What am I supposed to do now? Engage in binary search until I discover how much map data I can download? Consult the manual? Give me a break.

I can imagine that MapSource may say to the GPS "I've got 36MB of data for you" only to have the GPS reply "Up yours, that is too much", in which case MapSource truly can't tell me how much map data would fit. Of course, that only shifts the blame from MapSource to the Vista -- Garmin is on the hook regardless. I think it is much more likely that MapSource knows exactly how much space is available for map data (which may be different from the total memory in the unit) and simply neglected to report it as part of the error message.

Uploading maps starts from a clean slate.

When uploading maps to the GPS from MapSource, the very first action taken is to completely erase the map memory in the GPS. In the not uncommon case where the new map area partially overlaps the map area already in the GPS, no attempt is made to avoid needlessly transmitting the overlap area. The map data itself is broken into variable sized tiles, each of which is contained in its own distinct file on the MapSource CD-ROMs. When map data is selected for upload to the GPS, it is these tiles that are selected. There is almost certainly a filesystem, albeit probably rudimentary, which organizes the GPS memory, so it should be very straightforward to keep those map tiles that overlap, and only download the new tiles.

Downloading track data is inexorably slow.

I recently downloaded the track log from my GPS, a total of 7447 points. It required 6 minutes to move this piddling amount of data, in part because Garmin insists on performing the transfer at 9600 baud. The only possible explanation I can find is that the GPS could not continue to operate as a GPS while transferring the track log if it was going any faster than 9600 baud. I think that's a pretty unlikely explanation however, and a pretty poor design if that's the case.

Saving track data is a destructive operation.

The Vista maintains an active track log, and at any time the track log can be saved (and optionally cleared) to memory. Up to 10 tracks can be saved, in addition to the active track log.

However, saving the track log turns out to be a *destructive* operation. I discovered this when I downloaded my saved tracks and saw that the active log was about 2400 points, while the saved track from the previous day was only 700 points. I knew I had covered about the same distance in about the same time on each day, so something funny was definitely going on. I had previously seen very poor track resolution when displaying tracks in MapSource, and I had a sinking feeling I knew what was going on.

I saved the active log and then cleared the active log and downloaded the saved tracks again. Lo and behold, the previously 2400 point active log had become a scant 700 points upon saving the log. Presumably Garmin deletes intermediate points on straight line paths, etc. But whatever the error metric is for deleting points from the track, on more than one occassion it has turned the log of a hike from a smooth and obvious path into a nearly incoherent scribble that skips over switchbacks and other important features. To add insult to injury, the tracks are mangled without any warning whatsoever. It's incredibly annoying that Garmin should see fit to treat my data with such complete disregard. A dialog announcing "Saved logs are resolution reduced from the active log, and the resulting track may be completely useless. Are you sure you would like to save the active log?" is certainly in order.

The only excuse I can think of for this deplorable behavior is memory pressure -- there simply isn't enough memory to be storing voluminous tracklogs while also providing a large map, etc. Perhaps some analysis will give us some more confidence in this hypothesis.

A point on a track will probably require about 16 bytes of storage, between latitude, longitude, elevation and time. Perhaps Garmin has found even more goodies to store, like compass heading, etc. Of course there is a great deal of coherence in this data (latitude and longitude change very slowly, the time of day changes deterministically, etc.) so it could be wonderfully compressed. But let's not make extra work for Garmin, and we're trying to see how they might have a storage problem, so let's give them the benefit of the doubt and say 24 bytes per track point.

A quick experiment can vet this assumption. Downloading a track log which totaled 7447 points required about 6 minutes at 9600 baud. That's enough time to transfer about 345K, which gives us 46 bytes per trackpoint. Hmmmm. About 2x larger than the largest reasonable point size I can think of, but okay. Garmin isn't a big fan of efficient protocols, so maybe the track points aren't that big. In any case, let's use 46 bytes per trackpoing as a certainly pessimistic working figure.

So a 2400 point active log requires 110KB to store. Obviously 15 such logs would require about 1.5MB to store. In a device with 32MB of memory. And a *great* deal of that memory may be available, depending on how much or how little map data has been downloaded to the device. Of course I think there's good reason to believe that Garmin's memory management isn't that sophisticated -- perhaps with good reason. It would be irritating to try to upload map data to the GPS only to be told that track data will have to be deleted to make space.

Regardless, the track data requires ridiculously little space, and doing a poor filtering of the track to try to save space was a horrible idea. Even worse, this track data could be easily compressed, I would guess by a factor of 5, *without deleting track points* to further reduce any memory pressure.

Transfers can't be resumed.

Data transfers to or from the GPS can't be resumed. Either the transfer is performed in its entirety, or it must be restarted from scratch. This wouldn't be such an issue, except for some transfers require an inordinately long time. If my laptop goes into suspend mode during a long transfer, guess what? I can't resume the transfer, I have to start over from scratch.

MapSource + Laptop = Software Crashes

I did the most obvious thing and loaded MapSource on my laptop, allowing me to take the full MapSource data with me, instead of just the small portion which can be held in the GPS at any one time. My laptop doesn't include a serial port, so I bought a USB to Serial converter to allow MapSource to talk to the Vista and vice versa.

The first time I tried this system out in the field I ran into trouble. I started an upload to the Vista, and then started browsing a paper DeLorme atlas of the area while I waited (and waited). I forgot that my laptop was going to suspend after a few minutes of activity to conserve its battery.

What happened when the laptop suspended? The transfer to the GPS was interrupted and thus spoiled, so it would have to be repeated from scratch. When I unsuspended my laptop MapSource immediately crashed hard. I suspect that the USB to Serial dongle may behave a little strangely when the laptop suspends. For example, after resuming MapSource probably assumed that the serial port was still open, etc. However, the dongle may not have provided that interface. In which case MapSource would have encountered an error the next time it tried to use the serial port.

This isn't to say that MapSource is without blame here -- in fact the dongle may be operating exactly as it should. Regardless of how poorly behaved the dongle may be, MapSource should never crash. It should intelligently report the error it encountered, and in all likelihood it can just reopen the serial device and continue operating.

I think this is one of the few cases where I think Garmin has an at least plausible excuse. It's very likely that they've never tested their MapSource with the USB to Serial dongle I'm using. I'd be interested to know if they've tested the software under power suspend/resume, as obviously they should. Perhaps this is one for tech support.

Can't ask for trackback to a waypoint.

My normal mode of operation is to start the track log running at the start of the day and then save the track at the end of the day. During the course of the day I'll often set waypoints as I go, without starting a new track. For example, I'll set a waypoint at a trail head, but just leave the track log running.

Once I've hiked out the trail a fair piece it can be useful to now how far I've gone, so I'll know how much further I have to go to the end, whether I should turn around, etc. Garmin provides a feature that seems like it would do exactly this: you can "backtrack" along a track. The feature tells you how far from the start of the track you are and provides guidance to keep you on the track. Unfortunately this feature only supports backtracking along an entire track. So in my usual mode of operation I can only backtrack to my starting point for the day. It would be much more useful to be able to backtrack to a particular waypoint. In fact, part of the backtrack interface could present a selection dialog: "These waypoints are within 100 meters of your track. Select waypoint to backtrack, or start of track."

"Find nearest (waypoints)" is too literal.

The "Find nearest waypoints" function does exactly that, where Garmin has set some threshold for when a waypoint will be considered near. If the waypoint is too far away it simply won't be in the returned list, no matter how few waypoints are near the current location. What would be the harm in displaying a complete list of waypoints in order of distance from the current location? Just change the menu item to "Browse by distance" instead of "Find nearest" and it would be perfect.

"Find (waypoint) by name" is too clumsy.

The other option for locating a waypoint is to key in the waypoint name, or a prefix thereof, and select it from the list. The downside to this approach is it requires me to click around the virtual keyboard and hit "OK" before I can browse the list of names. This is a tedious process and is made even more annoying when the desired waypoint is near the top of the waypoint list, as any waypoint which stills bears its default numeric name will be. Why not provide "Browse waypoints by name" option to let me browse the list in alphabetical order?

MapSource draws really ugly maps.

MapSource does a terrible job of rendering maps. I'm sure a Tufte analysis of them could provide myriad reasons why they are a poor representation, but I'll stick with the simplest reason: they are incredibly difficult to read. I can't think of any possible reason why. Garmin is not the first company to draw a map, there are literally millions of examples of well-rendered maps that they could have used for direction.

What is so bad about the maps?

For starters, there is almost no control over the amount of detail that is shown. There is a crude slider under the preferences which lets you vary the detail between "Low" and "High" but it's unclear, at least to me, what effect this as you vary the scale of the map (zoom in and out). With the detail turned all the way up there is a dizzying amount of information on the screen at times. Any detailed options for what to show, what not to show, are completely absent. Don't need to see the several thousands navigational buoys in the San Francisco Bay? Tough, Garmin has decided those are important. Don't want a map choking on topographic contours? Tough, Garmin likes those too. Want to see more street names? Tough, Garmin has thrown almost all of those out in order to force you to buy a different, and presumably equally bad, map product from them.

Next up, they draw detail roads (the vast majority of roads) as narrow lines, regardless of scale. This makes the roads surprising hard to see and follow in a field of much stronger lines. For example, the topographic contours (which seem to *always* be displayed) include some very heavy lines periodically.

What else? The text labels, which are mostly used for point features in the topographic version (can't have you getting the street names for free) include no haloing, so often the text is just a jumble of thin text on top of other thin features.

MapSource draws really slowly.

MapSource draws the map very slowly. I mean agonizingly slowly. So slowly that scrolling is practically impossible to use. I think part of the problem is that MapSource doesn't appear to cache any of the map tiles in memory, so each time it redraws the screen it has to fetch all the tiles again from disk. Even worse, the software only officially supports keeping the map data on CD-ROM, making the pain of constantly reading the tiles from disk that much greater.

MapSource only supported to run off CD-ROM.

It is ridiculous in this day and age to not install all 1.5GB of data on the hard disk and eliminate the need for the CD-ROM. Fortunately you can copy the map data to your hard disk if you're willing to edit some registry keys so Garmin can find it there.

Selected area always highlighted in MapSource.

In order to download data to the GPS a map area must be selected. The selected area is drawn with a purple highlight, always. There is no way to turn off this feature, other than deselecting the area. Why? Who knows.

Uploading data from the GPS always starts a new .mps file.

Uploading data from the GPS (waypoints, tracks, routes, etc.) always starts a new .mps file (Garmin's proprietary save format for MapSource). As far as I can tell there is no way to upload the data into an existing .mps file, although I would argue this is the most obvious thing in the world to do. One reasonable interface would be to ask if the data to be uploaded should be included in the currently MPS file, if there is an MPS file open.

Transfer progress meter is subtly broken.

The progress meter for data transfers to/from the GPS includes an estimated time of completion that is slightly askew. When data is being transferred the estimated time till completion (ETC) will steadily increase until the integer representation of the percent complete changes. Clearly they are taking the elapsed time, dividing by the integer percent complete and extrapolating the time remaining.

While there's a ready hypothesis as to why the observed behavior exists, what astounds me is that the behavior was never corrected! We are several generations past x86 microprocessors which lack floating point support, so there is certainly no obvious reason to avoid the use of floating point. I suspect that the mistake was simply never observed, which seems astounding, given how incredibly slow the tranfers are. Of course, there is another, perhaps even more disheartening, possibility: the incorrect behavior was observed and not corrected.

"Find Place" is nearly useless.

The "Find Place" feature can only find cities, despite the fact that many more things also have names. Why not provide a "Find Named Feature" function instead? Of course, this may be part of the "you bought this version of the atlas, so you don't get that data" punishment program.

"Find Place" is broken.

Searching for "Severna Park", a city in Baltimore, returns nothing. Backing up and searching for "Seve" (a prefix) shows a list of many matching cities, which includes "Severna Park". Selecting that city and hitting "Find" results in "Severey, KS" getting selected. I can't imagine what is going wrong here. Perhaps there is an index of some sort that is out of date with respect to the map data? I can't imagine.

Waypoints don't include the time of creation.

Waypoints entered via the "Clikstik" could easily store the time of creation (a GPS always knows the time). This would be immensely useful for correlating waypoints to tracks, to time-stamped photographs, etc. At least the trackpoints all include the time.

Saved tracks don't include the time of creation.

"Raw" tracks includes a timestamp for each trackpoint, which combined with a distance-based search matching algorithm allows you to guess an approximate time for waypoint creation. Of course it is a guess at best -- the map from time to position is one-to-one, but position to time is potentially one-to-many. But at least it's something. HOWEVER, Garmin throws away the time associated with each trackpoint when the track is saved! So not only does the track get horribly massacred when saved, a large portion of the useful information is destroyed!

Duplicate waypoint names are forbidden

If you enter a waypoint with the same name as an existing waypoint the software complains that the name is already in use. Certainly a valid complaint. However, the software neglects to make any suggestion of a waypoint name that *isn't* already in use in order to allow the user to make some rapid progress.

Perhaps the most irritating thing about these problems is they are all so apparent after comparatively little use of the device, and they could be all easily remedied by Garmin.

Posted by Matthew Eldridge at February 9, 2004 04:57 AM | TrackBack