Embedded Files
Many people are familiar with the Wide Area Augmentation System (WAAS), which is an air navigation aid developed by the Federal Aviation Administration. WAAS is actually a type of Satellite-Based Augmentation System (SBAS), which is a system that supports wide-area or regional augmentation through the use of additional satellite-broadcast messages. Consumer-grade GPS systems suffer from various kinds of inaccuracies resulting delays in the ionosphere that skew the measurements used to compute the GPS receiver's position relative to the GPS constellation. WAAS helps to offset these errors by broadcasting correction data via a special set of satellites parked in geosynchronous orbit which consumer GPS receivers are also able to receive.
However, there is an older system developed by the United States Coast Guard (USCG), which also broadcasts correction messages via low bandwidth transmitters. Originally intended for marine use, this system was expanded into a nationwide network of 85 stations to include coverage throughout the lower 48 states. Correction data from this system is broadcast in a format named after the Radio Technical Commission for Maritime Services (RTCM), which is the international standards organization that developed it. The data format is called RTCM SC-104 and consists of a very convoluted binary protocol that's capable of carry many different types of "messages." Over time, new message types have been added to support increased accuracy using a technique called Real Time Kinematics (RTK). The original format, often called RTCM 2.0, supports the following set of message types:
Differential GPS corrections (pseudorange and velocity, max. 12 satellites)
Pseudorange corrections, referring to previous orbit data records (max. 12 satellites)
Reference station coordinates (ECEF X,Y,Z)
These messages implement a type of differential GPS correction based on adjusting the "pseudo range" measurements used by the GPS receiver to compute it's position in space. The station broadcasting the correction messages (DGPS beacon) is located in a fixed position, so any delays it sees in the signals it receives from the different GPS satellites must be due to signal delays in the ionosphere. So, it computes the amount of the delay for each satellite and broadcasts this as a set of correction messages. The receiving station is assumed to be relatively close in position to the beacon station so the signals it receives should have followed a similar path through the ionosphere. Therefore, the receiver can then simply subtract the corrections from the measurements it makes to arrive at a better position fix that adjusts for these errors.
The closest DGPS beacon station near me is located on Point Loma near San Diego, CA. The following photo shows the system components at that station. The large mast near the center of the photo is the beacon broadcast tower. The two smaller masts each contain two hemispherical domes spaced a few feet apart. Each dome is a survey-grade GPS antenna. One GPS antenna on each tower is the reference antenna and the other is used as an integrity monitor to check the reference antenna. In addition, each small mast contains another antenna that receives the beacon broadcast which is used to check the broadcast from the beacon mast.
Click for larger view
In reading about the uBlox series of GPS receivers, I noticed that they supported using RTCM 2.0 format correction messages and I wondered if using these messages could improve the accuracy of a position fix over WAAS. Commercial GPS receivers all now support the more accurate RTCM 2.3, 3.0 and 3.1 formats, which enable the receiver to perform RTK corrections down to the centimeter range for accuracy. However, these receivers are expensive and are designed to connect to either another GOS receiver acting as a base station and broadcasting correction messages, or to Internet-based connection stations using a protocol called NTRIP. I was curious to know where I could find a source of RTCM 2.0-format messages that would work with the uBox modules.
Meet BoB, Your Friendly DGPS Beacon Receiver
The network of beacon stations maintained by the USCG broadcast on Medium Frequency (MF) band from 283.5 to 325 kHz using a modulation technique called Minimum Shift-Keying (MSK) over a set of channels spaced 500 Hz apart. This means it requires a rather specialized receiver to tune in and demodulate these broadcasts. So, I went trolling on eBay to see what I could find. After some research, I purchased an odd-looking device called "BoB" for "Beacon on a Belt" that was made by Trimble. At 2.5+ lbs, I'm not sure how comfortable it would be to wear attached to my belt, but Trimble seemed to design the device to be used in this way. As the following pictures show, the BoB unit is a rather simple device. The front contains two buttons. Press and hold the lower button to turn power on, or off. The top button is used to select channels manually, but I let the unit auto select the closest beacon station.
Click for larger view
The bottom of the unit contains a 9 pin RS-232 connector and some type of Trimble-proprietary power connector. Trimble seems to love using obscure, and undocumented connectors on its devices and I was unable to find the matching power connector. However, by removing the case, I was able to determine that only two pins are used and noted the (+) polarity on the bottom so I could use my bench top power supply to change it. After locating a manual for BoB online, I determined that the power connector expected 12 volts DC, so this is how I charged my unit.
Click for larger view
I then used a USB to RS-232 adapter and a null modem adapter to connect BoB to my Mac Pro in order to do some analysis of the data coming out of the unit which, according to the manual is sent at 2400 baud with 8 data bits, 1 stop bit and no parity. Note: as of this writing (2/1/2015), Trimble still makes available a Windows PC application that support BoB, but it's primary purpose is to allow you to see a list of other, nearby beacon stations and to select which now you want BoB to use. You can read more about this in the BoB manual which is available at the link mentioned above.
Click for larger view
As mentioned above, the correction data output by the Bob unit is in a very convoluted binary protocol (designed by committee, I suspect) that took me some time to unravel and decode. Part of the problem is that the official documentation for the protocol is behind a paywall and costs several hundred dollars to order. However, I was able to piece together a decent description of the protocol from some scattered documents I found on the Internet. The basic idea behind the RTCM SC-104 is that 30 bit words are packed into a set of five, 8 bit serial characters, where the LS 6 bits of each character holds 6 bits of the 30 bit word and the MS 2 bits of each character are set to 01. The decoder also needs to use a sliding window technique to find the proper word boundary for the 5 characters. Then, each word undergoes a parity check which requires some tedious exclusive OR operations. For example, here's the code for the set of methods I use to rearrange the incoming 8 bit characters into 30 bit words and compute parity:
private static int b (int word, int b) {
int ii = (word >> (29-b)) & 1;
return(ii);
}
public static int getWord (int lp, byte[] data, int idx) {
int p29 = (lp >> 1) & 1;
int p30 = lp & 1;
int w = 0;
for (int ii = 0; ii < 5; ii++ ){
w = ((w << 6) + flip[data[idx + ii] & 0x3F]);
}
w = p30 != 0 ? w ^ 0x3FFFFFC0 : w;
int d25 = p29 ^ b(w,0) ^ b(w,1) ^ b(w,2) ^
b(w,4) ^ b(w,5) ^ b(w,9) ^ b(w,10) ^
b(w,11) ^ b(w,12) ^ b(w,13) ^ b(w,16) ^
b(w,17) ^ b(w,19) ^ b(w,22);
int d26 = p30 ^ b(w,1) ^ b(w,2) ^ b(w,3) ^
b(w,5) ^ b(w,6) ^ b(w,10) ^ b(w,11) ^
b(w,12) ^ b(w,13) ^ b(w,14) ^ b(w,17) ^
b(w,18) ^ b(w,20) ^ b(w,23);
int d27 = p29 ^ b(w,0) ^ b(w,2) ^ b(w,3) ^
b(w,4) ^ b(w,6) ^ b(w,7) ^ b(w,11) ^
b(w,12) ^ b(w,13) ^ b(w,14) ^ b(w,15) ^
b(w,18) ^ b(w,19) ^ b(w,21);
int d28 = p30 ^ b(w,1) ^ b(w,3) ^ b(w,4) ^
b(w,5) ^ b(w,7) ^ b(w,8) ^ b(w,12) ^
b(w,13) ^ b(w,14) ^ b(w,15) ^ b(w,16) ^
b(w,19) ^ b(w,20) ^ b(w,22);
int d29 = p30 ^ b(w,0) ^ b(w,2) ^ b(w,4) ^
b(w,5) ^ b(w,6) ^ b(w,8) ^ b(w,9) ^
b(w,13) ^ b(w,14) ^ b(w,15) ^ b(w,16) ^
b(w,17) ^ b(w,20) ^ b(w,21) ^ b(w,23);
int d30 = p29 ^ b(w,2) ^ b(w,4) ^ b(w,5) ^
b(w,7) ^ b(w,8) ^ b(w,9) ^ b(w,10) ^
b(w,12) ^ b(w,14) ^ b(w,18) ^ b(w,21) ^
b(w,22) ^ b(w,23);
int parity = (((((((((d25 << 1) + d26) << 1) + d27) << 1) + d28) << 1) + d29) << 1) + d30;
if ((w & 0x3F) == parity)
w |= 0x40000000;
return w;
}
I won't attempt to describe how it works in any detail, but I've attached a copy of a Java program named BobWordReader.java to the bottom of this page that you can study. This code does all the decoding steps to unpack the RAW BoB character stream into a series of 30 bit words which it then prints to the console in hexadecimal format. Since you probably don't own a BoB unit, the code is intended most to explain the word decoding process. I've also attached a file called "30 Bit Words.txt" which is the output from this program. If you want to learn more, use the documents linked below as a reference and try to further decode these words into the appropriate RTCM 2.0 messages.
Teaching UBloxSatMap to Parse RTCM 2.0
In a previous article, Decimeter Precision GPS, I described a custom Java program, UBloxSatMap which I wrote to allow me to control and experiment with the uBlox LEA-6T module and RAW data. To support my experiments with BoB, I expanded UBloxSatMap to include code to parse and display data from many of the RTCM 2.0 messages, as well as code to pass the RTCM messages thru to any uBlox module, as nearly all of the recent models now support reading these messages. The first addition to UBloxSatMap was a new pane that displays the decoded messages in a scrolling text box as well as a series of fields that track the latest values from each of the different broadcast types. Here's what this display pane looks like after the program has been parsing data for about 30 minutes (some RTCM 2.0 message, such as the ones that identify the beacon stations, are broadcast very infrequently):
Click for larger view
The top section of the pane labelled "Station Location" shows information about the beacon station that BoB is currently receiving. You can see the station id is #263 which, if you remember that the POInt Loma station has two GPS antennas, identifies that the RTCM information is coming the "B" GPS antenna. Here the station info from the official USCG site that provides status information for all the operational DGPS beacon stations
I eventually plan to publish this code but, at the moment, the serial I/O code used to connect to the uBlox modules and to the BoB unit are coded in a way that makes my code not very portable. In the meantime, I'll simply describe the results I've gotten so far in using the RTCM data from BoB to correct real time fixes in uBlox receiver modules.
Page updated
Google Sites
Report abuse