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. ** In the SiRF driver, get leap seconds from almanac data Currently we're using a fixed 13-leap-second offset to convert GPS time to UTC. This is wrong for the long term. We should compute it from message 8 subframe data. Gary Miller writes: >subframe 4 page 18 word 9 byte 1 in the ephemeris contains the leap seconds, >details here: > http://home-2.worldonline.nl/~samsvl/nav2eu.htm ** Set FIFO threshold to 1 to reduce jitter in serial-message times This can matter if you're using gpsd as a time reference. Rob Janssen : >> Setting the FIFO threshold to 1 can improve things. > > How does one do this? #include use ioctl TIOCGSERIAL to get a struct serial_struct filled with the settings of the UART, modify what you want, and write it back using ioctl TIOCSSERIAL. Hmmm, now that I check this in the kernel source it does not seem to be possible to set the receive FIFO size from a user program, only the transmit FIFO. However it appears that setting it to 1 will also disable the receive FIFO. You'll have to experiment. ** 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. There has been some debate about going to the cross-platform libusb library to do device scanning, but this would create a complex dependency that gpsd doesn't now gave, and bring more complexity on board than is probably desirable. ** 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. SiRF binary reports HDOP, SiRF and other NMEA devices report HDOP/VDOP/PDOP. C. Only Garmin devices report estimated position errord 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 gpsd.h. See the comment near the definition of UERE. 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. 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. ** Multisession code needs to be tested. Each client is at any given time listening to a channel attached to a specified device. It does not see messages from other devices. The F command now has the semantics "add a GPS to gpsd's internal search list (and switch this client to use that GPS)". The new 'K' command lists available devices. Soon, it will remove a GPS from the GPS list (hotplug scripts can use it to cue gpsd on a remove event). Tentative answers: (1) The default GPS is the last one plugged in. (2) Nothing. It should just get an offline indication. ** 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. 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? ** HAL integration David Zeuthen is the lead programmer on the Hardware Abstraction Layer. HAL aims to be at least two things: (1) An attempt to centralize and/or coordinate device probes and hardware autoconfiguration. (2) A standard interface for reading and writing hardware configuration info on D-BUS. David wants to include GPSes in HAL. The functional implication is that gpsd should publish PVT and status information on the D-BUS through the HAL libraries. Here is the state of our exchange about publishing PVT data: > > So, should I compose a 'gps' namespace? > > Yeah, that would be helpful - the hal spec is a little bit out of date > but basically your properties are key/value pairs where keys are ASCII > strings and the values assumes one of the following types > > o int32 > o uint64 > o double > o boolean > o UTF-8 string > o List of UTF-8 strings > > I think it would be pretty easy to write this code, it is somewhat > exemplified here > http://cvs.freedesktop.org/hal/hal/hald/linux2/addons/addon-hid-ups.c?rev=1.2&view=auto > > So, basically, it would go like this > > dbus_error_init (&error); > if ((conn = dbus_bus_get (DBUS_BUS_SYSTEM, &error)) == NULL) > goto out; > if ((ctx = libhal_ctx_new ()) == NULL) > goto out; > if (!libhal_ctx_set_dbus_connection (ctx, conn)) > goto out; > if (!libhal_ctx_init (ctx, &error)) > goto out; > > dbus_error_init (&error); > if ((gps_udis = libhal_manager_find_device_string_match ( > ctx, "serial.device", your_device_file_for_the_gps, > &num_udis_found, &error)) == NULL || num_udis_found != 1) > goto out; > > libhal_device_set_property_double (ctx, udi, "gps.longitude", the_longitude); > libhal_device_set_property_double (ctx, udi, "gps.latitude", the_latitude); > /* and so on */ > libhal_device_add_capability (ctx, udi, "gps"), &error); > > You probably also want to rate limit how often you write these properties, > e.g. only every few seconds or so. You can then check this with > hal-device-manager. We are also discussing hotplug integration. The issue there is that HAL wants to centralize all device probing into itself so that devices see as few probes as possible and the probes don't step on each other Playing nice in the HAL world may require that we replace our hotplug script with launcher code that lives in the HAL daemon. ** 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? Local variables: mode: outline paragraph-separate: "[ ]*$" end: