1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
|
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Author" content="Eric S. Raymond">
<meta name="Description" content="Programmer's guide to GPS hacking.">
<meta name="Keywords" content="GPS, translator, GIS">
<link rel="stylesheet" href="main.css" type="text/css"/>
<title>ESR's Guide to Hacking With GPS</title>
</head>
<body>
<div id="Header">
ESR's Guide to Hacking With GPS
</div>
<div id="Menu">
<img src="gpsd-logo-small.png"/><br />
<a href="index.html">Home</a><br/>
<a href="index.html#news">News</a><br/>
<a href="index.html#downloads">Downloads</a><br/>
<a href="index.html#mailing-lists">Mailing lists</a><br/>
<a href="index.html#documentation">Documentation</a><br/>
<a href="faq.html">FAQ</a><br/>
<a href="xgps-sample.html">Screenshots</a><br/>
<a href="index.html#recipes">Recipes</a><br/>
<a href="index.html#others">Other GPSDs</a><br/>
<a href="hardware.html">Hardware</a><br/>
<a href="for-vendors.html">For GPS Vendors</a><br/>
<a href="wishlist.html">Wish List</a><br/>
<a href="hacking.html">Hacker's Guide</a><br/>
<a href="compatibility">Application Compatibility</a>
<a href="references.html">References</a><br/>
<a href="history.html">History</a><br/>
<div> </div>
<a href='http://www.catb.org/hacker-emblem/'><img
src='http://www.catb.org/hacker-emblem/glider.png'
alt='hacker emblem' /></a><br />
<hr/>
<script type="text/javascript"><!--
google_ad_client = "pub-1458586455084261";
google_ad_width = 160;
google_ad_height = 600;
google_ad_format = "160x600_as";
google_ad_type = "text";
google_ad_channel = "";
//--></script>
<script type="text/javascript"
src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
</script>
<hr/>
<a href="http://validator.w3.org/check/referer"><img
src="http://www.w3.org/Icons/valid-xhtml10"
alt="Valid XHTML 1.0!" height="31" width="88" /></a>
</div>
<div id="Content">
<p>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 <code>gpsd</code> software that you need to know about when
writing location-aware applications.</p>
<p>We'll go from general to specific, beginning with an overview of how
GPS works and ending with architectural suggestions about how to use
<code>gpsd</code> to make your application location-aware.</p>
<h2>How GPS Works</h2>
<p>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.)</p>
<p>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.</p>
<p>You can look at a very nifty <a
href="http://rhp.detmich.com/gps.html">simulation</a>
of GPS satellite orbits. (Also includes GLONASS, the Russian military
equivalent of GPS.) You can also look at
<a href='http://www.tsgc.utexas.edu/images/spacecraft/gps/'>pictures</a>
of GPS satellites and the control system.</p>
<p>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 lightspeed 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).</p>
<p>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).</p>
<p>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 <a href="#ggps">DGPS, WAAS,
and EGNOS</a> for details on how this works.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>People who really <a
href="http://www.wsrcc.com/wolfgang/gps/accuracy.html">obsess</a>
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.</p>
<p>You can read a more in-depth description of how the satellites and
radio signals work in this <a
href="http://www.novatel.com/Documents/Manuals/GPS+Reference.pdf">vendor
manual</a>.</p>
<h1 id='dgps'>DGPS, WAAS, and EGNOS</h1>
<p>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.</p>
<p>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.</p>
<p>The definitive <a href='http://gps.gov/gps/WAAS-DGPS.htm'>FAQ</a>
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."</p>
<p>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.</p>
<h1>How GPS Hardware Talks To Computers</h1>
<p>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.</p>
<p>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.</p>
<p>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 <code>gpsd</code>'s job is to hide this stuff; applications don't have
to be aware of NMEA or the link layer, they just query <code>gpsd</code> for
information.</p>
<h2>The good news about NMEA</h2>
<p>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.</p>
<p>Here are some sample NMEA sentences:</p>
<listing>
$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
</listing>
<p>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.</p>
<p>More good news: you should never have to deal with this level
— <code>gpsd</code>'s purpose is to insulate you from it.</p>
<h2>The bad news about NMEA</h2>
<p>That's the good news. Now for the bad news, which comes in five
pieces:</p>
<p>First, the NMEA standard does <em>not</em> 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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<h2>Learning more about NMEA</h2>
<p>The final irritation about NMEA is that it's expensive to buy a
copy. The National Marine Electronics Association is a trade group of
electronics dealers, and they want <a
href='http://www.nmea.org/pub/0183/'>$250</a> for a copy of their
standard. Numerous Web sources have reverse-engineered or abstracted
bits of it; the NMEA page piously warns that <q>In most cases they are
very old versions or incorrect interpretations and should not be
depended upon for accuracy,</q> then mutters darkly about copyright
violations.</p>
<p><a href='NMEA.txt'>Here</a> 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 <code>gpsd</code> 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 are all you are ever
likely to need to know about.</p>
<p>After you've read about those sentences, it can be instructive to
run <code>gpsd</code> in a mode something like this:</p>
<listing>
./gpsd -N -n -D 2 /dev/ttyUSB0
</listing>
<p>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.</p>
<h1>Locking and Loading</h1>
<p>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.</p>
<p>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 <dfn>autonomous start</dfn>, notably in Garmin's documentation.</p>
<p>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.</p>
<p>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 <dfn>cold start</dfn>. 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 emphemeris, or a minute total if your GPS has
multiple receivers as most do now.</p>
<p>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 accasionally gets refreshes of ephemeris and almanac data
from the satellites it's listening to.</p>
<p>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.</p>
<p>If a GPS has been on recently, in the current location, then this
is sometimes called <dfn>warm start</dfn> or <dfn>hot start</dfn> 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.</p>
<p>Here's <a href="http://gpsinformation.net/main/warmcold.htm">more
on this issue</a>. Details about the satellite signals and there
timing are <a
href="http://www.kowoma.de/en/gps/data_composition.htm">here</a>.</p>
<h1>GPSs and Power Management</h1>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>One of the things <code>gpsd</code> does for applications is handle this
power-management issue. When no clients are active, <code>gpsd</code> will
automatically close the GPS device, re-opening it only when another
client connects to the daemon.</p>
<p>For more details on programming with <code>gpsd</code>, see the
<a href="faq.html">FAQ</a>.</p>
<h1>Where to learn more</h1>
<dl>
<dt><a href="http://34n118w.net/htmldir/GPS.html">GPS Resources</a></dt>
<dd>This is where the orbital simulation came from.</dd>
<dt><a href='http://en.wikipedia.org/wiki/GPS'>Wikipedia on GPS</a><dt>
<dd>Good introduction with much more on the history of the system.</dd>
<dt><a
href='http://www.circuitcellar.com/library/print/0899/Cyliax109/index.htm'>Where
in the World</a></dt>
<dd>Good introduction, with the best explanation I've seen yet of arcana
like <a
href="http://www.circuitcellar.com/library/print/0899/Cyliax109/3.htm">CEP
and DGPS</a>.</dd>
<dt><a href="http://www.ualberta.ca/~ckuethe/gps/">GPS Hackery</a></dt>
<dd>Chris Kuethe's page has links to many interesting resources.</dd>
<dt><a href="http://www.ualberta.ca/~norris/gps/DOPnontech.html">DOP,
the non-technical description</a></dt>
<dd>Explains the most obscure statistic in GPS output.</dd>
<dt>
<a href='http://www.eomonline.com/Common/Archives/1995aug/95aug_gps.html'>Two</a> <a href='http://www.eomonline.com/Common/Archives/1996feb/96feb_gps.html'>articles</a> from Earth Observation Magazine</dt>
<dd>These delve into the mysteries of GPS accuracy.</dd>
<dt><a href='http://users.erols.com/dlwilson/gps.htm'>David L. Wilson's GPS Accuracy Web Page</a></dt>
<dd>Goes in-depth on accuracy, with the math.</dd>
<dt><a href='http://home-2.worldonline.nl/~samsvl/'>Sam's GPS Raw
Data Pages</a></dt>
<dd>A useful view of some GPS technical arcana from a programmer.
Includes the best <a
href='http://home-2.worldonline.nl/~samsvl/nav2eu.htm'>short
description</a> I've seen of the GPS Navigation Message as it comes
down from the satellite.</dd>
<dt><a href='http://www.topology.org/soft/gps.html'>GPS interfaces and
software</a></dt>
<dd>Linux and open-source resources for working with GPSes.</dd>
</dl>
</div>
<hr/>
<script language="JavaScript" src="datestamp.js" type='text/javascript'></script>
</body>
</html>
|
