Differential GPS with the UBlox LEA-6H
When trying to build an autonomous car to compete in the Sparkfun AVC, it really helps to have a very accurate GPS module. Unfortunately, consumer-level GPS units are only accurate to about 2.5 meters CEP, which is marginal for building a ground-based autonomous robot. It's possible to buy GPS receivers that are accurate down to the centimeter level, but these units are very expensive. One reason for the greater cost is that these units can receive GPS signal on an additional channel called the L2 channel (consumer units receive only the L1 channel.) Being able to receive GPS timing signals on two different frequency bands means that the receiver can calculate how to compensate for distortion of the GPS signals caused by propagaiton through the Earth's ionosphere. This distortion is analogous to the way stars appear to twinkle on and off due to refraction of light in heated layers in the atmosphere.
Another way to correct for this distortion is to subscribe to a service that provides "correction" data to the GPS receiver. Most GPS receivers already include a free version of this kind of correction service made possible by the FAA. This service is called WAAS, which is a type of satellite-based augmentation system (SBAS) that sends out correction data from a set of geosynchronous satellites using the same L1 frequency band (Note: even though these satellites are parked in fixed, geosynchronous orbits they can also broadcast a navigation signal and can be used to compute position, too.) However, due to the dependence on geosynchronous satellites, the WAAS service is only usable from locations that can see these sats, but the improvement in the GPS position fix from using WAAS correction data is often not that great. Part of this is due to the fact that the WAAS satellites appear low on the horizon due to their positioning above the Earth's equator, which can result in the signal being blocked by mountains, tree, or buildings, depending on the local environment. It can also take as long as 20 minutes for a GPS receiver to get a lock on a WAAS satellite and begin receiving correction data from it.
However, another reason why WAAS corrections are often not that useful stems from the way the corrections are computed. In true differential GPS, a receiver in a known, fixed location continuously monitors the GPS signals from all visible satellites. Since it's in a fixed, unmoving position, the signals it gets from the GPS satellites should match an exact mathematical model of how the GPS satellite move relative to each other. In effect, the fixed receiver can compute the exact range at which it should see each satellite in the sky. Any deviation from this prediction means that the signal has been distorted due to varying ionospheric delay. So, if this fixed receiver sends these "error" adjustments to a nearby "roving" receiver, the rover can use these adjustments to correct its one calculations and get a better fix on its location. This system works best if the fixed station is close to where the roving receiver is located, as accuracy degrades as the two move further apart.
However, rather than trying to build a nationwide grid of fixed, GPS reference stations, the current WAAS system uses a mathematical model of the ionosphere to compute interpolated corrections from a much coarser grid of reference stations. Sometimes his works well, but other times it does not. So, are there any other options for making this work? It turns out that some commercial GPS receivers, such as the UBlox LEA-6H can read correction data from alternates sources. This data is in a format of digital messages defined by the Radio Technical Commission for Maritime Services, or RTCM. The format of these messages has evolved over time, but the LEA-6H is able to use an older version called RTCM 2.0 to receive GPS correction data. More modern message types, such as RTCM 2.3 and RTCM 3.x can be used by advanced, dual frequency receivers to get a position fix down to centimeter-level accuracy, but the LEA-6H is unable to directly use these message types. So, where can one get a source of RTCM 2.0 correction data?
Meet B.O.B.
The US Coast Guard (now under the Dept. of Homeland Security) maintains and operates a system of "beacons" that broadcast RTCM 2.0 correction messages using low speed (100 bps), low frequency (283.5 to 325 kHz) transmitters. This system dates back to the days when "selective availability" was used to deliberately degrade the accuracy of civilian GPS systems (deactivated by Presidential order in May 1. 2000 , but the system of DGPS beacons is sill largely intact and functional. I'm not sure if the equipment needed to receive the signals these beacons broadcast is still commercially sold, but it is possible to purchase surplus DGPS receivers on eBay for relatively low cost. Once such unit is called the "Beacon on a Belt" and was sold by Trimble Navigation. I was able to purchase a "BoB" for less than $50. Here's a photo if the unit I received:
Click for larger view
At 2.56 pounds, I can't imagine a scenario where I'd want to wear "BoB" on my belt, but perhaps that was just marketing talk. In any case, the Bob is a very sturdily built unit, having a body that appears to be made of cast aluminum with a "head" made of PVC plastic that feels as thinks at that used for molding plumbing fixtures. The controls are very simple, consisting of a power button and a button that can be used to select which DGPS beacon the unit receives signals from. However, if simply powered on, a Bob will try to automatically acquire the signal of the closest beacon and then outputs RTCM 2.0 data at 2400 bps via a 9 pin, RS-232 connector located on the bottom of the receiver (which makes it difficult to connect a cable and still stand the unit on a table; hence the special, cardboard box with a cut out used as a "base" that you can see in the photo above.) Note: the Bob is power from an internal battery, but mine did not come with a charger. However, by opening the unit, I was able to determine which two pins take power and learned from the Bob User Manual, that it requires 12 volts at 1 Amp to charge. So, I improvised a makeshift charger by poking leads from my bench power supply into the appropriate connector pins (I marked the (+) pin on the outside of the base for future reference.)
The data BoB spits out via its 2400 bps port is encoded in a format that could only have been devised by a committee, as it's one of the most ungainly binary formats I've ever seen. Unfortunately, the specification for this format is only available in a document you must purchase from the Radio Technical Commission for Maritime Services, or course. Being a cheapskate, I declined to pay good money for an obsolete spec, but I was able to piece together an understanding of the format from several sources freely available on the internet. Here's a short list:
While it did little more than satisfy my curiosity, I did manage to write some Java software that decodes the various RTCM 2.0 message types and displays them in a format readable by humans. Here's a dump of data that's been decoded from my Bob as it receives RTCM 2.0 messages from a beacon station located on Point Loma near San Diego:
Type: 9, Station: 263 - length: 5, numSeq: 3, working: 3
satNum: 25 dRange: 1.66 dSpeed: .000 age: 72
satNum: 29 dRange: -.72 dSpeed: .000 age: 89
satNum: 31 dRange: -7.16 dSpeed: .000 age: 75
Type: 59, Station: 263 - length: 3, numSeq: 4, working: 3
0x55138A06, 0x40694022, 0x62379B49
Type: 6, Station: 263 - length: 1, numSeq: 5, working: 0
0x55555569
Type: 9, Station: 263 - length: 5, numSeq: 6, working: 3
satNum: 2 dRange: -.24 dSpeed: .000 age: 45
satNum: 5 dRange: .68 dSpeed: .000 age: 31
satNum: 10 dRange: 653.94 dSpeed: .000 age: 61
Type: 59, Station: 263 - length: 3, numSeq: 7, working: 3
0x55138A10, 0x4069400B, 0x62389B55
Type: 6, Station: 263 - length: 1, numSeq: 0, working: 0
0x55555569
Type: 59, Station: 263 - length: 2, numSeq: 1, working: 0
0x55138A06, 0x40894032
Type: 9, Station: 263 - length: 5, numSeq: 2, working: 3
satNum: 12 dRange: 1.50 dSpeed: .000 age: 76
satNum: 25 dRange: 1.66 dSpeed: .000 age: 72
satNum: 29 dRange: -.70 dSpeed: .000 age: 89
Type: 59, Station: 263 - length: 3, numSeq: 3, working: 3
0x55138A10, 0x4069400B, 0x62381B4A
Type: 9, Station: 263 - length: 5, numSeq: 4, working: 3
satNum: 31 dRange: -17.36 dSpeed: .000 age: 75
satNum: 2 dRange: -.26 dSpeed: .000 age: 45
satNum: 5 dRange: -654.68 dSpeed: .000 age: 31
Type: 59, Station: 263 - length: 3, numSeq: 5, working: 3
0x55138A39, 0x41200C13, 0x4F000000
Type: 9, Station: 263 - length: 5, numSeq: 6, working: 3
satNum: 10 dRange: -6.52 dSpeed: .000 age: 61
satNum: 12 dRange: 1.52 dSpeed: .000 age: 76
satNum: 25 dRange: -653.70 dSpeed: .000 age: 72
As you can see, my software only fully decodes message type 9 (see if you can work out what the other messages mean using the references listed above), but this is workhorse message of the RTCM 2.0 format. BTW, the "station" field shown in each message is the designator of the Point Loma station near San Diego that I'm able to receive. As you can also see, it takes a series of type 9 messages to transmit correction data for each of the GOS satellites currently visible to the DGPS beacon station's GPS receiver. At 100 bps (the actual rate the receiver operates at), it takes several seconds to receive a full set of corrections, but this is sufficient, as ionospheric conditions don't usually change all that often.