When GPS first became available to consumers, it was heralded as the beginning of a new age of navigation. And it was. For the first time anyone could fine out where they where, anywhere on the planet -- give or take about 80 meters.
The military's was better and far more accurate while the consumer version was intentionally degraded by way of a GPS system mode, selective availability (SA). There were (probably) good reasons for this from the military perspective, but for mariners in bad weather, plus or minus 80 meters can mean the difference between safely pulling into the harbor or taking off the keel.
To deal with this inaccuracy, several groups developed and deployed Differential GPS (DGPS). DGPS works by having GPS receivers at stationary, known locations, near to where accurate position determination is desired. These stations broadcast the range errors they're seeing from each and every GPS satellite. Normally the transmission is by way of radio beacons, but geostationary satellites and the Internet are also commonly used.
Plot of test data used during development of PgDGPS for sanity checking.
Nearby DGPS receivers can use these correction messages, correlated with the satellite signals they're receiving, to give as good as between 10 to 2 meter accuracy. The exact accuracy attained is a function of distance from the DGPS stations, and how rapidly the stations broadcast their data. If more than one station's data is used, and each is transmitting updates fast enough, sub-meter accuracy is possible. Many DGPS stations intentionally transmit slowly to limit accuracy.
One of the key early participants in DGPS development was the US Coast Guard, with initial operations beginning in early 1996. Today, DGPS stations have been installed around most US waterways, as well as in Canada, several European countries, and Australia. Deployment inland is currently under way to allow DGPS to be used for air traffic.
DGPS was one of the reasons SA was turned off on May 1st, 2000. With DGPS available almost everywhere with any population, SA was pointless. While costing two to three times as much as a regular GPS receiver, DGPS provides military accuracy for anyone who wants it.
Even with SA disabled, DGPS has a role. Civilian GPS only has a single frequency to lock onto, and thus the (varying) delay caused by the ionosphere continues to introduce a 5 meter uncertainty. Also, the satellites are still not entirely truthful, so DGPS is currently the best means of inexpensive, high-accuracy positioning, sometimes providing results better than military grade GPS.
Two generations; a Garmin GPS 12, in purple, and an eTrex Summit, in yellow. Anyone see any point in correlating these data?
Based on the mechanics of the DGPS system, if you have two GPS receivers, you can rig your own DGPS system. The theory is that one of the receivers serves as the base station at a known, fixed location. Then it provides the GPS position error information to a second GPS unit as it roves around. This might be done with a radio link for real-time position processing or simply log the NMEA data from each receiver for post-processing.
Unfortunately, it doesn't work -- at least most of the time.
The biggest problem is that consumer GPS receivers don't expose the pseudo range information needed to do individual satellite comparisons. The NMEA standard (see related articles) gives the current position (or "fix"), the list of satellites used for the fix calculation, plus some very basic (and effectively useless) information consisting of each satellite's position vector relative to the receiver, and the signal strength being seen from each.
Two identical, stationary eTrex Summit units, 50 cm apart. Sky coverage was also identical.
The kicker is that each satellite introduces its own unique, but unpredictable error to the fix calculation, which the NMEA standard has no way of expressing. Unless the base station and rover receivers are each calculating their positions from the exact same set of satellites, the fixes cannot be reliably compared. Because of the ever changing Signal to Noise Ratio (SNR), which can vary centimeter by centimeter, even identical satellite sets usually do not result in the same fix.
Also, each manufacturer has their own proprietary algorithms that choose which satellites to use and how to combine additional channels for a better fix. Even under identical conditions, two GPS units from different suppliers will exhibit different "wanders".
But... it gets even worse!
As manufacturers improve their designs and release new models or versions of GPS receivers, their characteristics can change. Even different versions of the firmware running on identical GPS receivers can effect the fix results. The plot above comparing the output of a Garmin 12 with an eTrex Summit shows how much better modern receivers are at determining position, but it also shows that comparing the fixes from different models is pointless.
Because of all this, it's actually possible to increase the error in the data derived using this technique. It's like that old joke about time: With a watch you know what time it is; with two you aren't so sure!
PgDGPS plot of two eTrex Summit units with good coverage. Note the change in the purple ground track compaired to the image above.
By altering our OpenGL GPSplot program from the last installment, we can process the data presented by two or more GPS units and view the results. The new program, PgDGPS, is almost identical to GPSplot, except it assumes that the first file passed on the command line is the base station's feed, and subtracts the position from any other files which are passed, thus treating them as rover receivers.
In the previous section there's an image, generated using GPSplot, of two identical, stationary Garmin eTrex Summit receivers sitting 50 cm apart, both with version 2.07 of the firmware. On the right is the result of plotting this data using PgDGPS. Note the current correction being applied is drawn using three line sigments, each along a unique axis. As you can see, the results aren't too bad, and we see approximately a 10% improvement in overall position accuracy.
Of course, these are optimal conditions -- rarely will you have the two units so close together, with identical sky views. The base station may and should have such coverage. But the rover receivers are likely going to be roving, thus encountering different sky views, SNR and echo conditions.
And yet, in our perfect setup, additional error has still been introduced. Examine the changes made to the second, purple ground track (in the upper right-hand section) compared to the image above. The longitude error has been improved -- the track doesn't wander quite so far right or east. But, at the same time, the latitude wander has increased! It now wanders too far north.
Rover receiver moved to have partially obscured sky view. PgDGPS plot of two eTrex Summit units with good coverage. PgDPGS results in no worthwhile improvement.
To simulate different reception quality between the units, the rover receiver was moved so it only had partial sky coverage. It was still stationary and within 10 meters of the base receiver. As you can see from the PgDGPS plot to the right, when the units have different sky views, the correlation between their fixes becomes less reliable. The overall accuracy improvement was less than 1%, statistically irrelevant.
When you get right down to it, trying to implement DGPS with consumer level receivers and the NMEA data stream is like trying to remove white noise from a signal by subtracting another source of white noise. While it might work sometimes, it usually doesn't, and there's no way to know if the results are reliable or not.
The simple, sad reality is that without pseudo range estimates being provided for each and every satellite individually, DGPS cannot be implemented. If you really need the kind of accuracy DGPS provides, you'd better purchase a real DGPS-enabled GPS receiver. Or, if you're designing a custom system, make sure the embedded GPS receiver you specify provides the range data needed.
Why go to so much effort to show that and why something doesn't work? There were a couple of motivations.
First, the idea of attempting to use home-grown DGPS keeps cropping up again and again when people first start working with GPS receivers. Because this approach appears to help with accuracy for periods of time, some are fooled into thinking it's reliable. It isn't.
The second reason has to do with the coming wave of embedded solutions that have GPS receivers built-in. As long as GPS has the inherent inaccuracy that we see today, device programmers must be aware of its limitations and the differences induced by variations in supplier and firmware before they start comparing GPS provided positions.
This non-comparibility of fine-resolution position data will be important to consider for mobile devices with wireless networking. Devices may be able to determine they're in close proximity, but the exact physical relationship between the devices may not be discernible via the GPS signals.
An example might be a row of cars parked in a parking lot. Their onboard computers establish a micronet for mutual physical security. GPS, as is, will not be able to determine the physical order of the cars, so they'll need to figure this out using their on-board cameras or sonar/IR proximity detectors: in short, "Don't worry about this human, folks; it's my owner."
Hopefully, embedded developers will start insisting on the range data being provided, so more advanced GPS modules have a chance to leverage mass markets and decrease in price. There's no reason why a wide-area DGPS network couldn't be established dynamically with the marriage of wireless networking and GPS receivers, providing this data was available.
While GPS is an amazing technology, it's not perfect. To paraphrase Clint Eastwood -- A geek has got to know the limitations.
Chris Halsall is the Managing Director of Ideas 4 Lease (Barbados). Chris is a specialist... at automating information gathering and presentation systems.
Where Are You, Exactly? A GPS Introduction
GPS, Palm Pilot, OpenGL ... Let's Go!
Discuss this article in the O'Reilly Network Wireless Forum.
Return to the Wireless DevCenter.
Copyright © 2009 O'Reilly Media, Inc.