Real-Time Single Difference GPS Positioning

Although the procedure as described in the Single Difference Positioning page is suited for real-time DGPS, it has, besides a number of distinct advantages one big disadvantage: the data volume.
At least 4 bytes are required to represent a pseudorange. Suppose the receiver tracks 12 SV's. The SV number (one byte) and pseudorange occupy in this case 60 bytes. Furthermore some overhead is required, say 20 bytes. Thus at least 80 bytes of reference data is generated , and at an update rate of once per second this is about 800 bit/sec. For real-time positioning a datalink with this capacity is needed.
Capacity on real-time datalinks is expensive, be it AM or FM radio, communication satellite link, wireless telephony or a dedicated datalink.
Moreover, if an 800 baud datalink were available, it would take one second before the ref data was received completely. And one second may be much in the case of high dynamic applications (such as aircraft).

Because of these reasons one has looked for ways to lower the burden on the datalink without (too much) loss of quality.

An obvious way is to reduce the amount of data by sending the pseudorange corrections in stead of the pseudoranges themselves: the data range of a correction might be - 200.0 m to + 200.0 m, which is 4000 units of 0.1 m or 12 bits, whereas a pseudorange (with the same resolution) could be in the order of 30,000,000.0 m or 300,000,000 units of 0.1 m, or 29 bits. Thus sending the correction reduces the number of bits from 29 to 12 for each pseudorange.

As always, there is a price to pay.

  1. The moving receiver must use the ephemeris parameter set with the same 'issue of data' time as is used at the reference for calculating the differential corrections.
  2. The moving receiver must know which range corrections have been applied at the reference receiver  and which not, in order not to correct certain errors twice.
  3. The inavailability of all raw data at the moving receiver limits the methods of processing and thus limits flexibility at the moving receiver.

A way to reduce the burden on the datalink even further is to predict the correction for a certain time interval, e.g. the next 10 seconds, in stead of giving the correction at a certain point of time. The prediction coefficients have to be relayed only once for this interval in stead of once every second. It has the added advantage, that the moving receiver doesn't have to wait for the correction to become available. It can apply the correction to the measured ranges without any delay, which is required for e.g. navigation.

Again, some disadvantages:

  1. The predicted correction will become less accurate the 'older' it is. This effect is enhanced by Selective Availability (S/A).
  2. The number of coefficients in the prediction model should be kept low in order to keep the datalink burden low, which may result in a suboptimal prediction model.

The popular RTCM-104 standard incorporated the above correction / reduction methods. It uses a linear prediction model for the pseudorange correction, i.e. a constant term and a first order term . Let's have a look at the type 1 correction message.

For each SV the scale factor (1 bit), an accuracy indicator (2 bit), SV prn (5 bits), pseudorange correction (16 bits), pseudorange-rate-of-change correction (8 bits), the ephemeris issue of data (8 bits) and parity (6 bits) are relayed, together 46 bits. The header of any RTCM-104 message contains 60 bits (message ID, reference station ID, message time, and some other quantities), thus the total message length with 12 SV's tracking will be 60 + 12*46 = 612 bits or close to 80 bytes. In comparison with the  minimum number of bytes required to relay raw pseudoranges no reduction.

Its advantage lies in the fact that the RTCM-104 correction degrades slowly in time resulting in a position error of less than 4 m with a 20 second old correction, even under high S/A conditions. As a result the 80 bytes can be spread over 20 seconds, and a very low capacity datalink can meet this requirement.

The RTCM-104 standard is very succesfull, and is used worldwide. Most (if not all) popular GPS receivers accept RTCM-104 differential correction messages. If there is an RTCM-104 correction station close to you: use it, in most cases it's free. If you want to set-up your own differential correction station, use a receiver at the reference station which can generate RTCM-104 correction messages (see the OEM table for examples). Only if your requirements are not met by the RTCM-104 standard, or if you are the idiot who likes to make his/hers hands wet (let's shake hands :-) ), continue reading.

Do it your self real time DGPS

In the example I work with the full pseudoranges (and integrated carrier phases) in order to keep h/w cost down, and to allow maximum flexibility at the moving receiver. Furthermore, I assume you have a 'transparent', one-way RS232 datalink, i.e. RS232 data in at the reference receiver and exactly the same data out at the moving receiver, without any flow control visible to the user. Finally, I assume the availability of receivers which keep their internal clock sync'd to GPS time within 1 msec (a class 1 or a class 2 receiver).

At the reference station the following setup is chosen:

  1. The reference receiver is set up to output pseudoranges and integrated carrier phases once per second - no more data is required. Most receivers retain their setup in non volatile memory once they have been programmed, some loose the setup after a power cycle. In the latter case the reference receiver has to be set up each time after switching on.
  2. The output of the reference receiver is directly connected to the datalink transmitter input.

At the moving receiver the setup looks as follows:

  1. The moving receiver is connected to a serial communications port of a PC, the datalink receiver is connected to a second port of the PC.
  2. The moving receiver is set up to output pseudoranges an integrated carrier phases once per second, and satellite ephemeris data once per minute and/ or after a 'fresh' set of ephemeris data has been collected by the moving receiver (depending on your receiver's capabilities).
  3. The reference position is entered in the PC directly after power up.

The moving PC has to execute the following tasks:

  1. Wait for the next observations output of the moving receiver (a real time task).
  2. Read receiver time and observations, smooth pseudoranges.
  3. Wait for the next observations output of the reference receiver by the datalink (again, a real time task).
  4. Check if moving receiver time equals reference receiver time.
  5. Extrapolate observations to one common point in time.
  6. Calculate position.
  7. Pray, that your PC is powerful enough to handle the tasks well within one second. Go back to step 1.

The moving processor has to exercise one additional, lower priority task: the update of ephemeris data. Each time the moving receiver outputs new ephemeris data, this data should overwrite the buffered old ephemeris data. Read the data in such a way that no loss occurs. Process the data (conversion to engineering units) in the processor spare time between step 6 and the next step 1.

What are the advantages of the above method ?

The disadvantages are:

The example Turbo Pascal code is still under construction, but some general remarks apply.

For readability and ease of re-use, I made the Turbo Pascal library GPSproc with the required procedures and functions. In order to run the example you should download the library and make a run-time version.

In the example you will find many pieces of code which have been produced for earlier examples. The new things are: incorporation of real-time aspects, and communication with serial i/o ports (RS-232). For serial i/o I use PCL4P, a library with serial i/o procedures that WORK. Download this shareware and make a run-time version in order to run the example.

The TAPR recently released their DGPS reference station kit.


Back to s/w index
This page was last updated on 6 April 1998.