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. ** Bugs in gpsd and its clients: *** EPH and EPV reports are zeroed too often in the TSIP driver There is some bad interaction between the policy code in libgpsd_core.c and the TSIP driver that we haven't figured out. This may be a symptom of more general problems in data management on devices that ship several sentences of fix and related data per cycle. It does not affect devices speaking SiRF or Zodiac or Garmin-binary protocol. *** PPS code is flaky, possibly due to a pthreads bug Some code attempting to terminate the PPS-monitoring thread when there is no DCD (e.g., on a USB device) seems to have tickled some kind of bug in pthreads -- termination seems to close the GPS device or otherwise do something nasty to the serial I/O layer. The default build has ENABLE_PPS off until we figure this one out. *** There's a report that RoyalTek support broke between 2.25 and 2.28 There's a report that RoyalTek support broke between 2.25 and 2.28 by David Mandala . His workaround is to condition out SiRF-II support; it works OK in NMEA mode. He has undertaken to pin down the SVN revision that broke things after OLS. ** Bugs gpsd tickles in other software *** A long-running xgps may induce a memory leak in the X server Rob Janssen writes, reporting from SuSE 9.2 + Xorg 6.8.1 + KDE 3.3: >I have found something that leaks. Not in our software, but in the X server. >But caused by xgps. > >After 3 copies of xgps ran for a couple of days, I noticed a lot of swap >is in use: > total used free shared buffers cached >Mem: 1035776 992324 43452 0 174580 54756 >-/+ buffers/cache: 762988 272788 >Swap: 2104440 1444944 659496 > >This is more than normal for my system. I noticed it when switching to a >virtual screen where mozilla is running. It took several seconds to >redraw. > >I did a "ps axu" and found these interesting lines: > >USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND >root 7004 2.5 33.6 1861128 348460 ? SL Jun19 210:46 /usr/X11R6/bi >ntp 18011 0.0 0.2 2696 2692 ? SLs Jun19 0:00 /usr/sbin/ntp >nobody 23105 0.0 0.0 7004 900 ? Srob 28724 0.2 0.1 7084 1968 pts/18 S Jun22 9:03 /home/rob/src >rob 28744 0.3 0.1 7084 2040 pts/18 S Jun22 14:52 /home/rob/src >rob 28759 0.2 0.1 7084 1936 pts/18 S Jun22 9:44 /home/rob/src > >So the gps programs were not consuming that much memory. >I still stopped the 3 xgps programs (the last three in this list) and then >the X server showed: >root 7004 2.5 2.2 367140 23424 ? SL Jun19 210:49 /usr/X11R6/bi > >So there certainly is a relation here. >Unfortunately I have zero knowledge about X programming. I would guess >some kind of session or operation is started and never ended, or something >is said to be saved, but apparently it remains related to the specific >window because the X server neatly frees it once the program disconnects. But Rob's xgps memory leak doesn't reproduce on a stock Fedora Core 3 system. ESR tested for this in the simplest possible way, by doing system("free t") at the end of each handle_input() call. ** To do: *** SiRF firmware uploader Chris Kuethe has shipped a 0.0 alpha version. It is not yet resolved whether SiRF Technology will allow us to ship the binary loader code needed to actually use it. *** RINEX-format dumping of raw satellite data It would be useful to be able to extract RINEX-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. *** 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_mag() anyway? Should that be made available as an output mode of rtcmdecode and documented? 5) Python libraries must grok RTCM dump format. 6) Extend the test framework so we can verify RTCM service. 7) Get rid of the -d option by hacking open_device() so that when it sees a command-line option of the form server:port (with no embedded backslashes) it opens a socket to read from that server. Now any GPS-packet and RTCM data sources given on the command line can be remote as well as local. 8) 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 GPMRC/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 (?) *** Subsecond polling gpsd relies on the GPS to periodically send PVT reports to it. Most GPSes send PVT reports once a second. No GPS I am aware of allows you to set a cycle time of less than a second. This is because at 4800bps, a full PVT report takes just under one second in NMEA. At 50km/h (31mi/h) that's 13.8 meters change in position between updates, about the same as the uncertainty of position under typical conditions. There is, however, a way to sample GPSes at higher frequency. SiRF chips, and some others, allow you to shut down periodic notifications and poll them for PVT. At 57600bps we could poll a NMEA GPS 16 times a second, and a SiRF one maybe 18 times a second. Is this worth doing? Maybe. It would reduce fix latency, possibly to good effect if your GPS is in motion. Opinions? Calculations? *** 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: