path: root/TODO

$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
<http://gpsd.berlios.de/hacking.html>.

** 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 
<bpowell@tntc.com> at True North Technologies and tell him he needs
to send us an eval unit.

*** Support for Garmin USB binary in serial mode is currently broken

We rewrote the Garmin USB binary support in a different mode to
work around a bug in the Linux 2.16 tty layer.  Unfortunately the new
driver has some kind of bad timing interaction with the kernel
(probably due to another kernel bug) and only works reliably at -D6 or
up.  Some users report no problems at all. If this were a hard error
it would be easier to fix.

The new driver also requires a tool to switch between binary and NMEA
modes.  There is experimental untested code to do this via gpsctl, but
it could do anything including make bats fly out of your nose.

The new Garmin driver and gpsctl should be much more solid in the next
point release.

*** 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 <davidm@them.com>.  His workaround is to condition out
SiRF support; it works OK in NMEA mode.  The Royaltek died in an
accident, so we're stuck until someone else can test this.

** Bugs exposed by gpsd in other software

*** Distro-dependent problems with gpsd startup.

See <http://bugs.gentoo.org/show_bug.cgi?id=132288>.  This shows
up on other distributions as well, but not under Fedora Core.
The Gentoo problem can be fixed by creating a /var/run/usb directory;
this fix may apply to other distributions as well.

*** rtcm.c triggers an optimizer bug in some versions of gcc

The rtcm.c file confuses the gcc-3.4.[23] optimizer at -O2 level,
making it generate incorrect code.  Removing -O2 from the
compilation flags works around the problem.

*** Compiling with --enable-max-devices=1 may trigger a gcc optimizer bug

At gpsd revision level 3365, compiling with --enable-max-devices=1 has
been observed to trigger an optimizer bug in gcc 4.1.0 20060304 (Red
Hat 4.1.0-3).  The symptom is a for-loop termination condition not
causing an exit, leading to a core dump.  Removing -O2 from the
compilation flags works around the problem; upgrading to gcc 4.1.1
20060525 (Red Hat 4.1.1-1) solves it.  Other reports indicate this
bug was introduced sometime after gcc 4.0.2 20051125 (Red Hat 4.0.2-8).

*** Multiple definitions of symbol _gpsd_report due to libtool bug

Some people building gpsd get 'multiple definitions of symbol _gpsd_report'
as a warning.  This seems to be a result of two bugs in libtool, one
of which masks the other on i386. gpsd_report() is indeed multiply
defined, the problem is that libtool generates libgps.o where it 
should generate -lgps and *all* instances (rather than just the first
to be incorporated by other linkage demands) are linked in.

*** The 2.3.0-beta version of OpenMotif shipped with Fedora Care 5 is buggy

xgps tickles a bug, described at http://bugs.motifzone.net/ as bugs
1330 and 1331 and marked FIXED, in some versions of OpenMotif.  The
symptom is that the satellite-data window in xgps is too small.  Avoid
by either upgrading to 2.3.0-0.1.9.3 (or later) or dropping back to a
stable version like 2.2.2.  Alternatively, remove OpenMotif and
install lesstif. For gpsd's purposes, lesstif is a completely
compatible drop-in replacement.

*** Linux pl2303 driver can lock up when device is read at an unexpected speed

Michael R. Davis reports "If you read from the device at the wrong
rate (e.g. cat /dev/xxx) it will lock up.  On openwrt it required a
hard reboot." Details are at 

     http://gpsd.davisnetworks.com/bin/view/Main/FreezeBugPL2303

Related driver flakiness may explain some failures to hunt correctly.

*** gpsd build may break on 64-bit systems running Fedora Core 5

The problem may be be caused by the old ld (binutils-2.15.92.0.2-18)
being incompatible with gcc 4.1.0 on a 64-bit system. Updating to
binutils 2.16.1 or later avoids it.

***  Python socket library barfs on IPV6 notation in the /etc/hosts file

Robert J.Berger <rberger@ibd.com> reports:
"Until I changed the line in /etc/hosts from:

::1    localhost.localdomain   localhost

to:

127.0.0.1       localhost.localdomain   localhost

gps.py would fail when trying to open the socket connection to the gpsd:

   File "/usr/local/bin/spGps.py", line 198, in __init__
     self.connect(host, port)
   File "/usr/local/bin/spGps.py", line 237, in connect
     raise socket.error, msg
socket.error: (111, 'Connection refused')

and gpsprof would fail with:
# gpsprof | gnuplot -persist
gpsprof: gpsd unreachable.

This is with Python 2.4.4 under Red Hat Linux, kernel version not reported.

** To do:

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

*** Integrate udev support in the RPM installation

Currently gpsd includes udev support that seems to work in the source
build, but the RPM still installs the old-style hotplug support.
Fixing this is not urgent, as the old-style support will likely
be retained for compatibility for a long time, but it should
get done someday.

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

*** 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) 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's an iTalk driver, but it's an experiment written from the spec
that hasn't been tested.  It's not compiled in by default.

*** 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 <http://www.linuxsa.org.au/tips/time.html>:

    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: