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
|
$Id$
This is the gpsd to-do list. If you're viewing it with Emacs, try
doing Ctl-C Ctl-t and browsing through the outline headers. Ctl-C Ctl-a
will unfold them again.
For contribution guidelines and internals documentation, please see
<http://gpsd.berlios.de/hacking.html>.
The list of bugs exposed by gpsd in other software has moved to
<http://gpsd.berlios.de/upstream-bugs.html>.
See also the GPSD bug tracker at
<https://developer.berlios.de/bugs/?group_id=2116>
** Bugs in gpsd and its clients:
*** Support for the True North magnetic compass is currently broken
Massimo Burcheri reported that it broke somewhere between rev 3654 and
3722. We think this is a shallow bug, but we can't fix it without
test hardware. If TNT support is a problem for you, and you can't
fix the driver yourself and send us the patch, contact Bill Powell
<bpowell@tntc.com> at True North Technologies and tell him he needs
to reverse his refusal to send us an eval unit.
** To do:
*** Complete and test the speed/parity/stopbit methods in the drivers
These are used for the 'B' command. All work for 8N1.
**** superstar2: not implemented (driver is unfinished)
**** italk: not implemented (but could be)
**** tsip: speed tested, parity and stop-bit switching not tested
**** sirf: speed tested, parity and stop-bit switching not tested
**** evermore: speed tested, rejects parity/stopbit setting
**** ubx: fully implemented, parity and stop-bit switching not tested
**** zodiac: fully implemented, not tested
**** navcom.c: speed tested, rejects parity/stopbit setting
SiRF, UBX, TSIP, and even Zodiac can support non-8N1 modes; these need
to be tested.
*** Support the D-Bus signals recognized by libgypsy
Ian Holmes's Gypsy daemon is a pale shadow of GPSD, but his ideas
about signalling D-Bus client apps only on fix changes are good. We
should support the signal set described here:
<http://gypsy.freedesktop.org/why-not-gpsd.html>.
*** Command to ship RTCM corrections to a specified device
At the moment, if a GPS accepts RTCM corrections and they are
available, gpsd ships them to the serial device from which the GPS is
reporting fix data. Some GPSes have auxiliary ports for RTCM;
there should be a (privileged) command to redirect RTCM connections.
*** libgps should try to automatically try to reconnect when a poll fails
Petter Reinholdtsen suggests:
At the moment, when a gpsd client using libgps is connected to the
gpsd server, and the server is restarted, the client loses the
connection and do not update any more.
It would be nice if the gps_poll() and gps_query() would try to
reconnect to the server if the read() and write() calls on the tcp
socket fail.
To test this, start gpsd first (/etc/init.d/gpsd start), xgps second,
and then restart gpsd (/etc/init.d/gpsd restart). The xgps client
will fail to update any more.
I realised how nice this feature would be while comparing the xgps
client to the roadgps client (part of the roadmap package). The
roadgps client would reconnect to the new server and keep updating as
soon as the server was available. :)
On second thought, and after discussing this on the gpsd mailing list,
I believe the reconnect need to be handled by the applications in
addition to the library. Applications will commonly use the file
descriptor to detect incoming data, and this file descriptor will
change on reconnect.
So I rephrase my wish, and ask for reconnect functionality in xgps
instead. It will make sure the library support reconnects, and also
provide an example for other clients using the library.
(ESR thinks maybe this ought to be done at library level anyway, with
users warned that the gps_fd member of the gps_data_t structure may
change on reconnect and shouldn't be cached. This wouldn't be hard to
implement, but it would change gps_data_t and require a library
version bump.)
This is Berlios FR #3789.
*** Full Python wrapper for libgpsd
This would be useful for test code of all kinds.
*** New features for xgps.
Add J option checkbox. Maybe embed the speedometer widget from
xgpspeed in some of the unused space and nuke xgpsspeed.
*** Per-driver restore of changed config settings on exit.
This is a solved problem for generic NMEA, EverMore, TripMate,
EarthMate, TNTC, Zodiac, and RTCM104 drivers (if only because they
don't configure any device setting).
The SiRF driver now restores NMEA when necessary. It also restores
some (but not all) of the things it tweaks in binary mode -- at the
moment, just the Navigation Parameters from message 0x13. With more
work, we should be able to do a full revert.
The TSIP driver changes its per-cycle sentence inventory and thus
needs some state-restore logic. This can be done; the same packet 0x35
we use to configure it can be sent in a no-argument mode to query
the current sentence mix for later restore.
The FV18 changes its per-cycle sentence inventory to include GSAs. It
is possible to query that inventory, though we don't have code to do
it yet.
Garmin devices are a mess. We reconfigure those heavily, and we
don't know if there's any way to capture their configuration state
before we do it.
The iTrax02 driver sets SYNCMODE to start navigation messages without
checking to see if it's already on, and stops navigation methods on
wrapup. It also forces the set of sentences issued. There doesn't
seem to be any way to query these settings.
*** Merge cgps and xgps
Possibly cgps and xgps should merge into a single test client that honors the
GPSD_UNITS environment variable and chooses its UI mode depending on
whether or not it's running under X. There is controversy about this
proposal on the dev list.
*** SiRF firmware uploader
Chris Kuethe has shipped a 0.0 pre-alpha version. It is not yet
resolved whether SiRF Technology will allow us to ship the
binary loader code needed to actually use it.
*** uBlox firmware uploader
uBlox does make firmware updates available on their website and a cursory
inspection suggests that their flash process should plug directly in to
gpsflash - they use the same three stage process as SiRF: send a binary
command to enter programming mode, send a tiny reflash bootstrap program
and then send the actual firmware image.
*** Industry-standard format dumping of raw satellite data
It would be useful to be able to extract RINEX (or some other standard)
format data from any GPS device that can report pseudoranges etc. This
belongs in the daemon because the device drivers are already doing the
packet-cracking needed to get the data off the chips.
Several commodity chipsets (ANTARIS, iTrax3, SiRF and Trimble) readily
output enough data to make this a chore, rather than a hard problem.
It has been suggested one way to do this is to have a generic structure
in memory and corresponding output message with clock, doppler carrier
phase and pseudoranges. This message is then reformatted by a client
program. There are numerous formats for this information, and it would
be easier to adapt to new formats if the formatting and use was handled
by something other than the gpsd daemon. Currently the RT-IGS format is
looking like the favorite for implementation; it's a fairly lightweight
protocol, flexible enough to handle all the quantities required, and it
is actually in use in production reference networks. RT-IGS is also a
packet-oriented format, rather than a file-oriented format like RINEX.
*** RTCM3 support.
Previous plans for more RTCM2 support seem to have been overtaken by
events, e.g. the world moving to RTCM3. We have support for analyzing
RTCM3 messages, but it's entirely theoretical - written from the
standard. We need to find a pair of files consisting of a
representative set of RTCM3 sentences and some sort of ASCII dump of
thgem so we can test whether our analyzer gets all the bitfield
boundaries right.
*** Do the research to figure out just what is going on with status bits
NMEA actually has *four* kinds of validity bits: Mode, Status, the
Active/Void bit (some sources interpret 'V' as 'Navigation receiver
warning'), and in later versions the FAA indicator mode. Sentences
that have an Active/Void send V when there is no fix, so the position
data is no good.
Let's look at which sentences send what:
GPRMC GPGLL GPGGA GPGSA
Returns fix Yes Yes Yes No
Returns status No Yes Yes No
Returns mode No No No Yes
Returns A/V Yes Yes No No
In addition, some sentences use empty fields to signify invalid data.
My first conclusion from looking at this table is that the designers
of NMEA 0183 should be hung for galloping incompetence. But never mind that.
What are we to make of this mess?
The fact that the FV18 sends GPRMC/GPGLL/GPGGA but not GPGSA
argues that GPGSA is optional. I don't see how it can be, since it
seems to be the only status bit that applies to altitude. Just how are
we supposed to know when altitude is valid if it doesn't ship GSA?
Can a receiver ever ship a non-empty but invalid altitude?
Which of these override which other bits? I don't think status is ever
nonzero when mode is zero. So status overrides mode. What other such
relationships are there?
News flash: it develops that the "Navigation receiver warning" is
supposed to indicate a valid fix that has a DOP too high or fails
an elevation test.
*** IPv6 Support
gpsd should have support for IPv6. Steps to get to full IPv6 support
include:
**** Detect IPv6 support and getaddrinfo(3) in configure.ac
This web page may be helpful, but is probably overkill - the world has
gotten simper since then:
http://cvs.deepspace6.net/view/example-ipv6-package/configure.ac?rev=1.2&content-type=text/vnd.viewcvs-markup
**** Change from one listening socket to N
Having multiple sockets will also support future changes to listen on
specific addresses, rather than the -G option for INADDR_ANY instead
of INADDR_LOCAL.
**** If v6 support is present, open both AF_INET and AF_INET6.
If either fails, just skip it. gpsd should run on systems without
"options INET" but with only "options INET6" (BSD) or the Linux
equivalent.
**** In libgps, if getaddrinfo is present, use it instead of gethostbyname.
Loop through all the returned addresses until one works. See telnet
in NetBSD for an example (src/usr.bin/telnet/commands.c).
**** (perhaps) Add a flag to connection libraries to force v4 or v6.
Also add command line flags to force the library flags. Perhaps this
is not necessary; telnet and ntp have this feature but postfix and
sendmail don't seem to.
** Future features (?)
*** Support for more survey / professional / up-scale receivers.
Devices such as the Javad JNSCore, Hemisphere Crescent, Septentrio
AsteRx and PolaRx, NovAtel Superstar2 and OEMV, Thales (Magellan
Professional) AC12 and DG14 would all be welcome. Of course, these
are not $50 usb mice...
*** Audio cues in the client when the fix status changes
Calum writes:
>Is it possible to add functionality (with a switch to enable it to
>avoid annoying those that don't want it) so that beeps indicate NO
>FIX, FIX, and OFFLINE status changes?
>
>For example - I run cgps and my laptop battery doesn't always supply
>my PS2 port-powered GPS device with enough power, and it goes into
>OFFLINE mode. As I can't drive, and check my laptop all the time, if
>it emitted 5 1 second beeps when it went OFFLINE, it would be a handy alert.
>
>Similarly, a PCMCIA "eject" 2 beeps for NO FIX, and a PCMCIA "happy" 2
>beeps when it gets a fix again?
>
>Or something like that.
This is a good idea for supporting hands-free operation, e.g. while driving.
It would be an easy first project for somebody who wants to get into
the client code.
*** Set the system time zone from latitude/longitude
If we're going to give gpsd the capability to set system time via
ntpd, why not let it set timezone as well? A good thing for hackers
travelling with laptops!
The major issue here is that I have not yet found code, or a
database, that would allow mapping from lon/lat to timezone.
And the rules change from year to year.
Actually this should be built as a specialized client, as some
people won't want it.
From <http://www.linuxsa.org.au/tips/time.html>:
The timezone under Linux is set by a symbolic link from
/etc/localtime[1] to a file in the /usr/share/zoneinfo[2] directory
that corresponds with what timezone you are in. For example, since I'm
in South Australia, /etc/localtime is a symlink to
/usr/share/zoneinfo/Australia/South. To set this link, type:
ln -sf ../usr/share/zoneinfo/your/zone /etc/localtime
Replace your/zone with something like Australia/NSW or
Australia/Perth. Have a look in the directories under
/usr/share/zoneinfo to see what timezones are available.
[1] This assumes that /usr/share/zoneinfo is linked to /etc/localtime as it is under Red Hat Linux.
[2] On older systems, you'll find that /usr/lib/zoneinfo is used
instead of /usr/share/zoneinfo.
Changing the hardlink will, of course, update the system timezone for
all users. If I were designing this feature, I'd ensure that the
system timezone can be overridden by a user-set TZ, but I don't know
if it actually works that way.
If I'm reading the tea leaves correctly, this functionality is actually
embedded in the GCC library version of tzset(), so the same method will
work on any system that uses that.
Problem: system daemons use the timezone set when they start up. You
can't get them to grok a new one short of rebooting.
Sources:
Sources for Time Zone and Daylight Saving Time Data
http://www.twinsun.com/tz/tz-link.htm
Free time-zone maps of the U.S.
http://www.manifold.net/download/freemaps.html
Local variables:
mode: outline
paragraph-separate: "[ ]*$"
end:
|