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.
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:
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:
At the moving receiver the setup looks as follows:
The moving PC has to execute the following tasks:
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.