GPS Hackery

• Hardware
• Updates
• Tools
• Other Tools
• Links
• Further Reading
• Other stuff
• GPS Observatory

I've been interested in GPS for ages (the February 1996 issue of Scientific American didn't do anything to convince me that GPS was boring), but it's only recently that I fired up my text editors and started to write some stuff. I'm interested in a few applications of GPS: precise time transfer, mapping, autonomous navigation and positioning.

The mapping angle is obvious. Toss my laptop in my backpack with a USB GPS on one shoulder and a USB wireless interface on the other, and I have a highly mobile platform for wireless site surveys, quality of service testing and wireless security scans. And when I travel it's good to be able to answer "where am I, why am I in this hand basket and most importantly, how do I get home?" To that end I've actually paid good money to Microsoft for the last few versions of Streets and Trips. Certainly the "navigate to foo from current GPS location" feature works.

Navigation and mapping are low-hanging fruit as well, although I know some people who are race car nuts of varying intensity, and it'd be fun to kit out their cars with sensors and go for a virtual ride-along on a race. Another neat application would be to have a virtual co-driver for rally races. With some sufficiently precise measurements of the course and careful measurements of the car's behaviour during a trial run, the virtual co-driver should be able to talk the driver through upcoming hazards.

A few years ago I took a little road trip and brought my eTrex (before I got rid of it) and my TN-200. I'm fairly impressed with the fidelity of the TripNav; its one-second output of PVT information seems to be right on, and it seems to be more stable than the eTrex for holding a fixed position. Then again, I did have the TripNav stuck to the roof of the car, whereas the eTrex was sitting in the back window. Also, my eTrex stopped outputting NMEA after a while, so I didn't get realtime logs from it most of the way. I was able to download the track log which I used to compare the units, but that was annoying. So the short version is that I'd recommend using a device like the TripNav which is designed for continuous computer hook-up, rather than the eTrex hanging off a serial cable. (top)

Updates

(2005/10/25) We're still waiting on SiRF to tell us whether or not we can distribute the binary blobs, but the good news is that the SiRFstar II and III programming procedures are identical. I've got a new laptop; an IBM/Lenovo T42 with onboard accelerometers, which should make for a really interesting platform for doing some dead reckoning hacking. I got about 28 hours of driving in this weekend - went to spokane for a driving school at Spokane Raceway Park - and got some really interesting data logs.

(2006/09/07) And again... not dead. I've been doing most of my hacking on gpsd. Among other things I've set up a semi-permanent test station. Another trip to Spokane was arranged, with about 1100km on the racetrack itself. I got my calibration utility for the accelerometers sorted, and wrote a datalogger to integrate gps output and accelerometer recordings. The calibrated accelerometers can also be run at 100Hz, at the cost of increased battery use and elevated interrupt rates. New code snapshot reflects some of this work.

(2006/09/12) The code for the test station has been updated - the latest source is also in the source snapshot. Thanks to Gary E. Miller for useful suggestions and prodding.

(2006/09/18) Apparently my rotting carcass of a NAV decoder wasn't a rotting carcass at all... it was just hibernating and needed a shower. I now have a decoder that parses SiRF messages 14 and 15 and have made some progress on message 8 - the raw NAV message. More about all that in my post to gpsd-dev...

(2006/10/12) Just got a Wintec WBT200 receiver - iTrax3 with the uNav chipset. This should be a good weekend.

(2006/11/08) Jeff Francis is running a gpsd server.

(2006/11/16) I got a pair of FV25 receivers, and found that my Trimble interface board is somewhere in the city. There are vendor photos below, and here's my hardware gallery. (top)

Hardware

Tools

I've got a little skunkworks project going on to provide a PERL interface to Garmin and SiRF GPS units. I may rewrite it in C later, and provide a PERL binding. Anyway, this module currently does a fairly decent job of decoding the Garmin and SiRF protocols, and provides some basic utilities. I aim to have a complete library for manipulating your GPS, with lots of error checking to avoid Hazardously Misleading Information, and some sample applications (like a time synchronization tool, a satellite plotter, etc.)

