GPS, the Global positioning System, was designed in the 1970s under hardware-cost constraints that would seem ridiculous today. This makes interpreting the data it sends into a black art, and produces some really painful edge cases.
There’s one edge case in particular that I’ve come to think of as the Rollover of Doom. This morning I came up with an evil, clever hack for getting around it. I call it clever because you have to think your way out of a conceptual box to see it. As to why it’s evil…well, you’ll see. If you can figure it out.
Welcome, ladies and gentlemen, to another darkly humorous tale of the seamy side of GPS interfacing. GPSD working with USB GPS mice has, when properly installed, lovely plug-and-play self-configuring behavior. That is, you plug a USB GPS into a USB port, the hotplug system notifies the gpsd daemon that the GPS is available, the daemon records this fact…and subsequently when you start up any GPSD client application It Just Works. Well, usually. There’s a dangerous weakness in the machinery, and yesterday it came around and bit us in the ass.
In discussion of the GPSD project, a commenter suggested that its role might be going away in part because the NMEA 0183 protocol historically used in GPS sensors is being replaced by NMEA2000. So far, this is not true, and the reasons it’s not true are worth a look because they illustrate a sort of flip side of the economic and technological tends driving the adoption of open source and open protocols in the wider technology market.
Yes, GPSD is way cooler than your project. You know how I can tell?
Because my latest feature request is from a scientist who wants to use GPSD as part of the control software for an autonomous robot submarine. That’s how I can tell.
No word yet on whether the robot submarine will have a frickin’ laser mounted on its frickin’ head. But I’m hoping.
Me, on the GPSD mailing list:
Once upon a time, I did not hate autotools. Yea verily, it was the morning of the world and all things (even autotools) seemed fresh and new). I’d say this innocence lasted until about, oh, 1995.
But autotools was a kluge. And it did accrete kluges and crocks around it, adding layers of complexity until it became sore difficult to tell which end was up. And lo, it became a festering pile of special cases and obscure semi-documented rules, leading to a combinatorial explosion of unplanned interactions and obscure lossage.
Like, say, the fact that our make check insists on running gps-makeregress twice and in spite of being a genuine autotools expert with fifteen years of experience bear-wrestling the sorry fscker I cannot figure out why it is doing this.
Oh, there’s a reason, all right. And if I were willing to quintuple the three hours I just spent poking at our build setup I’m sure I could find it. But that was three hours wasted as far as solving any real problem was concerned. Life is too short for such nonsense.
Autotools has reached the Chandrasekhar mass limit of software and become a black hole of suck that consumes endless hours of bright peoples’ time without any good result. It is well past time for it to die.
I’ve been doing some heavy work on the core code of gpsd recently, and realized it would be a good idea to explain the whys and wherefores to my co-developers on the project. After I wrote my explanation and reread it, I realized I had managed to generate something that might be relatively accessible, and perhaps even interesting, to people who aren’t intimate with the GPSD codebase.
I guess I’m aiming this at junior programmers and particularly curious non-programmers. It’s a slice of what software systems design — the thing that project leads and architects do — is like in the real world, where the weight of history is often as pressing as today’s requirements list. I think this note shows an example of doing it right, or at least not getting it too badly wrong.
If you find the technicalese in here difficult, it may be useful to refer back to some of my previous posts about this project:
GPSD and Code Excellence
GPSD-NG: A Case Study in Application Protocol Evolution
Why GPSes suck, and what to do about it
I’ve been wanting to migrate the GPSD codebase off Subversion to a distributed version control system for many months now. GPSD has a particular reason for DVCS; our developers often have to test GPSD sensors outdoors and aren’t necessarily in range of WiFi when they do it.
GPSD also needs to change hosting sites, for reliability reasons I’ve written about before. Though I’m a fan of Mercurial, I determined that moving to git would give us a wider range of hosting options. Also, git and hg are similar enough to make intermigration really easy – from SVN to either is 90% of the way to the other.
This blog entry records two problems I ran into, and solutions for them. One is that the standard way of converting repos does unfortunate things with tags directories. The second is that the CIA hook scripts for git are stale and rather broken.
There’s been some upset in the blogosphere over the shutdown of the LORAN system of radionavigation beacons. This post at Chicago Boyz is representative (hat tip to Instapundit). The author worries “Iâ€™m not totally sure that this was a good decision.” and various commenters are much more emphatic, bemoaning the lack of a backup for GPS.
In my capacity as lead of the GPSD project I’ve been required to become a topic expert on the strengths and weaknesses of GPS and various competitors to it, including LORAN. So here’s the straight scoop: yes, a backup for GPS would be a really good idea. No, LORAN was never plausible as that backup, so angsting about its passing on those grounds is just silly.