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 meters? The accuracy of your signal depends not only on how many satellites you can see, but also the atmospheric interference between them in low earth orbit 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 vacuum. 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 arrive 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 parts 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, interacts with solar and cosmic radiation to produce a layer of ionized particles that surrounds the planet, known as the ionosphere. 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 roughly 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 reception 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 readings accordingly. 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 differential GPS, or DGPS, and it can bring GPS accuracy to within five meters or less! DGPS can even overcome the deliberate errors caused by Selective Availability, the U.S. government's term 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 reserves the right to turn 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 obstacle 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 Wolfgang 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 group 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 apt-get install dgpsip. 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 dgpsip-x.xx.tar.gz, where x.xx is the latest version (1.33, as of this writing). You can build and install it as follows:
$ tar xvfz dgpsip-x.xx.tar.gz $ cd dgpsip-x.xx $ ./configure $ make
Then, as root, run:
$ make install
Next, you may want to symlink your serial port (usually, /dev/ttyS0 for the first serial port, but it might be /dev/ttyS1) to /dev/gps, so that dgpsip knows by default where to look:
$ ln -s ttyS0 /dev/gps
Finally, check your /etc/services 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 rtcm-sc104 2101/udp
If the output of this command doesn't print anything out, you'll want to add the two rtcm lines to your /etc/services 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 Jdgpsip1.01.exe 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, ideally, 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 powered 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 reports.
5.16.4. Getting Better Differentials
Now, start up dgpsip (or Jdgpsip). The dgpsip client should connect to dgps.wsrcc.com on port 2101 by default. If you're running the *NIX version of dgpsip, you can start it as dgpsip -v2 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 gnssip.ing.uniroma1.it instead, which is located in Rome.
Let the DGPS client run for a few minutes and check the accuracy reported 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 clients 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 impossible to identify any individual DGPS-over-IP user, but we mention it for completeness's sake.
For many general purposes, the accuracy offered by uncorrected GPS receivers is sufficient. Still, as you can see, differential GPS can offer a significant improvement in positioning accuracy, especially 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 opportunistic 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 articulated 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 backpack.