Both the Garmin and SiRF receivers can output NMEA, but that's fairly uninteresting to work with. Garmin proprietary protocol support is weak - I don't plan to do much more development with Garmin hardware unless a) someone gives me free hardware and b) more importantly, Garmin becomes a lot more forthcoming with their protocol documentation. SiRF support is fairly mature; I have decoders for all message types that I've seen during testing. There is now a routine to set speed and protocol (SiRFDemo calls it "Synchronize Speed/Protocol"). The snapshot is a bit unstable yet, but that's why it's a snapshot and not a release... Not long ago, I refactored a large part of the SiRF decoder, and added a few more decode types. RINEX or BINEX ouput would be really nice. For those interested, there is now a "GPS context" driven by the 50bps data stream allowing you to have something like a software GPS. Have a look at the %gps_ctx hash in the SiRF module. The kit contains (among other thing):

• An NMEA-based status application (requires the Curses, Device::SerialPort, GD and GTK PERL modules)
• Protocol Decoders/Prettyprinters: Garmin, NMEA, SiRF
• A tool to log SiRF binary packets into a database
• A tool to query logged SiRF packets from the database
• The database schema is now part of the cvs snapshot
• A tool to pretty-print the Garmin simple text protocol
• A tool to set your local clock to GPS time via the SiRF protocol
• A PERL Module to do all the protocol decodes, checksums, math, I/O, and other magic
• A PHP script to generate pretty pictures for the web if you have a gpsd server somewhere
  
• The beginnings of a C library to do all of the above too.
• Sparse documentation of the tools, API docs are forthcoming

Other GPS Data Processing Tools

• gpsd
• Garmin Async & RINEX tools
• Bob Lindell's Garmin for NTP page
• GPS module for PERL
• GPSDrive
• Microsoft Streets & Trips
• BSD Airtools (bsd-airtools-v0.3.tgz)
• GAMIT-GLOBK
• UNAVCO teqc
• UNAVCO binex
• GPStk Toolkit
• NGS Toolkit
• Kinematic
  

Links

• Google Scholar
• CiteSeer
• Navstar Global Positioning System Joint Program Office
• US Army GPS PM Page
• Navstar Constellation Status
• GPS Support Center
• National Imagery and Mapping Agency Status Page
• GPS Satellite Prediction Tools
• IERS Prediction Center
• GPS Test COE
• US Coast Guard Nav Center
• USCG Status Reporting
• GPS/GLONASS Observations
• National Geodetic Survey GPS Orbits
• Orbit Determination and Satellite Navigation
• Scripps Orbit and Permanent Array Center
• Institute of Navigation
• GPSinformation.net
• David L. Wilson's GPS Accuracy Web Page
• Sam Wormley's GPS Resources
• Norris Weimer's GPS page
• GPS Links (google cache)
• u-Blox
• SiRF
• GPS Central
• FRS142@princeton.edu
• EAS591@purdue.edu
• The Geographer's Craft - GPS
• UNB Geodesy and Geomatics
• GPS Solutions (journal)
• GPSWorld
• RINEX Specification
• Great Circle Calculator
• Matlab EASY GPS Suite
• Kalman Filters (1)
• Kalman Filters (2)
• Kalman Filters (3)
• Kalman Filters (4)
• Kalman Filters (5)
• Kalman Filters (6)
• Kalman Filters (7)
• Kalman Filters (8)
• Kalman Filter (9)
  
• Open Source GPS (1)
• Open Source GPS (2)
• Open Source GPS (3)
• Open Source GPS (4)
• Open Source UAV (1)
• Open Source UAV (2)
  
• Inertial Navigation Systems
• http://www.fourmilab.ch/earthview/satellite.html
• http://www.n2yo.com/
  
• http://plan.geomatics.ucalgary.ca/research.php
• http://www.navsys.com/Papers/
• http://www.ga.gov.au/geodesy/datums/distance.jsp
• http://www.movable-type.co.uk/scripts/GIS-FAQ-5.1.html
  

Good Reading

Other Stuff

• Civilian GPS units have this silly limit of 515m/s at 18000m (Item 11, 22CFR121.16 in case you were wondering). That's probably to make it difficult for people to build home brew cruise missiles or to discourage the use of a little hand-held unit in a high-dynamic environment. SiRF will remove the limit from their firmware if you ask nicely and get a permission slip from your Uncle Sam. Personally, I think that an unknown object moving 515m/s (mach 1.5, 1000kt, 1854km/h, 1152mph) at 18000m (11.19mi, 60000ft) would be lighting up everyone's EWS in a big way. Certainly that's a pretty crappy job of terrain-following, which is something cruise missiles are supposed to be good at. Just for reference, commercial airliners wander across the sky at a leisurely 243m/s (844km/h, 525mph) at something like 10500m (6.53mi, 35000ft). What's even sillier about that limit is that it's an AND condition: you can go faster than 515m/s just so long as you stay under 18000m, or you can get above 18000m, so long as you're not going more than 515m/s in the process. If 515m/s is evil, then 512m/s must be pretty darn naughty. *boggle*
• I saw some of my code posted on another tech forum, where someone was asking for help converting it to C. While the license certainly allows that sort of thing, you're more than welcome to just email me directly about my code.
• The US Army GPS product manager's office has a little zine called Pathfinder. They say it is "[an] informal newsletter published for the GPS user community by PM GPS. Information presented is based on published and submitted news items of interest to the general user. Widest dissemination and reproduction is encouraged." Thus far it's been possibly the most legible and interesting military documentation I've ever read.
• I hate the 50bps data stream. Sure, I can extract data from it, but I think I've been spoiled by my plush commodity computer gear with gigabytes of memory and terabytes of disk for a few thousand dollars. Still, haggling over a couple of bits seems pretty shortsighted. How can you tell I'm doing the 50bps data stream bit-banging in software. :(

GPS Observatory

A number of the gpsd developers have set up monitor stations (gritch.org, mainframe.cx, rellim.com); other gpsd users with static receivers are encouraged to set up receivers and let us know about them.

My plan is something like this: There will be sensors, database masters and analyzer slaves. The sensors will most likely be a PC with four TN200's. They will run a small daemon to put the receivers into 57600bps, switch to binary mode and turn on all output packet types. As packets are read, a minimal decode is done - checksum is validated and packet id is extracted - and then they are logged into the database as (time, receiver-id, packet-id, raw packet). Only authorized sensors will have write access to the database master. Database access "will be denied to unauthorized users by the use of cryptography." The database master then writes into a database slave. The database slave then becomes the distribution point for other researchers wishing access to our logs. Access will be provided by allowing a machine controlled by the researcher to become a 2nd tier slave. This allows the researchers to have a fast local data store without unduly burdening the core.

Over time, the database will grow very large. I think that on a weekly basis, dumps of the database will be done and made available for download and data older than eight days will be purged from the working database (today's logs plus the last seven full days). The schema will also be available so that a new analyzer can be bootstrapped quickly. It is my hope that monitor stations worldwide can be connected, and that current and historical data from each of these stations can be used for further development of GPS-enabled applications.

Measured I/O rate: Given that 1024bps = 10.55MB/day, ... (per sensor, typical case). Currently I'm logging ephemeris, almanac, clock data, navigation solutions, satellite views, measured tracker data, cpu utilization, 50Hz data, raw tracker data, and a few other things. Various vendors say that to use the full tracker and debug output, your serial interface needs to be running at 38400bps (4.7KB/s) or 57600bps (7.1KB/s).

• du -sk db/ = 272892KB
• du -sk db.tar = 272896KB
• du -sk db.tar.gz = 83552KB