forked from ukyg9e5r6k7gubiekd6/gpsd
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathTODO
301 lines (216 loc) · 11.6 KB
/
TODO
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
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.
** Installation **
Improve the uninstall target. Remove library syminks.
Make libdir conform to new FHS layout: 32bit in lib/ and 64bit in
lib64/. Doing that also makes the uninstall more complex.
** Documentation **
We now have two different calibration procedures in the Time Service
HOWTO. One was written by Gary and is based on peerstats; the other by
Sanjeev Gupta and is based on loopstats.
Can these be merged? How do we know which is appropriate to use when?
What could we build in the way of tools and visualization aids to make
the calibration process less annoying?
** Things to do when we can break compatibility **
-------------------------------------------------------------------------
In gps_data_t, save PPS precision; this will require creating a pps struct.
Where would PPS precision come from?
Make the Python JSON client as smart as the C JSON client. Gonna be
a big job. The C client checks all the JSON classes for completeness
and correctness. For example, a missing JSON field will be replaced
with a default value. Also out of bounds values are fixed. The Python
client does no checks. it just mushes a JSON sentance into a big Python
variable. No validity checking, no missing fields fixed, etc. The C
client uses a generic validator function, fed with templates for each
JSON message. Initially harder than a simple procedural parser, Once
running it is very robust and easy to tweak.
Add u-blox IMU (UBX-ESF-RAW) support. Nothing we can do without
samples or a u-blox IMU.
Adding a sample Go client (gpspipe -> pytogo -> Go ?).
Move webgps.py out of contrib. It needs a man page and light cleanup.
** 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.
*** RFC2783 bugs
**** detangle TIOCMIWAIT and RFC2783
Currently, the code for RFC2783 seems to depend (logically) on
TIOCMIWAIT support. However, RFC2783 (and really, no standard)
defines TIOCMIWAIT, and NetBSD (and probably FreeBSD) do not implement
it. So, there really should be two separate implementations, one that
works with TIOCMIWAIT (and thus only on Linux and OpenBSD) and one
that assumes only RFC2783 (and thus works on Linux, FreeBSD and
NetBSD, as well as any future system that complies with RFC2783 and
uses the serial port for time_pps_init).
*** Client bugs
*** 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 as it doesn't happen with test logs.
*** Driver issues
**** RTCM3 analysis is incomplete
We can presently decode RTCM3 messages of type 1001-1014, 1029, and
1033. 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).
The support for unpacking RTCM3 sentences in the client library is
limited to 1001, 1002, 1007, 1008, 1009, 1010, 1014, and 1033. There
are some design issues with the baby JSON parser that are going to
make extending this set difficult.
**** 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 - specifically, 6/23, 8/21, 8/22, 8/24, and
8/26.
** New features **
** Qt **
Add a sample client
*** Time tracking
Our goal is to be independent of the system clock.
Create a CLI tool to convert UTC to GPS week/tow and back.
**** Maybe apply wraparound compensation ****
See <http://www.febo.com/pipermail/time-nuts/2013-August/079271.html>
*** Optionally use tag blocks in NMEA output
Ed W. writes:
>Feature request: I would like to see an option to get the NMEA data
>out of gpsd, but augmented with a timestamp on each sentence and
>details of which input fed in the data. TAG blocks appear to solve
>that problem perfectly. So the feature request is simply an option
>that inserts a TAG block for each emitted sentence from GPSd with a
>timestamp and some handle which references the input method for the
>sentence.
>
>I think all this is effectively emitted with the JSON output (?), so
>really this is just adding it to the NMEA sentence output options via
>the TAG structure
However, Iván Sánchez Ortega notes:
>There is one *big* problem with using TAG blocks to timestamp the sentences.
>The standards (as far as I/we know) say that the timestamp is **either** the
>number of seconds **or** milliseconds since the UNIX epoch, but we do **not**
>know if the initial state should be secs, msecs, or nothing. We do not know
>how clients reading that TAGblocked NMEA stream should ask GPSD to switch the
>timestamp units (or enable/disable them).
>
>There are a few sentences introduced in NMEA 4.00 that supposedly allow that -
>the client sends a sentence to the server, and then the server starts
>TAGblocking sentences. But, alas, there are no examples anywhere.
>
>>From my personal experience, the way to know if a TAGblocked timestamp is in
>seconds or milliseconds is ask the people in charge of setting up the
>device/service. Perhaps some devices output only secs/msecs, and some other
>accept the NMEA 4.00 TAGblock configuration sentences.
>
>I, for one, would like to see the secs/msecs problem solved before GPSD
>embarks on the enterprise of writing TAGblocks.
If someone is working on this, please see:
http://www.nmea.org/Assets/0183_errata_tag_block_final.pdf
**** Speed, mode and rate-changes in client-mode gpsctl.
Baud rate and mode changes work in direct mode but are not
reliable in client mode.
**** Optional dump of GPS configuration using gpsctl.
Some settings, like antenna in use, dead-reckoning mode, would be
helpful to see.
**** Integrate 1PPS into profiling ***
We caw now *really* measure latency from GPS top of second when it has
1PPS. Add this capability to gpsprof and revise the "Where's the
Latency?" white paper.
*** Low-power autoconfiguration in the uBlox driver ***
Anthony Stirk <[email protected]> writes on Wed May 21 06:09:00 2014:
The low power modes are really good on the ublox modules (especially the
MAX7's) however a word of warning.
We use the 1 sec cyclic mode on our balloon trackers but if the module
looses satellites or is jammed out (cheap Chinese cameras do it) the ublox
modules seem to hang and become unresponsive. To mitigate against this you
need to put the module back in max performance mode as soon as the
satellites drops below 4.
I'm not sure for most applications the low power mode needs to be used at
all on the newer ublox modules. The values for the MAX-7Q are 22mA (6Q
50mA) under acquire, tracking (i.e locked and in max performance) current
at is 17mA (39mA 6Q) and power saving reduces this to 5mA or less (15mA on
the 6Q). We've observed the issue on the 6 and 7 series.
A possibility: drop the chip to low-power mode when it can see > 4
sats, revert to normal otherwise.
*** 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 environment 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.
*** 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
dumped 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.
*** 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: