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 thenm again. ** Bugs: *** No data from BU-303? Roeland Th. Jansen was reporting no data from a BU-303 running under SuSE 9.9. I have a BU-303 and it's working fine. I don't know if he has checked out SVN head recently. ** To do: *** Hotplug interface problems The hotplug interface works pretty nicely for telling gpsd which device to look at, at least on my FC3 Linux machines. The fly in the ointment is that I'm using a deprecated version of the interface, the old-style /etc/hotplug version with usermap files. It is unlikely this interface will be dropped by distro makers any time soon, because it's supporting a bunch of popular USB cameras. Still, it would be nice not to be using a deprecated interface. I tried moving to the new-style /etc/hotplug.d interface, but I ran into a nasty race condition. My hotplug agent got woken up on a USB add event as it should, but in the new interface the creation of /dev/ttyUSB* can be delayed arbitrarily long after the wakeup event. Thus, it may not be there when gpsd goes to probe it unless I busy-wait in the script. Ultimately this should all be done through udev. The problem is that at the current state of udev, we'd need to do it through a script that would fire every time a tty activates. Because of virtual consoles firing up at boot time, this would introduce significant boot lag. This would be antisocial and I'm not willing to do it, so udev needs to grow better filtering before I'll use it. When and if udev supports HOTPLUG and ACTION keys, this will work: # The Prolific Technology 2303 (commonly in tandem with SiRF chips) BUS="usb" SYSFS{vendor}="067b" SYSFS{product}="2303" \ NAME="gps%e" \ HOTPLUG="/usr/bin/gps-probe" # FTDI 8U232AM BUS="usb" SYSFS{vendor}="0403" SYSFS{product}="6001" \ NAME="gps%e" \ HOTPLUG="/usr/bin/gps-probe" # Cypress M8/CY7C64013 (DeLorme uses these) BUS="usb" SYSFS{vendor}="1163" SYSFS{product}="0100" \ NAME="gps%e" \ HOTPLUG="/usr/bin/gps-probe" More generally, the hotplug code we have is Linux-specific. OpenBSD (at least) features a hotplug daemon with similar capabilities. *** The mess near error modeling One of my goals has been to report an uncertainty along with every dimension of PVT, so that the return from the GPS actually (and realistically) describes the volume of kinematic state space within which it is located at 1-sigma or 66% confidence. (Because the errors are taken to be normally distributed, we can square the error to get 2-sigma or 95% confidence.) There are several problems with this. A. I don't know how to derive or estimate uncertainty of time in the general case. There are clock drift and bias fields in the SiRF binary protocol, but I don't know how to interpret these. Does anyone? B. Only Garmin devices report estimated position uncertainties in meters. They won't say what the confidence interval is, but it is generally believed to be 1-sigma. See . Here is what I am presently doing in the new E command: 1. I pass up the Garmin PGRME fields (uncertainty in meters) if they're available. 2. Otherwise, I apply the error model described in the HACKING dociment. What non-Garmin GPSes will return in the E command is UERE multiplied by PDOP/HDOP/VDOP. Annoyingly, SiRF binary mode only offers HDOP, one respect in which it is functionally inferior to SiRF NMEA. We compute VDOP and PDOP using an algorithm supplied by SiRF. I don't know, because my sources didn't give, the confidence level associated with the range uncertainties in gpsd.h. My educated guess is that they are 1-sigma (66%), and that's what the gpsd documentation now says, but it needs to be confirmed. This area needs some attention from somebody who cares a lot about GPS accuracy and is willing to do research on error budgets to pin down the numbers and confidence levels. *** 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? Local variables: mode: outline paragraph-separate: "[ ]*$" end: