TODO

   1 This is the gpsd to-do list.  If you're viewing it with Emacs, try
   2 doing Ctl-C Ctl-t and browsing through the outline headers.  Ctl-C Ctl-a
   3 will unfold them again.
   4
   5 For contribution guidelines and internals documentation, please see
   6 <http://gpsd.berlios.de/hacking.html>.
   7
   8 The list of bugs exposed by gpsd in other software has moved to
   9 <http://gpsd.berlios.de/upstream-bugs.html>.
  10
  11 ** Bugs in gpsd and its clients:
  12
  13 *** Tracker bugs
  14
  15 See the GPSD bug tracker at https://developer.berlios.de/bugs/?group_id=2116
  16 but don't be surprised if it's empty or very sparse.  Our rate of new defects
  17 per month is quite low.
  18
  19 *** Driver issues
  20
  21 **** gpsctl -b should work on UBX, but does not.
  22
  23 Presently this means there's no way to kick a UBX into returning
  24 binary data.
  25
  26 ** Ports
  27
  28 *** Windows port
  29
  30 Partially complete. David Ludlow <dave@adsllc.com> is working on it.
  31
  32 ** To do:
  33
  34 *** Bump MAXCHANNELS to support GPS/GLONASS devices
  35
  36 This will require a major soname bump. Probably goes with the API
  37 changes on the Future page. Here's a test log for a GPS/GLONASS device,
  38 the Geostar Geos 1M: <http://old.nabble.com/new-gps-report-to29115582.html>.
  39
  40 *** Write advanced features for TNT Revolution device
  41
  42 The baud-rate switcher in the TNT driver needs to be tested.
  43
  44 gpsmon could support a number of TNT configuration commands, including
  45 unit changes. See http://gpsd.googlecode.com/truenorth-reference.pdf
  46 for possibilities.
  47
  48 Jon Schlueter has one of these on a flock machine, so testing
  49 shouldn't be difficult.
  50
  51 *** Finish gpssim
  52
  53 It's blocked on skyview computation.
  54
  55 *** Complete and test the speed/parity/stopbit methods in the drivers
  56
  57 These are used for the '?DEVICE' command.  All work for 8N1.
  58
  59 **** superstar2: not implemented (driver is unfinished)
  60 **** italk: not implemented (but could be)
  61 **** tsip: speed tested, parity and stop-bit switching not tested
  62 **** sirf: speed tested, parity and stop-bit switching not tested
  63 **** evermore: speed tested, rejects parity/stopbit setting
  64 **** ubx: fully implemented, parity and stop-bit switching not tested
  65 **** zodiac: fully implemented, not tested
  66 **** navcom.c: speed tested, rejects parity/stopbit setting
  67
  68 SiRF, UBX, TSIP, and even Zodiac can support non-8N1 modes; these need
  69 to be tested.
  70
  71 *** Command to ship RTCM corrections to a specified device
  72
  73 At the moment, if a GPS accepts RTCM corrections and they are
  74 available, gpsd ships them to the serial device from which the GPS is
  75 reporting fix data.  Some GPSes have auxiliary ports for RTCM;
  76 there should be a (privileged) command to redirect RTCM connections.
  77
  78 *** Per-driver restore of changed config settings on exit.
  79
  80 This is a solved problem for generic NMEA, EverMore, TripMate,
  81 EarthMate, TNTC, Zodiac, and RTCM104 drivers (if only because they
  82 don't configure any device settings).
  83
  84 The SiRF driver now restores NMEA when necessary.  It also restores
  85 some (but not all) of the things it tweaks in binary mode -- at the
  86 moment, just the Navigation Parameters from message 0x13.  With more
  87 work, we should be able to do a full revert.
  88
  89 The TSIP driver changes its per-cycle sentence inventory and thus
  90 needs some state-restore logic.  This can be done; the same packet 0x35
  91 we use to configure it can be sent in a no-argument mode to query
  92 the current sentence mix for later restore.
  93
  94 The FV18 changes its per-cycle sentence inventory to include GSAs. It
  95 is possible to query that inventory, though we don't have code to do
  96 it yet.
  97
  98 Garmin devices are a mess.  We reconfigure those heavily, and we
  99 don't know if there's any way to capture their configuration state
 100 before we do it.
 101
 102 The iTrax02 driver sets SYNCMODE to start navigation messages without
 103 checking to see if it's already on, and stops navigation methods on
 104 wrapup.  It also forces the set of sentences issued.  There doesn't
 105 seem to be any way to query these settings.
 106
 107 *** Industry-standard format dumping of raw satellite data
 108
 109 It would be useful to be able to extract RINEX (or some other standard)
 110 format data from any GPS device that can report pseudoranges etc.  This
 111 belongs in the daemon because the device drivers are already doing the
 112 packet-cracking needed to get the data off the chips.
 113
 114 Several commodity chipsets (ANTARIS, iTrax3, SiRF and Trimble) readily
 115 output enough data to make this a chore, rather than a hard problem.
 116
 117 It has been suggested one way to do this is to have a generic structure
 118 in memory and corresponding output message with clock, doppler carrier
 119 phase and pseudoranges. This message is then reformatted by a client
 120 program. There are numerous formats for this information, and it would
 121 be easier to adapt to new formats if the formatting and use was handled
 122 by something other than the gpsd daemon. Currently the RT-IGS format is
 123 looking like the favorite for implementation; it's a fairly lightweight
 124 protocol, flexible enough to handle all the quantities required, and it
 125 is actually in use in production reference networks. RT-IGS is also a
 126 packet-oriented format, rather than a file-oriented format like RINEX.
 127
 128 *** RTCM3 support.
 129
 130 Previous plans for more RTCM2 support seem to have been overtaken by
 131 events, e.g. the world moving to RTCM3. We have support for analyzing
 132 RTCM3 messages, but it's entirely theoretical - written from the
 133 standard.  We need to find a pair of files consisting of a
 134 representative set of RTCM3 sentences and some sort of ASCII dump of
 135 them so we can test whether our analyzer gets all the bitfield
 136 boundaries right.
 137
 138 ** Future features (?)
 139
 140 *** Support for more survey / professional / up-scale receivers.
 141
 142 Devices such as the Javad JNSCore, Hemisphere Crescent, Septentrio
 143 AsteRx and PolaRx, NovAtel Superstar2 and OEMV, Thales (Magellan
 144 Professional) AC12 and DG14 would all be welcome. Of course, these
 145 are not $50 usb mice...
 146
 147 *** Audio cues in the client when the fix status changes
 148
 149 Calum writes:
 150 >Is it possible to add functionality (with a switch to enable it to
 151 >avoid annoying those that don't want it) so that beeps indicate NO
 152 >FIX, FIX, and OFFLINE status changes?
 153 >
 154 >For example - I run cgps and my laptop battery doesn't always supply
 155 >my PS2 port-powered GPS device with enough power, and it goes into
 156 >OFFLINE mode. As I can't drive, and check my laptop all the time, if
 157 >it emitted 5 1 second beeps when it went OFFLINE, it would be a handy alert.
 158 >
 159 >Similarly, a PCMCIA "eject" 2 beeps for NO FIX, and a PCMCIA "happy" 2
 160 >beeps when it gets a fix again?
 161 >
 162 >Or something like that.
 163
 164 This is a good idea for supporting hands-free operation, e.g. while driving.
 165
 166 It would be an easy first project for somebody who wants to get into
 167 the client code.
 168
 169 *** Set the system time zone from latitude/longitude
 170
 171 If we're going to give gpsd the capability to set system time via
 172 ntpd, why not let it set timezone as well?  A good thing for hackers
 173 travelling with laptops!
 174
 175 The major issue here is that I have not yet found code, or a
 176 database, that would allow mapping from lon/lat to timezone.
 177 And the rules change from year to year.
 178
 179 Actually this should be built as a specialized client, as some
 180 people won't want it.
 181
 182 From <http://www.linuxsa.org.au/tips/time.html>:
 183
 184     The timezone under Linux is set by a symbolic link from
 185     /etc/localtime[1] to a file in the /usr/share/zoneinfo[2] directory
 186     that corresponds with what timezone you are in. For example, since I'm
 187     in South Australia, /etc/localtime is a symlink to
 188     /usr/share/zoneinfo/Australia/South. To set this link, type:
 189
 190     ln -sf ../usr/share/zoneinfo/your/zone /etc/localtime
 191
 192     Replace your/zone with something like Australia/NSW or
 193     Australia/Perth. Have a look in the directories under
 194     /usr/share/zoneinfo to see what timezones are available.
 195
 196     [1] This assumes that /usr/share/zoneinfo is linked to /etc/localtime as it is under Red Hat Linux.
 197
 198     [2] On older systems, you'll find that /usr/lib/zoneinfo is used
 199     instead of /usr/share/zoneinfo.
 200
 201 Changing the hardlink will, of course, update the system timezone for
 202 all users.  If I were designing this feature, I'd ensure that the
 203 system timezone can be overridden by a user-set TZ, but I don't know
 204 if it actually works that way.
 205
 206 If I'm reading the tea leaves correctly, this functionality is actually
 207 embedded in the GCC library version of tzset(), so the same method will
 208 work on any system that uses that.
 209
 210 Problem: system daemons use the timezone set when they start up. You
 211 can't get them to grok a new one short of rebooting.
 212
 213 Sources:
 214
 215 Sources for Time Zone and Daylight Saving Time Data
 216 http://www.twinsun.com/tz/tz-link.htm
 217
 218 Free time-zone maps of the U.S.
 219 http://www.manifold.net/download/freemaps.html
 220
 221 Local variables:
 222 mode: outline
 223 paragraph-separate: "[  \f]*$"
 224 end: