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)
(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
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/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
(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.USGlobalSat TN-200 , a USGlobalSat BU-353, a Pharos iGPS360, a Wintec WBT-200, a Trimble Lassen iQ, a San Jose FV-25 and an IBM T42 with onboard accelerometers. I had an eTrex but it was fairly annoying to hack at though - the lack of protocol documentation, the low speed interface, etc - and I decided it was time for a new unit more suited to being and staying connected to a computer. The TN-200 is pretty much ideal for my purposes due to the availability of chip set documentation and the fact that it uses the FTDI FT232B USB serial controller, supported by OpenBSD's uftdi driver. Other SiRF-based units use the Prolific PL2303 (uplcom) which is OK too. Both the TN-200 and the iGPS360 appear to be based on something like the USGlobalSat EM401 module.
A large part of my development effort is focused on gpsd; my hardware wishlist and the gpsd wishlist are one and the same. If you'd like to send me one of these devices, drop me a line.
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):
Download CVS snapshot (2006/09/20 2247h)
# time ./sirfdbget > /dev/null
SQL exec time: 116.431809
Decode time: 1467.228854
Packets Printed: 1552832
Run Time: 1583.660663
1180.007u 68.976s 26:25.56 78.7% 0+0k 88+19io 1pf+0w
That's pretty quick, considering I ran that on a 1GHz Pentium3 laptop with a 4200RPM disk
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
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).
|Chris Kuethe <firstname.lastname@example.org>||Updated: 2006/11/17 1939h|