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
|
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
the "Hacking Guide" on the project website.
The list of bugs exposed by gpsd in other software has moved to
the "Upstream Bugs" page on the project website.
** Bugs in gpsd and its clients:
*** Tracker bugs
See the GPSD bug tracker on the project website, but don't be
surprised if it's empty or very sparse. Our rate of new defects per
month is quite low.
** Dispatcher/network issues
**** Reading AISHub data via UDP confuses xgps with short writes
To reproduce, "gpsd -D 5 -N -n udp://192.168.1.3:12346" (only
works inside thyrsus.com) and run xgps. Probably some kind of
packet aggregation issue.
*** Driver issues
**** gpsctl -b should work on UBX, but does not.
Presently this means there's no way to kick a UBX into returning
binary data. Chris Kuethe is supposed to fix this one.
**** RTCM3 analysis is incomplete
We can presently decode RTCM3 messages of type 1004, 1005, 1006, 1008, 1012,
1013, and 1029. This is not the complete set. We need more test data with
different types in them, and a copy of the RTCM3 standard at latest revision
(all we have is revision 3).
**** Reporting code for specialized Type 6 and 8 AIS messages is incomplete.
This one is mine and Kurt Schwehr's. Support is currently nearly
complete; the only missing cases are a handful of IMO 236 and IMO 289
message 6 and 8 subtypes.
** Ports
*** Windows port
Partially complete. David Ludlow <dave@adsllc.com> is working on it.
** To do:
*** Make subframe reports available in the C API.
gpsd now reports subframes when they're available, but the C client
library doesn't yet parse them. A sample program to dump the SUBFRAME
data would also be useful. Gary Miller has this in his queue.
*** Write advanced features for TNT Revolution device
The baud-rate switcher in the TNT driver needs to be tested.
gpsmon could support a number of TNT configuration commands, including
unit changes. See http://gpsd.googlecode.com/truenorth-reference.pdf
for possibilities.
Jon Schlueter has one of these on a flock machine, so testing
shouldn't be difficult.
*** Enable flocktest on the Debian server farm
Debian server farm boxes have a screwy chrooted envoronment setup.
flocktest needs to be modified to deal with it.
*** Finish gpssim
It's blocked on skyview computation.
*** Complete and test the speed/parity/stopbit methods in the drivers
These are used for the '?DEVICE' 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.
*** 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.
*** Per-driver restore of changed config settings on exit.
This is a solved problem for generic NMEA, EverMore, TripMate,
EarthMate, TNT, Zodiac, and RTCM104 drivers (if only because they
don't configure any device settings).
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.
** Future features (?)
*** Industry-standard format dumping of raw satellite data
It would be useful to be able to report raw GPS data (pseudoranges,
clock, doppler carrier) 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.
Probably the best way to do this would be to add support for unscaled
output of pseudoranges in SKY and add clock and doppler carrier
phase. This JSON could then be interpreted by a client program and
dunmped in various standard formats.
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.
*** NOFLOAT build
We want to be able to build a minimalist version that doesn't require
floating-point arithmetic, for deployment on low-power ARM devices
without FPU.
*** 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...
Local variables:
mode: outline
paragraph-separate: "[ ]*$"
end:
|