From 510ae13c69d8d3d0c54a211293dde03f74df0e7d Mon Sep 17 00:00:00 2001 From: "Eric S. Raymond" Date: Sat, 21 Feb 2015 00:34:18 -0500 Subject: Update the post-3.12 to-do list. --- TODO | 114 ++++++++++++++++++++++++++++++++++++------------------------------- 1 file changed, 62 insertions(+), 52 deletions(-) (limited to 'TODO') diff --git a/TODO b/TODO index c3e647bd..93db70da 100644 --- a/TODO +++ b/TODO @@ -8,6 +8,16 @@ 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. +** Documentation ** + +We now have two different calibration procedures in the Tine 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? + ** Bugs in gpsd and its clients: *** Tracker bugs @@ -16,6 +26,58 @@ 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 + +**** In gpsmon's PPS Offset field + +Presently PPS Offset is displayed in direct mode for NMEA, SiRF, and +UBX devices. Others should probably do likewise, notably the +Motorola Oncore and Garmin drivers. + +*** 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 ** + *** Time tracking Our goal is to be independent of the system clock. @@ -69,27 +131,6 @@ However, Iván Sánchez Ortega notes: >I, for one, would like to see the secs/msecs problem solved before GPSD >embarks on the enterprise of writing TAGblocks. -*** 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 - -**** In gpsmon's PPS Offset field - -Presently PPS Offset is displayed in direct mode for NMEA, SiRF, and -UBX devices. Others should probably do likewise, notably the -Motorola Oncore and Garmin drivers. - *** Time offset debugging in gpsmon *** Hall Murray: @@ -142,37 +183,6 @@ Anthony Stirk writes on Wed May 21 06:09:00 2014: A possibility: drop the chip to low-power mode when it can see > 4 sats, revert to normal otherwise. -*** 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. - -** To do: - *** Make subframe reports available in the C API. gpsd now reports subframes when they're available, but the C client -- cgit v1.2.1