Re: [gpsd-dev] Fw: [PATCH] gpsd: Don't gratuitously switch drivers, if we already have a driver that matches the packet type

[Andy Walls]

Hi,

(Hopefully this makes it to the list.)

On Wed, 2013-08-07 at 23:40 -0700, Hal Murray wrote:
> address@hidden said:
> 
>    > There is also another list posting that I can't
>    > find right now, with someone with a similar problem.

The other post I was thinking of was actually this one from April 2012:

http://lists.nongnu.org/archive/html/gpsd-dev/2012-04/msg00023.html


>    I reported this issue a few years back. I have a BU-303 on a USB device
>    and after a period of time it always gets a bad packet and switches to
>    some other driver.  The period could be 1 day or 1 month.  But, it was
>    eventual.

The code path I modified was only processing known good packets.  The
path was only really a problem for drivers that handle NMEA_PACKET and
GARMIN_PACKET, since multiple drivers support those packet types:

$ cd gpsd
$ grep '.packet_type.*[^!]=' driver*.c | awk '{print $4}' | sort | uniq -c | 
sort -nr
     11 NMEA_PACKET,
      2 GARMIN_PACKET,
      1 ZODIAC_PACKET,
        [...]
      1 GARMIN_PACKET;
        [...]


There are other places in gpsd where an unrecognized packet prompts a
call to gpsd_switch_driver() (e.g. in drivers.c:generic_parse_input()).

If you believe your symptoms were induced by a bad packet, you really
need to hunt down which instance of a call to gpsd_switch_driver() is
doing the switch.  Very verbose debugging enabled when it happens might
give you enough of a clue.




>    My proposed solution was to have a configuration file to disable or
>    enable certain drivers.  Major distributions need to ship gpsd with all
>    drivers compiled in but cannot afford to have the driver switch if gpsd
>    gets one bad packet.

I would've liked a "let me force the driver type" command line option.
However, I have no need for it now.
  

> An alternative would be some sort of sticky mechanism.  If you have received 
> 10 or 100 good packets, require more than a single bad packet before 
> switching drivers.

Such hysteresis would need to be really shallow - e.g. only 2 packets of
a different type required before switching drivers.  Changing GPS unit
output modes from NMEA to TSIP, for example, shouldn't result in any
dead time really.


> It might be interesting to see what the BU-303 was actually sending at the 
> time that gpsd switched drivers.

Yeah.

Regards,
Andy