$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 . The list of bugs exposed by gpsd in other software has moved to . ** 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 at True North Technologies and tell him he needs to reverse his refusal to send us an eval unit. ** To do: *** 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 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 funcionality 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. *** send/expect for the NMEA driver initializer We've had one report of a GPS, the Garmin GPS-10, which gpsd puts in a bad state because the device chokes on having all of our NMEA probe strings shoved at it without having time to respond. A simple send-expect function (ship given string, wait until specified reply arrives or time out) would solve this problem and might help avoid problems with other GPSes we haven't encountered yet. *** 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. *** RTCM support. We have an RTCM packet decoder, and untested scratch code to serve RTCM packets to port 2101. Here's the plan for the rest of it: 1) Inversion needs to be done somewhere in the encoding logic. 2) Wolfgang's decoder-hardening patches. 3) Test productions. I have one that tests dumping and one that uses passthrough mode to test that pack() and repack() are inverse. We should have an undumping torture test. 4) What about rtcm_output_magnavox() anyway? Should that be made available as an output mode of rtcmdecode and documented? 5) Extend the test framework so we can verify RTCM service. 6) Generate and broadcast RTCM corrections from an attached device? Might not be possible -- appears to need nanosecond timing. *** 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. ** Future features (?) *** iTalk support There is a minimally functional driver for the Fastrax iTalk3 protocol. It is still very much a work in progress. It is now compiled in by default so that we can collect bug reports. Version 3 of iTalk is not backwards compatible; we do not anticipate supporting previous versions unless someone requests it and is able to provide us hardware. *** Navcom support Initial support for the Navcom binary protocol has been committed to allow for in-tree development. It is compiled in by default. *** UBX support There is a minimally functional driver for the uBlox UBX protocol. It is still very much a work in progress. It is now compiled in by default so that we can collect bug reports. *** 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 : 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: