Home
News
Downloads
Mailing lists
Documentation
FAQ
Screenshots
Recipes
Other GPSDs
Hardware
For GPS Vendors
Wish List
Hall of Shame
Troubleshooting Guide
Hacker's Guide
Application Compatibility References
History
Future
This is a gentle introduction to writing GPS-aware applications
— or, How I Stopped Worrying And Learned To Love Spherical
Trigonometry. It will explain the capabilities and limitations of GPS
hardware and the gpsd software that you need to know about when
writing location-aware applications.
We'll go from general to specific, beginning with an overview of how
GPS works and ending with architectural suggestions about how to use
gpsd to make your application location-aware.
First, the basics of how GPS works. It depends on the fact that satellite orbits are very predictable. A GPS sensor is a specialized computer that knows about the orbits of GPS satellites, and in particular can predict exactly where each satellite will be at any given time with respect to the fixed Earth. (For those of you who enjoy such details, what they actually predict is each satellite's position with respect to an imaginary ellipsoid called the "WGS 84 geoid" which closely fits the mean sea level of Earth.)
There are presently 28 dedicated GPS satellites, 11,000 miles up in high-inclination orbits so that each one's trajectory wraps around the Earth like a ball of yarn as the planet spins beneath them. The inclinations are tuned to guarantee that about twelve will be visible at any given time from anywhere on Earth (coverage falls off a little at high latitudes). Additional GPS coverage is provided by a couple of maritime navigation satellites parked in geosynchronous orbits over the middle of the Atlantic and Pacific oceans.
You can look at a very nifty simulation of GPS satellite orbits. (Also includes GLONASS, the Russian military equivalent of GPS.) You can also look at pictures of GPS satellites and the control system.
Each satellite broadcasts identification pulses, each one including the clock time it was sent. A GPS receiver, picking up one of these pulses, can compare it to an internal clock and know the time it took to arrive. Multiplying by light speed gives the distance to the satellite. This starts to be useful when the GPS can get accurate timings to three or more satellites; at that point, computing the GPS's exact position with respect to the satellites becomes a relatively simple if tedious exercise in spherical trigonometry (which, fortunately, the GPS's firmware does for you).
That's the theory. In practice, the system has important limits. Anything, natural or artificial, that messes with the signal timings will degrade the accuracy of your position fix. Until it was abolished by Presidential decree in 2000, the most important limit was artificial, the so-called 'Selective Availability' feature. The satellites were programmed to introduce patterned timing jitter into the signals. The U.S. military knew the pattern, but nobody else did (or, at least, nobody who was admitting it).
Now that 'Selective Availability' is gone, the important limits are natural. One is a variable amount of signal lag produced as the GPS signals pass through the ionosphere, which partly reflects radio waves. This can be largely compensated for by a technique called "Differential GPS" or DGPS, in which your receiver takes timings both from satellites and ground stations. The ground stations are in a known fixed positions, so they can compute the exact distance to satellites from an ephemeris. Thus, they can measure the for the ionospheric lag and tell nearby GPSes how to correct ranges for it. WAAS and EGNOS are similar systems. See DGPS, WAAS, and EGNOS for details on how this works.
In practice, the most important limit on accuracy is the actual visibility of satellites. A timing signal has to be fairly strong and clear, with little noise or distortion, before a GPS can use it. The frequencies GPS has to use in order to punch through the ionosphere with minimal attenuation (unlike conventional radio and TV signals) don't cope well with solid barriers. Thus, GPS tends to work poorly if at all inside buildings. Tall trees and tall buildings can mess it up, blocking line of sight to satellites that aren't nearly directly overhead.
Accuracy also falls off a bit when you're in motion. This isn't a physical effect, but mostly due to the fact that computation always takes a little time; by the time the GPS figures out where you are, you're not there any more.
Another limit, implicit in the geometry, is that GPS is relatively poor at getting your precise altitude. When you can get a signal lock on four satellites, a modern GPS will give you longitude and latitude within about 10 meters or yards, down to 2 with DGPS correction. Vertical uncertainty will be much higher, as much as fifty meters.
People who really obsess about GPS accuracy quote it not as a single figure but as a probability-of-error: e.g., you're within 10 meters 95% of the time and 2 meters 50% of the time.
You can read a more in-depth description of how the satellites and radio signals work in this vendor manual.
DGPS requires out-of-band communication with a service providing GPS signal correction information to make the GPS positioning more accurate. WAAS and EGNOS are almost identical systems, WAAS being the system covering USA, and EGNOS being the system covering Europe. They provide DGPS-like corrections with in-band communication — geo-stationary satellites broadcasting GPS signal correction information on the same frequency and format as the GPS satellites. The WAAS/EGNOS system makes GPSes more accurate, and adds integrity checks making it possible to detect when the GPS location is totally wrong. Unlike DGPS, your GPS will generally use these systems automatically whenever it can see the satellites.
WAAS/EGNOS data starts out as normal DGPS stations observing the errors. That data gets processed and interpolated into a grid which models ionospheric and tropospheric delay over the WAAS/EGNOS coverage area. The GPSes then interpolate into that grid to get an estimate of lag for their current position. For points close to a DGPS station, raw DGPS should give better accuracy than WAAS/EGNOS. For points far between any reference stations, WAAS should be more accurate than software arbitrarily choosing one 'nearby' DGPS station or another.
The definitive FAQ says this: "On the average, WAAS and DGPS accuracy are virtually the same, although DGPS accuracy is better when the user is near a DGPS transmitting site. The WAAS architecture is designed to provide uniform 7m accuracy (95%) regardless of the location of the receiver within the WAAS service area. DGPS is designed to provide better than 10m navigation service (95%), but typically provides better than 1 meter horizontal positioning accuracy (95%) when the user is less than 100 nautical miles from the DGPS transmitting site. Accuracy then degrades at a rate of approximately 1 meter per hundred nautical miles as the user moves away from the transmitting site."
An important caveat about WAAS is that it doesn't work at sea. You're too far away from any DGPS ground stations for the WAAS birds to interpolate a good value for atmospheric display.
From a software designer's point of view, a GPS sensor is an oracle that tells you its location whenever it can get line-of-sight to four satellites. Our next topic is how it gets that information to a computer in a form your application can use.
Almost all GPSes are serial devices that use either RS-232C or USB to communicate with the host machine. Most track a standard called NMEA 0183 which prescribes both electrical signal levels and a data encoding. The protocol is bidirectional, but designed in the expectation that most of the traffic will be GPS-to-computer, with commands going in the computer-to-GPS direction rare.
The modern trend in GPSes is away from RS232C and towards USB. USB
GPSes keep the NMEA data protocol but discard the NMEA link layer. Under
Linux, USB GPSes use the usbserial module and look like serial ports.
Part of gpsd's job is to hide this stuff; applications don't have
to be aware of NMEA or the link layer, they just query gpsd for
information.
The basic design of the NMEA data protocol is very simple. The GPS throws ASCII text lines called 'sentences', each beginning with a '$' and terminated by CR/LF, at the host machine. Usually the host gets one update a second, but the GPS has the option of sending more frequently when it detects a change of position or velocity or status. The standard prescribes a serial encoding at 4800bps, 8 bits, one stop bit, no parity.
Here are some sample NMEA sentences:
$GPGGA,212734,4740.0569,N,12219.6612,W,1,08,74.00,73.9,M,638.000000,M,,*6D
$GPRMC,212734,A,4740.0569,N,12219.6612,W,0.000000,0.000000,020403,18.936255,E*60
$GPGSA,A,3,17,06,23,15,16,18,10,30,,,,,152.00,74.00,133.00*3F
$GPGGA,212735,4740.0569,N,12219.6612,W,1,08,74.00,74.1,M,638.000000,M,,*63
$GPRMC,212735,A,4740.0569,N,12219.6612,W,0.000000,0.000000,020403,18.936255,E*61
Each sentence consists of a comma-separated fields. The first field is always a message type and the last a checksum that can be used to check for data corruption. Interpreting NMEA sentences is not complicated. Modulo a few glitches like 2-digit year numbers, the NMEA standard does a pretty good job of specifying a message set for GPSes that want to convey data to computers.
More good news: you should never have to deal with this level
— gpsd's purpose is to insulate you from it.
That's the good news. Now for the bad news, which comes in five pieces:
First, the NMEA standard does not specify a command repertoire for the opposite direction. Thus, functions like changing the GPS's update frequency or selecting the subset of sentences for it to send are often not supported at all, and when they are it's all by sentences that are vendor-specific.
This used to be more of a problem than it is today. Early GPSes tended to have elaborate facilities for accepting lists of waypoints and sending back course information to help you navigate to them. Modern high-end units still do, but the GPSes designed for connecting to computers are increasingly designed on the assumption that the host computer will do all the waypoint geometry itself and the GPSes only job is to deliver periodic position and velocity readings. Thus, they tend to have no control codes at all. This makes them laudably stupid.
Second, vendors don't stick to the NMEA-prescribed 4800bps data rate. This is understandable; 4800 is very slow by today's standards, and by boosting bits per second they can deliver information that's fresher by a few milliseconds (which might make a difference if, say, you're using a GPS-enabled autopilot to land an aircraft). Some GPSes feature data rates upwards of 38400bps. However, this actually does little good unless the application polls the GPS at a rate faster than 1Hz rather than waiting for it, as most GPS sensors cannot be told to ship updates faster than once per second — and the polling commands (when they exist at all) are proprietary. And the fact that GPSes don't have a single data rate graven in stone brings back all the well-known baud-mismatch configuration problems we thought we'd left behind in the 1980s.
The third problem with NMEA is that it's not universal. A decreasing but still significant percentage of GPSes use proprietary binary protocols. For example, there was a GPS chipset called "Zodiac" made by Rockwell International, that used to be very widely OEMed by GPS makers. It spoke NMEA, but had irritating limitations in that mode like not being able to accept DGPS corrections. It preferred a tight-packed binary protocol. There haven't been any new Zodiac-based designs in a few years, but a lot of Zodiac-based GPSes (like the DeLorme EarthMates made before they switched over to a SiRF chipset in 2003) are still around.
2004's equivalent of the Zodiac is the SiRF-II chipset, which seems to be nearly ubiquitous in inexpensive GPS sensors. It too speaks a binary protocol, but only if you ask it to; it's fully capable in NMEA mode. Which is where it boots up. The idea seems to be that you can switch to binary to improve your bits-per-second in latency-critical applications.
The fourth problem with NMEA is that it doesn't deliver all the information that the GPS has in one atomic message. In particular, you can't get altitude (delivered in the GPGGA sentence only) and speed (delivered in GPRMC and GPVTG) at the same time. This is annoying; ideal, you want you position/velocity/time oracle to deliver one observation tuple conveying all seven degrees of freedom (t, x, y, z, vx, vy, vz) and their error estimates.
The final irritation about NMEA is that it's expensive to buy a
description. The National Marine Electronics Association is a trade group of
electronics dealers, and they want $250 for a copy of their
standard. Numerous Web sources have reverse-engineered or abstracted
bits of it; the NMEA page piously warns that In most cases they are
very old versions or incorrect interpretations and should not be
depended upon for accuracy,
then mutters darkly about copyright
violations.
Here is the best compendium I know of. I
have never seen a copy of the official NMEA standard. Fortunately, it
isn't necessary for even gpsd developers to know most of
it, since most modern GPS sensors only emit about a half-dozen of the
eighty or so NMEA sentences. RMC, GGA, GSA, GSV (and now possibly
GBS) are all you are ever likely to need to know about.
After you've read about those sentences, it can be instructive to
run gpsd in a mode something like this:
./gpsd -N -n -D 2 /dev/ttyUSB0
Watching the output for thirty seconds or so will give you a good feel for what your GPS has to say, and how often it says it.
The time required for a GPS to get a fix can vary from under 15 seconds up to just under 30 minutes (actually, 29 plus calculation time). The main factors affecting this latency are (a) whether it has an almanac available, (b) whether it has satellite ephemerides available, and (c) whether it has recent fix available. Of course the quality of signal at your location matters as well.
If a GPS has not been on for several months, then it has no current almanac available. It was to wait to download one before it can generate a fix. This can take just under 15 mins. This is sometimes called an autonomous start, notably in Garmin's documentation.
While the almanac download takes 15 minutes, you have to be there for the start of it, otherwise you have to wait for the next cycle. So if you are unlucky and just miss the start of one, it could take just under 29 minutes to obtain, and on average closer to 22 min.
If a GPS has not been on for a day (four to six hours) then it has an almanac but no valid satellite ephemerides, and must download at least three before it can generate an accurate fix. This is sometimes called a cold start. Each satellite has its own ephemeris that must be downloaded if a current copy is not fresh. It takes about a minute per sat to get the ephemeris, or a minute total if your GPS has multiple receivers as most do now.
GPSes store ephemerides is non-volatile memory, either internal flash storage or battery-backed SRAM. Thus, a GPS does not need to have been on continuously to have ephemerides available, but it will consider old data to be invalid after a while. In normal operation the GPS occasionally gets refreshes of ephemeris and almanac data from the satellites it's listening to.
For both an autonomous start and a cold start if the sat signal is momentarily lost, the process will have to restart and you'll get more delay.
If a GPS has been on recently, in the current location, then this is sometimes called warm start or hot start and an accurate fix can be generated quite quickly. This will usually be under a minute for a modern GPS, perhaps as low as 15 seconds.
Here's more on this issue. Details about the satellite signals and there timing are here.
Many GPSes are designed to power down or go to standby mode when DTR or its USB equivalent goes low (under Linux, this happens when you close the port). An important category of exceptions is USB SiRF-II GPSes; these don't seem to power down on DTR low, but instead go to a low-power standby mode for the 8/10s of every second that they're not shipping packets.
Powering down on DTR low can be a valuable power-saving measure if the GPS is (say) running off of laptop batteries in a navigation or wardriving system. Thus, you don't want to keep your GPS device open when you don't actually need information from it.
Unfortunately, this rule can collide with one of the persistent problems with GPSes — though they can update a previous fix quickly (in 0.1sec or less), they can take a long time to acquire a first fix when they power up.
When a GPS receiver boots up, it has to suck radio waves for a while just to figure out what satellites might be available in line of sight. The speed at which it can do this is inversely proportional to the number of GPS channels it can sample simultaneously. Older one- or two-channel units could take several minutes at this. In 2004, even low-end GPS sensors have twelve channels and can thus cock a separate ear for as many satellites as they're ever likely to see. Even so, it's not uncommon for them to take 30 or 40 seconds after a cold boot to get a fix.
One of the things gpsd does for applications is handle this
power-management issue. When no clients are active, gpsd will
automatically close the GPS device, re-opening it only when another
client connects to the daemon.
For more details on programming with gpsd, see the
FAQ.