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
|
<!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>GPSD FAQ</title>
</head>
<body>
<div id="Header">
GPSD Frequently Asked Questions
</div>
<div id="Menu">
<a href="index.html">Home<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/>
FAQ<br/>
<a href="xgps.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="history.html">History</a><br/>
<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">
<h1 id='bug-reporting'>How do I report bugs in GPSD?</h1>
<p>First, read this whole FAQ before reporting apparent misbehavior as a
bug. You may find a solution here.</p>
<p>Second, make sure it is a real gpsd bug and not a problem with
your client software. A good way to do this is to run your client and
the gpsd test client (xgps) side by side. If xgps seems to report
good numbers but your client does not, you have a client problem.
If xgps reports the same sort of bad numbers as your client, you
have a real gpsd bug.</p>
<p>You may get a better handle on your problem by running gpsd in
foreground (-N option) with the -D option set to a high level (-D 4 is
often good). If the transcript has anything that looks like a clue
in it, send it along with your bug report. When in doubt about
whether it holds a clue, send it.</p>
<p>If we can reproduce your gpsd problem, we can usually fix it very
rapidly. If we can't reproduce it, you might get lucky or you might
not — and we try hard, but all too often the result is 'not'.</p>
<p>Therefore your third step should always be to try to capture a log
of some GPS output that reproduces the bug, and your second step
should be to feed it to a gpsd instance through gpsfake to verify that
the log does in fact reproduce the bug.</p>
<p>Once you have the log, trim it to the smallest span of data that
reproduces the bug. A systematic way to do this is to cut the log in
half at the middle and test each half. If one half doesn't reproduce
the bug but the other does, throw away the half that doesn't. Repeat
this procedure on the half that tickles the bug until you can't make
it any smaller. Then send us that.</p>
<p>If possible, use the -l option of gpsfake to pin down the line of
NMEA or packet of SiRF that produces the bug and tell us that.</p>
<p>If you're using a SiRF-based GPS (which you can tell from the -D 4
output), switch back to NMEA mode using the N command and see if the
bug still reproduces. Also try switching on <a
href="#crazy_speed">static navigation mode</a>.</p>
<p>Though it happens seldom, badly-formed NMEA from a device with poor
standards compliance has been known to core-dump gpsd. If your gpsd
has core-dumped, try to use gdb or whatever your local symbolic
debugger is to generate a stack trace of the crash, and send us
that.</p>
<p>Always include with your bug report the GPS vendor and model. If
your GPS is SiRF-based, include the firmware version as well. You can
find out what that is by running at the daemon at -D 4.</p>
<h1 id='crazy_speed'><code>gpsd</code> reports crazy high speeds</h1>
<p>You are probably using a SiRF-II GPS. Some of these come up in
XTrac mode, which makes them more sensitive but also more sensitive
to multipath interference and prone to report spurious large velocities.
Try bringing up <code>sirfmon</code> and using the 'c1' command to
set Static Navigation Mode. This setting should persist between
GPS uses.</p>
<h1 id='date_flicker'>The date in <code>xgps</code> flickers to "n/a" part of the time</h1>
<p>The sentence or packet your GPS uses to report satellite
bearing/elevation has no timestamp. The <code>xgps</code>
date display flickers to "n/a" when it has just seen this report.</p>
<p>This is a known problem. It's not a bug — or, at least, not
a bug in the GPSD code. Blame the idiot protocol designers who
saw fit not to timestamp their satellite-data packet. (NMEA and Garmin
GPSes don't. SiRF GPSes do. Score one for SiRF.)</p>
<p><code>gpsd</code> is faithfully reporting the information it is
getting from the GPS, including the fact that the Y sentence contains
no date, That's its job. The libgps library is doing its bit by
passing everything from <code>gpsd</code> on to the client application
as it arrives, including the lack of date.</p>
<p>It's the <em>client's</em> job to interpret/interpolate/fill in
gaps, to do policy. What you're seeing as a bug only looks like one
because <code>xgps</code>, as is proper for a test client, has as
little policy as possible.</p>
<h1 id='why_migrate'>Why this version of <code>gpsd</code>?</h1>
<p>If you have written a <code>gpsd</code>-aware application using one
of the old 1.x versions, or a fork such as ngpsd or tgpsd, here are
some good functional reasons to migrate to 2.0:</p>
<ol>
<li>Your application can now query whether or not the GPS is online
and get an authoritative answer.</li>
<li>Timestamps are now no longer truncated to seconds, but reported to
whatever resolution the GPS ships. Often (notably on SiRF-II GPSes)
this is milliseconds.</li>
<li>There is a new "watcher" mode. It is like raw mode in that the
GPS streams updates at you, but unlike it in that the updates are in
the simpler GPSD format rather than the more complex NMEA one.</li>
<li>The daemon now automatically tries to reconnect to the GPS once
a second when it is offline but clients are connected.</li>
<li>Writes to clients are nonblocking, so new <code>gpsd</code> cannot
be stalled by a wedged client.</p>
</ol>
<p>These changes mean that even if users casually unplug and reconnect a
GPS, your application can notice the unplug and reconnect events,
and automatically starts getting data again a second after the reconnect.</p>
<h1 id='accuracy'>Why use <code>gpsd</code> protocol rather than
parsing raw NMEA?</h1>
<p>Some applications that use <code>gpsd</code> start raw mode with
the 'r' command and parse the NMEA directly. This is not a good idea.</p>
<p>One problem with raw mode is that NMEA is a poorly specified
standard. There are, for example, two different and incompatible
variants of GPVTG. Another issue is that implementations vary as to
whether they leave fields they don't supply empty or fill them in with
a special value such as 0.0. Interpretation of the different NMEA
status fields is a black art.</p>
<p>It is all too easy to write an NMEA parser that works well on one
variant but breaks on anither, delivering subtly incorrect results or
even crashing your application. Because <code>gpsd</code> specializes
in the job, we collect knowledge on all variants and do parsing that
is much less likely to get tripped up.</p>
<p>Another issue is that some of the reports your application would
like to have are not generated by all GPSes. Estimated position error
in meters is the most obvious example; climb/sink is another. When a GPS
doesn't supply these, <code>gpsd</code> can fill them in using the
same sorts of computation that more capable GPSes use.</p>
<h1 id='accuracy'>How should I interface my application with
<code>gpsd</code>?</h1>
<p>The <code>gpsd</code> package provides two ways for C code to get
data from a GPS. Both go through the libgps.a library, which supports
two sets of entry points. The <a href="libgpsd.html">low-level
interface</a> talks directly to the GPS. The <a
href="libgps.html">high-level interface</a> communicates with an
instance of <code>gpsd</code>, which uses its own copy of libgps.a to
talk to the device.</p>
<p>A third way would be to open a socket to <code>gpsd</code> and
interpret <code>gpsd</code> protocol or raw NMEA in your application.
Before 2.0, all <code>gpsd</code>-aware applications had to do this
because libgps.a didn't exist. Now that it does, the exercise is
rather pointless. Using libgps.a will probably simplify your code a
lot.</p>
<p>You will almost always want to use the high-level interface and go
through the daemon; among other things, this means more than one
application will be able to query the GPS without causing confusion.
The only exception will be in very space-constrained single-user
scenarios, perhaps on embedded systems or PDAs. On those it may be
appropriate to use the low-level interface directly, probably with a
build from source that conditions out all but one of the drivers.</p>
<p>For Python programmers, there are gps.py and gpsd.py modules
implementing respectively the high-level and low-level interfaces.
Each exports a class that encapsulates a GPS session.</p>
<h1 id='accuracy'>How has the <code>gpsd</code> interface changed since
1.x?</h1>
<p>There are three minor incompatibilities with <code>gpsd</code> 1.x:</p>
<p>First, <code>gpsd</code>-2's command-line options have been changed
and simplified. If your <code>gpsd</code>-using application is
starting up <code>gpsd</code> directly you may find you have to modify
the invocation. However, we don't recommend this. New
<code>gpsd</code> is designed to be started by hotplug scripts when
a USB device wakes up, or started at boot time and run
continuously just like any normal daemon. It will do nothing, and be
swapped out, unless there are clients trying to query the GPS.</p>
<p>Second, <code>gpsd</code> now returns "?" as the contents for a
field when it doesn't have valid data for that field (e.g. latitude
or longitude before the first fix). This is only an issue if you are
interpreting GPSD responses yourself rather than using libgps.a or the
gps.py Python module.</p>
<p>Third, the format of the timestamp returned by the D command has
changed, from "%m/%d/%Y %H:%M:%S" to ISO-8601: "%Y-%m-%dT%H:%M:%SZ".
No more U.S.-centric date-format assumptions! Also, as previously
noted, the seconds part may have one or more digits of decimal fractional
seconds.</p>
</body>
</div>
<hr/>
<script language="JavaScript" src="datestamp.js" type='text/javascript'></script>
</html>
|
