[Thumbgps-devel] USB handshake signals and Linux

[Eric S. Raymond]

tz <tz2026 at gmail.com>:
> Skytraq has a number of unique commands that identify the chipsets.  So do
> MTK and Garmin.

That is true and fortunate.
 
> Right now the udev for gpsd gets it wrong by including the generic FTDI
> vendor id for one gps, so plugging in my ftdi arduino/breakout starts up
> gpsd and it probes (same error in upowerd - I filed a bug report with
> fedora).   It thought my SkyTraq was this unit.

Alas, this can't be fixed, due to lossage in the USB standard.  I'll explain.

In an ideal world, there would be a USB device class for GPSes and GPSD
would key on that, ignoring all other devices.

The root of the problem is that there is no USB device class for GPSes. There
isn't even one for USB-to-serial adaptors.  So the USB class that GPSes report
is the catch-all 0F = vendor-specific, same as your Arduino widget.

As a workaround, GPSD picks up devices that report USB vendor-id/product-ID
pairs associated with USB-to-serial adapters like the PL2303 that are
commonly used for GPSes.  Because this is in fact the overwhelimingly 
most common use for USB-to-serial adapters, this bodge works for almost
everyone almost all the time.

You happen to be one of the 1% exceptions.  Sorry about that.  It means 
you have to start GPSD by hand and can't use udev.  There isn't a better
solution, the information to implement one is just not there.

> I have the PPS hooked to the CTS pin, but gpsd has to be recompiled to
> enable pps or change pins.  This should be configurable at runtime.

GPSD has no runtime configuration.  Even the use of command-line switches
is minimized. There is exactly one that sets an operating mode, and that is
only because without it certain broken Bluetooth devices would be bricked.

GPSD has no runtime configuration because my design philosophy is that
it should autoconfigure itself to meet conditions.  It autobauds and 
automatically recognizes the packet protocols it supports.  I removed
the command-line switches for device type and baud rate in 2005 and they
are not coming back.

For the bufferbloat deployment, GPSD will be compiled with 1PPS enabled.
I might change that to be the default - it's hard to imagine circumstances
under which that could go wrong.

> You still have the same problem using any other gps for bufferbloat - gpsd
> will attempt to sync the time via ntpshm based on any NMEA stream at the
> last sentence in a group.

Not the last sentence. GPSD detects the start of cycle sentence of your
device by watching a couple of cycles go by.  thereafter, it knows to 
associate current GPS time with the saved arrival time of the first character
in the start packet of the current reporting cycle.

>         You will need some tweaking to make it not do
> this, or reject other gps units, or otherwise indicate that unless you are
> using one of our 'blessed' units the time won't be accurate.  'Blessed'
> might mean PPS, but how do we certify it?

The current logic is simple.  If GPSD sees 1PPS, then it feeds NTPD.  
Otherwise not.  I don't think it needs to be more complicated than this.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>