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.

Apple iGPS

-----Original Message-----
From: Matthew Eldridge [mailto:graphics@eldridge.stanford.edu]
Sent: Monday, January 19, 2004 1:59 PM
To: Nils Blutig
Subject: RE: FW: Dates encoded in Garmin Waypoints?

Nils Blutig writes:
> you know who really needs to manufacture a handheld gps?
> Apple. They'd do it right.

Mmmmm. It would only speak AppleGPS protocol, but that wouldn't
matter, because it would only talk to a FireWire800 interface in a G5
MacIntosh.

But at least it would cost $800.

And be hermetically sealed so you could just throw it away once the
battery dies.

And it could use that ugly-as-shit-1984-nostalgia font they use on the
iPod.

I need a new GPS...

Spoiled Vista

Over two years ago I bought a Garmin Etrex Vista. It was the sexiest new model of handheld GPS, and promised to be good for hiking and adventure exploring. From day one, I have found it to be astonishingly unreliable (screen problems, shutting itself off, clickStick malfunctioning, condensation). Its software is quite mediocre, especially MapSource.

I am getting ready for a driving trip to Laos in a few weeks, and I need to have a GPS. I just turned on my Vista and the screen looks like a big UPC bar code. DOA. I'll send it back to Garmin for the second time I suppose, but at this point I'm writing it off as a $300 bad trip.

So what should I buy?

How I use a GPS

I've used the GPS mostly for 4wd adventure trips and bicycle trips. I guess I've used it for 4wd trips more, because the Vista loves to silently turn itself off during rough mountain bike rides, and furthermore works very, very poorly in the heavy jungle canopy of Southeast Asia. (I live in Singapore)

I use the GPS to document our trip (keeping the tracks, trying to set waypoints) as much as I use it for navigation. I never found that the Garmin had particularly good set of functionality for this. Yes, it sets waypoints, and yes it records tracks, but then, it also does things like arbitrarily compressing tracks. Furthermore, its "Worldmap" isn't very good in Southeast Asia. It's not even that good in Outback Australia.

I can imagine that some of the more GIS-centric systems make documenting a trip, route easier and more robust.

I can also imagine that other units could work better under canopies. After all, the Vista has no external antenna jack.

I've never used the Vista's altimeter (nor it's HALO and HAHO parachuting functionality...) so the feature set isn't actually that huge:

1) good reception
2) waypoint and track recording
3) compass
4) navigation to/from waypoints and tracks
5) better or alternative basemap options
6) small enough form factor that can be hand carried if necessary

What should I buy?

I'd be willing to consider even non-consumer grade GPS's, like Trimbles and Leicas, but I am not sure how well they'd serve my six criteria, and they're really expensive.

The Trimbles I looked at were the Trimble Recon, essentially a PDA for which you must buy a Pathfinder GPS antenna, and the GeoXT and GeoXM handhelds. Are there older model Trimbles that I might find second hand that would have enough functionality, and maybe not cost $4000USD?

The Leica also produces a high-end handheld GPS system, the GS20 Professional Data Mapper, which, like the Trimbles, is a $4800USD toy.

Any other ideas? Used units? Other brands? I'm feeling pretty dismal if I am going to have to buy yet another Garmin or Magellan (I can't imagine they're going to be any different or better than Garmin).

Integrating GPS and MoveableType

The problem

So yesterday I spent some time aggregating all my saved track and waypoint files from our trip to the Outback in August.

One problem with waypoints is that they're space-constrained. Thus I have lots of terse titles, "ROKAMP" (Rock Camp?) "MARYVGAT2" (Second Maryville gate?).

Another problem is that by the time I go back and try to do something with this information, three months has passed and names/places that made perfect sense to me then have melted away and I can't remember what I was thinking.

The first problem is structural, but the second problem could be helped with the collective memory of the four other folks on the trip.

The idea

People can jog others' memory. Maps can jog others' memories.

What would be a cool format for this? A blog, of course.

What I want is some software that processes each row of a waypoint file. It then calls the appropriate MoveableType/BloggerAPI and generates a blog item for each of those rows.

Waypoints from different trips/days/routes could be given their own category. It could play with the publishing date to control the ordering of the waypoints so that consecutive waypoints are displayed consecutively in the blog. The blog item would have the same title as the waypoint. The other information (GPS coordinates, elevation, etc) are stored in the body of the blog.

Since comments are "on", people can browse the waypoints and add what they remember to that waypoint. Before long, you have a fleshed out waypoint report.

It would be cool to somehow integrate a map (generated from OziExplorer) into all of this but that would be a considerably larger challenge.

===
UPDATE (November 10th)

In searching for some example code to implement this project, I found a guy who wrote a clever system for submitting blog items via his handphone/camera combo.

Wish he had an email address on his site...my perl-generated blog items seem to have some subtle (?) problems with them.

What I could really use would be some hints on debugging MT-related applications in perl. Hell... I can't even find a proper error log.

===
UPDATE (November 15th)

Being able to easily convert GPS Waypoints into blog items allows easier collaborative mapping.

Map Prep

Spent a chunk of this afternoon packing up gear for the Finke trip on Wednesday. This evening I worked on the navigation.

Mapsource
I reluctantly re-installed Mapsource so that I could download Garmin's meagre basemap of Australia into my GPS. Six map quadrants covered an enormous swath of Australia--very nearly from Darwin on the north coast to the southern coast. I expect I could put the entire Australian map into my GPS if I wanted to.

I upgraded the Mapsource software from 3.20 to 4.something. The errata doesn't show any special new functionality just endless kludge-sounding fixes where in certain peculiar circumstances Mapsource does peculiar things. ("2. Fixed an issue where the Tide Prediction calendar control was not working correctly in some date ranges when Windows was set to a time zone that automatically adjusted for daylight savings time." and "5. Fixed an issue where MapSource would not correctly send the Dark Green track color to some units." )Big Suprise. I don't really know why these hacks merited a left-of-decimal-point increase.

At least now I have basic Australian navigation capability, so long as the Etrex Vista doesn't vomit on me during the trip.

OziExplorer and Epson 2100
I'm not bringing any laptop this trip, so I'll have to rely solely on GPS and paper maps. The amusing thing was to take some of my higher-fidelity maps of Australia, load them into OziExplorer, dump the map.BMPs to Photoshop, and convert that into a one-page map cropped and accented to my exact specifications.

The final result was compressing the better part of three large maps into an A3 format page (11.7"x16.5") printed with photo quality. Fortunately my printer has excellent resolution. The map detail is just large enough to be legible with an unaided eye. It's nice to have the complete course on one map.

This prototype should help me to figure out what makes a good custom map design for our August trip.

Pox on the House of Garmin

So when I set off on a bike ride this afternoon, I tried to make out the strange color along the bottom of my Garmin Etrex Vista's lcd display.

"Oh, yes, of course, it's condensation inside the unit."

"But, Garmin claims the etrex is rated for 'Immersion for 30 minutes at a depth of 1 meter', and all you've done is ride your bike in the rain."

"Ah, but you see, it's a Garmin... and nothing Garmin says has to be true at all and their products can be entirely defective."

So I don't know what the hell to do about this unit. I can hardly send it back to the USA for yet another rebuild.

I don't know why it leaked. Perhaps because I am using Garmin's own bicycle mount, and it has a poor seal? (Actually... I think that the battery compartment is outside of the immersion-sealing zone. That is, the battery compartment could flood (it could easily with the microscopic rubber seal they provide) but the internal compartment holding the computer stays dry.)

I really wish they'd get themselves in order. Their products are universally crap.

"On the Ground in Iraq, the Best Compass Is in the Sky" by Seth SCHIESEL NY Times

On an afternoon early this month, in the desert near Najaf, Iraq, elements of an elite United States Army unit received word of a column of almost 60 vehicles, including about two dozen tanks, moving along a nearby road.

Some of the soldiers thought it could be Saddam Hussein's Republican Guard.

Then a general in his Humvee leaned over to a computer console that is part of a satellite-based navigation system called FBCB2. He tapped in the military grid coordinates where the mystery force was located. Then on the screen, up popped the little blue symbols that represent friendly units, rather than the red icons that the United States military uses to designate enemy forces.

It was not the Republican Guard. It was a separate United States division.

During the cold war and even the 1991 Persian Gulf war, satellite technology was not an everyday part of the lives of foot soldiers or even generals. But in the Iraqi desert, satellite technology - specifically the Global Positioning System, or G.P.S. - has become a fundamental and pervasive navigation tool for ground forces.

G.P.S. gadgetry has become almost as much a part of army life as shovels and cigarettes - whether integrated into vehicles in advanced systems like FBCB2 (often referred to as "blue-force tracker"), used in the hand-held receiver known to soldiers as the Plugger, or even bought off the shelf.

"Primarily the way that G.P.S. technologies have changed the way the army can perform its mission is it has given us a more accurate way to navigate the battle space," said Lt. Col. William S. Harborth, the Army's product manager for Global Positioning System technology.

That means the devices simply help soldiers figure out where they are. Perhaps even more important, the ability to define location precisely can help soldiers figure out where other units are.

"Increased accuracy is more important because if you know better where you are, you can ensure that you reduce fratricide," Colonel Harborth said. "In the old days, there was some human error in determining your location on the ground."

Satellite navigation continues to be crucial for long-range weapons like cruise missiles, and G.P.S. is essential in the sort of unmanned aircraft that saw their first broad deployment in Afghanistan. In contrast, the main such tool among ground troops, the Plugger, is in some ways less sophisticated than gear found at Wal-Mart or in rental cars - its utility in traversing the open desert diminished as forces entered urban areas, for example, since roads and landmarks are not programmed into it.

Still, the increasing use of satellite-based systems for navigation - and for "situational awareness," in military parlance - is one of the biggest changes in United States ground operations since the 1991 gulf war.

During that war, the Global Positioning Satellite network was in its infancy, and among front-line units, a single G.P.S. receiver might be allotted to an army company, perhaps numbering 180 soldiers in the infantry. Now the Army says that it has more than 100,000 Pluggers (the name is derived from the initials for their full name, PLGR for Precision Lightweight G.P.S. Receiver). In Iraq, the leader of each combat squad, which might include nine soldiers, often has a Plugger at hand; in some Army units, Pluggers are even more numerous.

The Marines have adopted the technology more cautiously. Matthew Brandt, the Marines' project manager for G.P.S., said the corps had purchased only about 5,400 of the units and generally deployed them at the platoon level. (A platoon might include three to five squads.)

That may be one reason that at least some marines are carrying their own civilian-grade G.P.S. devices from home. The civilian devices, made by companies including Garmin International, are typically smaller than Pluggers and, though not quite as precise as Pluggers, are apparently sufficient for everyday purposes.

Those purposes can be as trivial as finding the chow line. Before the shooting started in Iraq, some soldiers in front-line units were using their Pluggers to navigate through the dark and sand to the mess tent.

As with most technologies, however, satellite navigation is only as useful as the human intelligence guiding its use. For instance, in late March an American military detachment was sent to pick up some prisoners near Najaf. The soldiers were told the coordinates of the captives.

Their Plugger unit worked fine and the soldiers reached the coordinates. But they did not find the prisoners there. Instead, they came close to a mortar attack. The human intelligence had failed, not the device.

And even with the growing use of satellite navigation devices, there are gaps. A prominent setback for the Army in the early days of the war was the ambush of members of the 507th Maintenance Company near Nasiriya, Iraq, in which eight soldiers were killed. A private captured in the confrontation, Jessica D. Lynch, was later rescued, and five others taken prisoner were found alive north of Baghdad on Sunday.

The Nasiriya episode, which occurred while the soldiers were traveling in a convoy of trucks and other vehicles, was initially attributed to their having taken a wrong turn off a major highway. The Army has refused to comment publicly on precise details of the incident, and more recent accounts indicate that the convoy was ambushed after having stopped to repair vehicles.

But a technology expert with the American forces in the region and a civilian expert on military G.P.S. both said it was unlikely in any case that the captured unit had a G.P.S. device on board.

While Plugger units are almost ubiquitous among front-line combat units, they remain less common among units like maintenance companies, which are not generally meant to engage the enemy.

Even soldiers who have Pluggers are relying on devices that are in some ways primitive compared with their civilian counterparts. It is a curious position for the Pentagon, the driving force behind the creation of the constellation of 24 G.P.S. satellites in the 1980's and 90's.

The Plugger devices remain largely unchanged since their initial deployment in 1994 (although their cost has fallen from about $2,000 each to less than $1,000), and for many purposes, the relatively scant information they provide is sufficient. Soldiers can specify their destination, and the unit will tell them what direction to go. Using encrypted satellite signals reserved for government use, they are accurate to within roughly 10 yards, compared with 20 to 25 yards for civilian devices.

Built for resilience in combat, they are big (roughly the size of a small shoebox), heavy (about 2.75 pounds) and have a small text-based display incapable of showing maps or other information. In general, the units, which are made by Rockwell Collins, display only location, velocity (if the unit is moving) and time.

Civilian G.P.S. devices like the NeverLost system in Hertz rental cars, in contrast, are often able to display maps and other information.

The advanced graphical FBCB2 system used in Army combat vehicles, in contrast, allows commanders to electronically "see" broad swaths of a battlefield. In the version of FBCB2 known as "blue-force tracker," far-flung United States units not only receive their location information from G.P.S. but also communicate with one another using other classified satellite systems. Other versions of FBCB2 units receive their location from G.P.S. but communicate with one another using land-based radio.

(In either case, the system is connected by cable to a Plugger, which serves as the actual location-detection device. In fact, more than half of the Pluggers in the Army are not used in a hand-held mode. Rather they are used as "slave'' location-detection devices for other systems, which include air-defense batteries in addition to FBCB2.)

FBCB2, which has been in development since 1997, has been deployed in practically every tank and Bradley fighting vehicle in the Fourth Infantry Division, said Michael Lebrun, deputy director in the Army's command, control, communication and computers office. Elements of the Fourth Infantry, which in some ways is the most technically advanced of the army's infantry divisions, are on the way to Iraq.

The FBCB2 system displays the location of similarly equipped units in the area as blue icons. When any of the units spot enemy forces, they enter their location into the system. They are then displayed as red icons, and that information is relayed to other FBCB2 trackers.

Mr. Lebrun said that over the last seven or eight months, FBCB2 was deployed to other army divisions, though generally company by company. A tank company might include three platoons, each with four tanks.

For foot soldiers without access to the FBCB2, however, satellite navigation usually means getting their location from the Plugger and then using a paper map to plot their location manually.

That is why the Pentagon is ordering a new generation of hand-held G.P.S. devices, to be known as DAGR, pronounced "Dagger," for Defense Advanced G.P.S. Receiver. Rockwell Collins is competing with Raytheon for the right to produce the new system, which is scheduled to reach everyday soldiers next year. The Pentagon is to pick the winning company in September.

"Plugger is about 12 years old, and if you can make an analogy to the commercial electronics marketplace, just think about your cordless phone you had at home 10 years ago versus now," said Mark Youhanaie, Raytheon's strategy director for G.P.S. products. "Now, we can make these receivers more accurate. We can acquire the satellite signal more quickly. It has higher jam immunity, and we can give you that all in a package that is a quarter of the size of the old Plugger system."

For now, it appears that the Rockwell Collins contender is a bit smaller than Raytheon's, while Raytheon's boasts a bigger screen. Whichever company wins, however, the Dagger will weigh only about a pound and will be much smaller than the Plugger. Perhaps most important, the new devices will allow soldiers to see not just lines of coordinate numbers, but also a map that shows their location in relation to objects like minefields, rivers and enemy positions. The units will also incorporate graphical user interfaces.

Drawing a comparison to generations of computer operating systems, Steve Jones, the Rockwell Collins marketing manager for land navigation products, said that "Plugger is DOS, and Dagger is Windows."

By plugging the Dagger system into a military radio, soldiers may be able to display their location on the screens of nearby Dagger units or more advanced FBCB2 systems, Mr. Jones said.

The Dagger devices, which are meant to initially cost about $2,000 each, will be more advanced than the Plugger in other ways as well. While the Plugger receives its encrypted signals at 1,575 megahertz, the band also used for civilian G.P.S. devices, the Dagger will also be able to pick up signals at the government-only 1,227-megahertz band, allowing for additional accuracy. The 1,227 band is now used largely for military aircraft, cruise missiles and other airborne systems, military officials say.

The new system will also track all 12 G.P.S. satellites in each hemisphere at once. The old units can only track five satellites at once, and signals from four satellites are required to establish a three-dimensional position. In addition, current G.P.S. receivers are somewhat vulnerable to enemy equipment that beams false G.P.S. signals to indicate the wrong location, a technique known as spoofing.

The Dagger is meant to include classified technology that will help the device verify that the signal it is receiving is actually coming from a United States G.P.S. satellite.

It is still unclear just how many of the new devices will reach United States soldiers. "The plan was to replace all of the Pluggers in one year,'' said Mr. Brandt of the Marines, "and of course that depends on how much money Congress decides to give us, which is never certain."

But no matter how many are ultimately deployed, the new devices are meant to give the soldiers perhaps the most precious commodity on the modern battlefield besides life itself: information.

"The key is greater situational awareness for our soldiers so we bring them home alive," Colonel Harborth said. "That's it."

Using Oziexplorer

I started playing around with OziExplorer and my newly-repaired Garmin Etrex Vista this evening. I went on a bike ride through some less-manicured areas of Singapore yesterday and wanted to work out a trail map.

Since there wasn't heavy jungle canopy, the GPS worked fine and I got a good track and set pertinent waypoints.

With only a few moments of twiddling (well-guided by the OziExplorer help file) I had downloaded the tracks and waypoints from my Garmin into OziExplorer.

I don't have a base map of Singapore (where can I find a digital base map of Singapore?) so I just called OziExplorer to create a blank map. Simple.

[My user experience so far suggests that OziExplorer was written by a GPS-Navigation enthusiast who added functions as he thought, "Gee, it would be useful to have function X." So far he's thought of everything that I want to do. The downer is, it's all organized in a somewhat non-traditional menuing and icon structure. It's idiosyncratic, but I am sure I can get used to it. (The icons are real eyesores, though -- way, way too busy) ]

I pulled up the base map and the map size was way too big. It had world map Lat/Long proportions. I started throwing away a few left-over waypoints from Canada, USA, Taiwan and Europe and reduced the map info to just local Singapore geodata. Then used the button called, "Rescale Map." It pruned the size, but still the few waypoints and tracks I had (a meandering, short 9 mile bike ride that probably was 3 miles diameter max) were still too small in scale to the map. They were piled right on top of each other.

Repeated rescans wouldn't make it any smaller, and my zoom was maxed-out at 750%. What am I supposed to do?

Consulting the help file, I found this troubling (?) explanation:

Why doesn't OziExplorer have zooms larger than 750%

OziExplorer is Raster software (that is it uses images for the map, even the blank map is just an image). Zooming in on a raster image does not improve accuracy. The best a raster map can be calibrated to is +or - 1 pixel, when you zoom in at say 500% (x5 times) each pixel in the map image is increased 5 times, the accuracy of a position is now +or - 5 screen pixels. There seems little point in adding more zoom levels, as the calculations cause pixel rounding the liklehood of causing positional errors (on the zoomed screen that is) increases as the zoom level increases.

I do agree the blank map zooming could be improved as an image need not be used for that but to do that I have to rewrite quite a bit of the code and am saving that for a while.

So I don't know... Am I stuck from ever displaying a 3-mile diameter set of tracks in size large enough to read comfortably? It is sounding like I'm stuck.

Let's put it this way, I would be happy to sacrifice some accuracy in an image of my mapping data if I could zoom it enough to nicely fill a 8x12" paper map. It feels like OziExplorer is assuming that I demand absolute cartographic precision or nothing else. All I really want in this case is a trail map I can refer to now and then -- not a rigorous map.

If I'm forced to, I can always just save the map to an image, and then inflate it with Photoshop, but this is such a gross solution, and I'd prefer to do all my work inside OziExplorer.

Ideas?

How Pathetic is Garmin's Technical Support?

I just completed uploading the transcripts of several email exchanges that show how bad Garmin tech support is. They're clearly ignorant and seem to suffer the sin of sloth as well.

Garmin makes junky products that almost work and backs them up with substandard tech support.

These are the reasons I am so tempted to use a professional GPS, not a toy.

Another interesting Geocache, in Alameda County

Here is another geocache candidate: a strange antenna/radar array location in Alameda. It's got a bunch of cool antennas, a bunker, and some uninformed insinuations that their long-wavelength antennae are responsible for a mass-murder in Sunnyvale several years ago. Appeals to cranks of all ages!

An Interesting Geocache

A lot of geocaches are corny -- too easy to find, stupid items in the cache. Some virtual caches are interesting to find, but they just end up with 'scenic vistas'. I stumbled onto an interesting target for a geocache hunt -- a map of some United States military aerial refueling routes.

It's not clear if these are always used, or just used during Nellis AFB's annual 'Red Flag' training exercise. But if you were lucky to find the route at the right time you'd see any number of planes cited as participating in the exercises:

A typical Red Flag exercise involves a variety of attack, fighter and bomber aircraft (F-15Es, A-10s, B-1s, etc.), reconnaissance aircraft (UAV -Predator), electronic countermeasures suppression aircraft (EC-130s, EA-6Bs and F-16s), air superiority aircraft (F15s, F-16s, etc), airlift support (C-130s, C-141s), search and rescue aircraft (HH-53s, HC-130s), and aerial refueling aircraft (KC-130s, KC-135s). The E-3 Airborne Warning and Control System (AWACS) aircraft plays a significant role in the training by using its unique radar capability to monitor and support many aspects of the "Blue" force effort.

Since I built my new computer, and my shitty Garmin GPS is being repaired, I haven't bothered to install Mapsource on my pc, so I don't know exactly where the GPS Waypoints sit in Nevada. But there are particular parts of the route that might be more or less interesting. This page explains the components of the refueling route and provides a diagram title "Anchor Pattern" at the bottom of the page. There are locations like 'Tanker Orbit', 'Receiver Holding Pt' and 'Outbound Course.' Some of those may be more or less likely to have something interesting to see. These legs are supposed to be at least 50NM long.

This could be an amusing weekend's project and a fun Geocache writeup.

Dead drop compromised!?

Word back that the first leg of the Asymptotic Linked List has been compromised.

Hard to believe that the triple-redundant communication channel would have been entirely lost.

Perhaps the angry individual decided to blow the whole operation.

Hopefully a freelancer will check out the scene, sort it out, and report in...

Moving Mapsource Data Locally

We've got a lot of complaints about MapSource, and for most problems, Garmin is unlikely to ever resolve them.

Leave it to 31die to provide an excellent solution to one of the most vexing -- the inability to use the MapSource data locally on the harddrive. Now you won't have to suffer Mapsources slow, tedious CD-Rom data accesses. Nothing is quick or efficient inside of MapSource, so these optimizations are worth their weight in gold.

Here are 31die's instructions.

> Run regedit and navigate to
>
> HKEY_LOCAL_MACHINE\Software\Garmin\MapSource\Products
>
> Under that I have 4 entries, labeled 6 through 9. These correspond to
> Alaska, Hawaii, West and East US. Each one of them contains 3 keys.
> Bmap and Tdb will already be on your machine, Loc will point at a
> subdir of your CD-ROM. Just copy that subdir wherever and change the
> Loc key to point at it.
>
> For example, I copied E:\West to D:\data\mapsource\West and changed
> the key in the exact same fashion.
>
> It doesn't even look for the CD -- it must be authenticated by
> whatever serial number we typed in initially.
>

p.s. remember that if you want to pass around this article to others, forward the 'permanent link' below, not the generic black-coffee blog url.

Eldie Precog

31die provides a first screenshot for his Precog Terrain Visualizer. This is the software that will give us Predator Drone-like coverage while we are blasting through the Australian Outback in a convoy of diesel Land Cruisers in 2003. Excellent Stuff.

'Desert Explorer' Arrived

So yesterday my Hema Maps Desert Explorer CD Rom arrived. It's a single CD and has a quick installation. It comes with a copy of "OziExplorer LITE," which as far as I care should be named "OziExplorer BROKE."

There were a number of irritating graphics-based problems immediately. The tiny little drilldown-zoom window was being misdrawn. You could only see about 55% of it. The map index window, once minimized couldn't be restored.

I have no time for shabby software like that. I did a short search for software upgrades for OziExplorer LITE, but failed. So I ended up going back to using the "OziExplorer 'DEMO'" version. At least the graphics errors were solved.

So how are the maps? There are six of them designed to provide overlapping coverage of the central outback of Australia. The scale is 1:1,250,000. The typography and legending is nice. However, the map lacks the track detail I'd hoped for. Maybe I am being unfair.

My total lack of sense for the size of Australia probably to blame. These maps are 1:1,250,000 scale. Is that big or small? To put it in perspective here are some map scales for some Arizona Maps...

• 1:24,000. 7.5 Minute Series (Topographic). Reston, VA: U. S. Geological Survey, 1945 to present, app. 1971 sheets when complete. G4331s.C2 1882.U6

• 1:50,000. Arizona 1:50,000 [15 Minute Series (Topographic)]. Washington, DC: Army Map Service and Defense Mapping Agency, 1947 to present, currently 92 sheets, coverage incomplete. G4330s.50.U5

• 1:62,500. 15 Minute Series (Topographic). Reston: USGS, 1910 to 1968, 306 sheets, coverage incomplete. G4331s.C2 1882.U6

• 1:100,000. 30 x 60 Minute Series (Topographic). Reston: USGS, 1980 to present, 68 sheets when complete. G3700s.100.U5

• 1:125,000. 30 Minute Series (Topographic). Reston: USGS, 1901 to 1939, 23 sheets, only partial coverage. G4331s.C2 1882.U6

• 1:250,000. 1 x 2 Degree Series (Topographic). Reston: USGS, 1953 to present, 22 sheets, periodically revised. G4050s.250.U5

• 1:500,000. State of Arizona. Reston: USGS, 1981, 1 sheet. G4330. 1981.G4

• 1:1,000,000. World (North America) 1:1,000,000. Reston: USGS, 1952, 4 sheets, coverage incomplete. G3200s.1,000.U51
  

So you can see that the entire state of Arizona can be comfortably mapped at 1:500,000 scale. That scale represents 7.891 miles in one inch.

The entire area of Australia is 7,682,000 square miles, similar in size to the 48 mainland states of the USA. Lonely Planet says that 75% of this continent is referred to as the 'Outback.'

Therefore, it's impossible to squeeze the desert outback (assume it's only just 50% of Australia) into Arizona-scale maps -- roughly 20 states' worth of data on six maps -- 3 states on one map.

Consequently the Hema maps are 1:1,250,000 scale where one inch equals 19.728 miles and you can fit the equivalent of half the 48 states into six maps.

Once I considered the maps in scale terms, I'm more comfortable with the detail level they provide. Maybe moreso when I realize that Hema field-checked all these tracks, which tend to move around and degrade. So the major tracks on the map you can rely on more comfortably.

Of course, I would like more detail... more side trails, more pointers to ruins, mines, and other strange points of interest, but I'll get at those in different ways.

Thanks to the OziExplorer software, I can keep several different maps, even satellite images, inside the software. Then as we are driving along, the GPS updating our coordinates in OziExplorer, I can switch to different panes showing our location on each of the different map sets I have loaded into the software. Therefore I am able to drill down on my specific location as necessary and as the mapping data is available.

For sure the next series of maps to load would be the Auslig data. Since these maps are much larger scale (1:250,000) than the Hema maps(1:1,250,000), you get a lot more detail, even down to dwellings. That is a very good start for points of interest, for example.

There are more piecemeal data sources too. Recently I found data for the 'Northern Territories' that allows me to get actual aerial photography of the regions around and north of Alice Springs all the way to Darwin.

To show the level of extra detail provided by those two compare the Hema Map detail to the the Aerial Photo detail of the same region. Drilling down further on the Aerial Photography maps yields thumbnails of aerial photos that you could order!

This allows us to take an interesting approach to trip navigation. We plan a route based on the basic Hema maps and Auslig maps. And then we drill down on specific areas and points of interests and seek out supplementary data, like aerial reconaissance and satellite imagery to provide some more color to the navigation.

Another Australian Map Datasource

Logisitical planning for our 4wd trip through the Australian Outback next year is made easier by the excellent mapping resources provided by the Australian Government, through Geoscience Australia.

The most important item is their "Natmap Raster 250k Mapsheets 2002." The project, "provides georeferenced digital images of Geoscience Australia's 1:250 000 scale national maps covering the whole of Australia." Two cd's hold the entire 518 map collection. "Each map image is georeferenced to Map Grid of Australia (MGA94) coordinates, which allows interfacing with software that uses geographic positions such as GPS mapping software and geographic information systems (GIS). The MGA projection is ideal for measuring distances and areas."

How would we use the data? "NATMAP Raster 250K contains all the software needed to use the maps on the Windows 95/98/2000/NT4/Me/XP operating system - all you need is Internet Explorer 5.5. " Futhermore, folks have written some free software to allow this map data to be used inside OziExplorer. I also expect the 31die Precog/Terrain Visualizer could take advantage of the data.

The maps, updated as recently as June 2002, show nice detail that would be helpful in finding interesting sites to seek out -- things like abandoned mines, salt evaporators, and other ruins.

It only costs $99AUD, so I will order it and have it for December, when 31die is in town the Summit, when we plan our wicked works.

Geoscience Australia is worth browsing. One of the goodies is a zoomable/scrollable Landsat 7 Picture Mosaic of Australia

HemaMaps Desert Explorer CD (pt 2)

Last week I wasted time trying to get this CD.

Expecting disappointment, I called back today, and found that their revisioning (which was only to revise the packaging, not the map data [different story than last time]) had been delayed several months. So they simply reproduced some of their current stock, so the CD is now available. I ordered it, it will be sent out tomorrow. Maybe I get it next week sometime?

At any rate, I'll now have some desert mapping to look at for trip planning.

Overview of GPS Technology

This is a quick introduction to how GPs technology works. It only takes about seven minutes to read. The last half is some boilerplate about Garmin products, but the first bit about the GPS Satellite network is sort of interesting.

I also remember discussing w/ my dad how the Garmin unit handles north (magnetic and true). This report says the unit just has its own little model of the magnetic fluctuations around the earth.

Hemamaps Desert Explorer

Wasted lunch hour today... Wanted to get the Hema Maps cd of their six desert tracks maps. I hunted down their distributor in Singapore, Mapco, and called them up. Sounded like I was calling the local fishmonger at the wet market, but the woman said that yes, they had it, and it was sold at both Borders and Kinokuniya. Then she hung up before I could ask another question.

So of course I hopped in a cab and went over at lunch time. And of course they didn't have it. When I talked to the folks at the information counter they had no record of it at all. They called the distributor themselves, who told them that 'no, they don't carry it and never have.' Great.

So I came back to the office and called Hema directly in Australia and started purchasing it over the phone. Almost finished the transaction before the woman remarks about the wrong product. When I tell her that I was looking for the CD Rom, she says, 'oh, no, that won't be ready for another two weeks--it's in re-production.' Groan again. I asked her, 'are you sure this is really "two weeks" or in two weeks it'll still be "two weeks", and I'll be in store for a WRX-repair-style wait?"

She checked around, and it sounded much more like six or eight weeks. They were updating the maps, packaging, everything. On one hand it's good -- I'll get a better product, on the other hand I won't be able to get it before Christmas unless I'm very lucky.

I guess in the meantime I'll continue my investigation of OziExplorer.

Exploring OziExplorer (part 1)

//Basic idea of what it is supposed to do

OziExplorer is a generalized system that allows you to import an arbitrary map image, which is then calibrated (georeferenced) so OziExplorer can use any pixel position on the map to determine the true geographic position. There are two more basic sets of functionality it provides. First it allows you to notate and measure the map. Secondly it communicates with your GPS to give you real-time positioning inside OziExplorer.

OziExplorer's distinction from other products is that it can import arbitrary maps. MapSource only works with the proprietary maps produced by Garmin. Consequently you have more options for getting mapping data to areas you want, and it also allows you to generate your own maps. This might not be as vital in the US, where MapSource has good coverage, but in Singapore, for instance, the World MapSource disk is anemic and useless. However, for example, I have this great satellite image of Singapore that presumably OziExplorer could consume and allow me to use with my GPS.

The immediate limitation I noticed for Garmin GPSs (I have a Garmin Etrex Vista) is that maps you create from scratch with OziExplorer cannot be uploaded into the GPS. So if you create a custom map, the only way to use it is to have a laptop with you receiving location data from the GPS, or by uploading just the waypoints and routes created on your custom map up to the GPS. The third work around is to buy a different brand of GPS that DOES allow it. There is no way to view the map you created on OziExplorer on the the Garmin GPS display. Thanks for another proprietary format, Garmin. (PROJECT-IDEA: People should investigate how to create their own basemaps that are Garmin-compatible, whether Garmin likes it or not.}

//Background
OziExplorer is written by one guy, with the intention of making a gps/mapping system for planning his 4wd trips. In some ways this might be good -- you stand a chance of being able to communicate with someone who knows something, rather than faceless MapSource and their abysmal technical support staff. On the other hand, writing software like this would require him to know a broad range of subjects in good depth. Since I haven't used the software yet, it's hard to say if he has succeeded.

In the 'About' section of his help file, he is quite straightforward about the philosophy of the software and his intentions. I respect that. The guy recognized a tool he needed, couldn't find the tool already, so he built it for himself. Fortunately for me, I need the same tool, too.

...coming in Part 2.... How well does it work, and is it up to the task?

An alternative to Garmin MapSource?

Garmin MapSource is very mediocre software, and there is lots to not like about it, including not only its poor design and operation, but the non-USA data sources are abysmal. To put it in perspective, I have their mapset for the USA/Hawaii/Alaska. It's three CDs, and very detailed. I have their world ex-USA, too. It's one cd. It's got basically nothing. The Singapore section is basically worthless.

The poor operation of the software we can curse, tolerate, and workaround. The lack of decent map data, however, is going to make our 4wd trip through the Australian Outback harder.

I have found a potential answer. A company called Hema Maps produces detailed Australian Desert Track maps. They've converted these to a single CD called the "Great Desert Tracks CD-ROM". I asked them what I can do with the cd. Turns out it is only a data source -- there is no viewing capability. The CD is to be read by a program called OziExplorer.

Checking the site out, it seems like an Australian version of MapSource. The website is somewhat tacky, and shouts out small-time-operation, but perhaps the software is built better than MapSource. I've just skimmed it superficially, but already I've found one alarming thing. It implies that their "map creation" (you can create your own map features) is unable to upload the maps you create to any Garmin GPS. I'd have to get more clarification on this. At any rate, we should investigate this program as an alternate to Garmin Mapsource.

This weekend perhaps I'll download their evaluation copies and see how they run. The software costs $75 and some sort of 3-d add-on costs an additional $25. I'm going to do myself the favor of reading the support groups and see what kind of complaints are coming out about the software. Maybe spare myself some headache if this thing turns out to be a piece of shit.

Of course, hopefully our need for this product will be mooted by the completion of The Eldie Pre-cog sub-metre terrain tracking and visualization system.

Asymptotic Linked List

Some dude found the first segment of our nasty cache Asymptotic Linked List. The first segment is easy, but what is interesting is that It's seen no activity between May and September, probably because it is like 110 degrees in the area.

Reminds me that we should set up some local geocaches.