Hack 60. Improve the Accuracy of Your GPS with Differential GPS
The GPS system is amazing, but here is a way to make it even better
Why does your GPS receiver give you an error reading, and why are the values it gives you often in tens of
? The accuracy of your signal depends not only on how many
you can see, but also the atmospheric interference between them in low earth
and you with your feet on the ground.
Satellite-based global positioning systems rely on the basic property of our universe that radio signals travel at a constant speed through a
. If we can estimate how long a GPS signal has taken to travel to our receiver from a satellite in orbit, we can multiply our time estimate by that constant speed to arrive at an estimate of how far away the satellite is. If we combine enough of these estimates, we can
at a pretty good idea of where we are on the planet's surface. So far, so accurate!
But this simple physics solution doesn't work so well in the real universe. GPS signals don't travel through a vacuum to reach us; they travel through Earth's atmosphere, and, in much the same way that sound waves travel at different speeds through air or water or other mediums, the radio signals from GPS satellites end up traveling at different speeds to reach Earth's surface. While certain
of the atmosphere have a predictably constant density that can be accounted for easily, others do not.
Our atmosphere, starting at about 60 km above sea level,
with solar and cosmic radiation to produce a layer of ionized particles that
the planet, known as the
. The electrically charged particles that make up the ionosphere are the cause of the Northern Lights, the beautiful aurorae that can be sometimes seen at extreme latitudes, but their charge and their widely variable density affects how easily high-frequency radio waves, such as GPS signals, can pass through them. This "ionospheric delay" can cause GPS errors of 10 meters or more. And changing conditions on Earth's surface can add another one or two meters of error to your GPS reading.
5.16.1. How Does GPS Error Correction Work?
There are a couple of ways of detecting and canceling out the effects of atmospheric delay. One solution is to use a receiver that listens for GPS signals on two different frequencies. Since ionospheric delay is
inversely proportional to signal frequency, a dual-frequency receiver can work out the relative delay for the same signal transmitted over the two different frequencies and then estimate the total delay.
This is the solution employed by military-grade receivers, but it comes at a price: each dual-frequency GPS receiver needs to have two antennas, two GPS radios, and so on, effectively doubling the cost of the receiver. Furthermore, the U.S. military, for obvious reasons, keeps the second NAVSTAR GPS signal encrypted. As a result, this option is basically out for ordinary civilian GPS users.
A second way of correcting atmospheric delay error is to place a second, stationary GPS receiver at an already well-surveyed location. Since we already know the exact longitude and latitude of this stationary receiver, we can calculate the effects of atmospheric delay and other errors on local GPS
quite accurately. If we broadcast this information over ground-based radio, nearby GPS receivers can listen for our estimates of local GPS error and correct their
. In fact, this is exactly what the U.S. Coast Guard doesand their GPS correction broadcasts can be pulled in with a suitable radio receiver listening in the 200-300 kHz range and fed to an ordinary consumer GPS unit.
This method of correcting atmospheric error is referred to as
, or DGPS, and it can bring GPS accuracy to within five meters or less! DGPS can even
errors caused by
, the U.S. government's
for the "fuzzing" of the civilian NAVSTAR GPS signals, which were formerly used to degrade GPS accuracy to hundreds, rather than dozens, of meters. Selective Availability was finally turned off in May 2000, but the U.S. government nominally
the right to
it back on at will.
There are still two main issues with using differential GPS, of course. The first is the relatively local nature of ionospheric conditions, which means that DGPS information is only really useful for navigation within about 500 km of the DGPS base station, and there's not really any way around that. The other issue is, again, cost. In order to pick up the free DGPS corrections broadcast by the U.S. Coast Guard, we need an expensive radio, tunable to the appropriate frequencies and equipped to provide correction data over a serial line to a GPS receiver.
Naturally, we can get around this second
to using differential GPS if we opt for an alternate medium for disseminating the data. This is the approach taken by DGPS-over-IP, a protocol for relaying DGPS corrections over the Internet. The dgpsip server, written by
S. Rupprecht, accepts incoming TCP connections and then simply takes the serial data output by his Garmin DBR-21 DGPS receiver near San Francisco, stuffs it into a TCP/IP packet, and sends it back out. The correction data is in RTCM SC-104 format, a protocol published by an industry
called the Radio Technical Commission for Maritime Services. Most consumer GPS equipment can be configured to accept RTCM DGPS corrections, so all a DGPS-over-IP client needs to do is assemble the SC-104 data on the receiving end and pipe it out to the GPS receiver over a serial port. The net effect of DGPS-over-IP is, in essence, to treat the Internet as an indefinitely long RS-232 extension cable!
5.16.2. Setting Up DGPS-over-IP on Linux
In order to use DGPS-over-IP, you'll need to get a suitable client. If you're running Debian Linux, you can simply run
. If you're running a different *NIX, you can get the latest source code tarball from http://www.wsrcc.com/wolfgang/ftp
. The file should be called
is the latest version (1.33, as of this writing). You can build and install it as
tar xvfz dgpsip-x.xx.tar.gz
Then, as root, run:
, you may want to
your serial port (usually,
for the first serial port, but it might be
, so that dgpsip
by default where to look:
ln -s ttyS0 /dev/gps
Finally, check your
file to make sure that port 2101 is registered for rtcm-sc104:
grep rtcm-sc104 /etc/services
rtcm-sc104 2101/tcp # RTCM SC-104 IANA 1/29/99
If the output of this command doesn't print anything out, you'll want to add the two
lines to your
file, so that the dgpsip client knows which port to use to talk with the server. (You can leave out the part of the line following the hash mark,
it's just a comment).
5.16.3. Setting up DGPS-over-IP on Windows
You can also get a DGPS-over-IP client for Windows from http://www.wsrcc.com/wolfgang/ftp/. Look for a file called
in that same directory and download and execute it. The file is a self-extracting ZIP archive that will install the Jdgpsip application on your system. You'll then need to configure your GPS receiver to accept RTCM data at 4800 baud, and,
, output NMEA data. This setting should be available in the setup menu on your receiver, but check your owner's manual for details. Then connect your GPS to your computer via the serial cable provided by your manufacturer. Make sure you know which serial port you've connected it tooften COM1 or COM2.
You'll want to try getting DGPS corrections somewhere where you can get a reasonably clear view of the sky. Indoor GPS reception tends to be weak, at best, due to the extremely low power of the satellite transmissions, so you may want to go outside. A laptop with Wi-Fi makes this enormously easier.
Make sure your computer is connected to the Internet and your GPS receiver is connected and
on. Wait until your GPS gets a satellite lock. If it doesn't get a lock, you may need to find another location with a better view of the sky. Note the accuracy that your GPS
5.16.4. Getting Better Differentials
Now, start up dgpsip (or Jdgpsip). The dgpsip client should connect to
on port 2101 by default. If you're running the *NIX version of dgpsip, you can start it as
to get periodic position and accuracy updates printed to your terminal. Regardless of which client you're using, if you're in Europe, you should try connecting to
instead, which is located in Rome.
Let the DGPS client run for a few minutes and check the accuracy
by your GPS. If you're more than a couple thousand kilometers away from San Francisco or Rome, you may not see much of an improvement. However, when we tried it from our home in San Francisco, our accuracy jumped from 12 meters to 4 meters in a matter of minutes!
Be aware that both the Windows and the *NIX versions will attempt to send your position data back to the dgpsip server. The
do this in order to allow the dgpsip server to collect statistics about how well it offers corrections in various locales. This may cause some privacy concerns, but the data is sent with an accuracy of about three or four kilometers. Obviously, at that level of granularity, it would be next to
to identify any individual DGPS-over-IP
, but we mention it for completeness's sake.
For many general purposes, the accuracy
by uncorrected GPS receivers is sufficient. Still, as you can see, differential GPS can offer a significant improvement in positioning accuracy,
if the United States government ever decides to turn Selective Availability back on. One potential use for this technology, for example, might be to hook it into a car navigation system and use a cellular uplink or
Wi-Fi connections to obtain DGPS corrections. Of course, it would work a lot better if more DGPS-over-IP servers were available in a wider variety of locationsa part of the vision
by Wolfgang Rupprecht on his DGPS-over-IP homepage. You can read more about it at http://www.wsrcc.com/wolfgang/gps/dgps-ip.html and at his GPS Hacks page at http://www.wsrcc.com/wolfgang/gps. Maybe you'll be inspired to provide your own DGPS-over-IP server or build your own DGPS