path: root/TODO

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 <gpsd@xs4all.nl>:
>> Setting the FIFO threshold to 1 can improve things.
>
> How does one do this?

#include <linux/serial.h>

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 <http://gpsinformation.net/main/epenew.txt>.

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.

** 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: