Re: [gpsd-dev] Getting the driver-switching logic right

[Andy Walls]

On Sat, 2013-10-12 at 09:07 -0400, Eric S. Raymond wrote:

[snip]
> The following table classifies all the drivers we have by what sorts of
> command strings they have and whether their packet type is uniquely
> recognizable.  It's the output of gpsd -L:
[snip]
>               c               MTK-3301
[snip]
> The capabilities are as follows
> 
> n: mode switch, b: speed switch, c: rate switch, *: non-NMEA packet type.
> 
> Here are the rules that I think will work.  Criticism invited:
> 
> 1. When you see a unique packet type for a driver with control
>    capabilities, switch to that driver.  Covers EverMore binary, Garmin
>    serial binary, Geostar binary, oncore binary, Navcom binary, SiRF
>    binary, SuperStar II binary, Trimble TSIP binary, uBlox UBX binary,
>    and Zodiac binary.

Does that include MT-3301 and other enhanced NMEA devices?  I'm not sure
what you mean when you say "control capabilities.

> 2. When you see a unique packet type with no control capabilities,
>    pass the packet to the packet parser for that driver but *do not
>    switch drivers* (that is, retain whatever driver type is currently
>    selected).  This covers AIVDM, Garmin USB binary, iTalk binary,
>    RTCM2, RTCM3, Garmin Simple Text, and the JSON slave driver.
> 
> 3. Keep a fallback pointer to the last NMEA driver that identified
>    itself (e.g. via a trigger string or probe response). The default
>    value of this fallback is Generic NMEA.  When you see an NMEA
>    packet, pass it to your fallback driver.  *Never switch drivers in
>    this case.* This rule assumes that enhanced NMEA drevices (Ashtech, Delorme
>    Tripmate and Earthmate, Furuno Electric GH-79L4, Garmin NMEA,
>    MTK-3301, OceanServer Digital Compass OS500, San Jose Navigation
>    FV180, True North, Jackson Labs Fury) identify themselves early after
>    startup.

That might be a bad assumption.  My experience with gpsd-3.7 and the
MT-3301 driver is that the Generic-NMEA driver consumes the
'event_identified' event and prevents a switch to the MT-3301 driver
(given the MT-3301 driver's logic).

I carry the following patch to gpsd-3.7 for my MT-3329 based device:

--- a/drivers.c 2013-07-23 12:37:31.527386882 -0400
+++ b/drivers.c 2013-07-23 13:05:25.320646594 -0400
@@ -1137,11 +1137,10 @@ static void mtk3301_event_hook(struct gp
     if (session->context->readonly)
        return;
     /* FIX-ME: Do we need to resend this on reactivation? */
-    if (event == event_identified) {
-       (void)nmea_send(session, "$PMTK320,0"); /* power save off */
-       (void)nmea_send(session, "$PMTK300,1000,0,0,0.0,0.0");  /* Fix interval 
*/
+    if (event == event_identified || event == event_triggermatch) {
+       (void)nmea_send(session, "$PMTK300,1000,0,0,0,0");      /* Fix interval 
*/
        (void)nmea_send(session,
-                       "$PMTK314,0,1,0,1,1,5,1,1,0,0,0,0,0,0,0,0,0,1,0");
+                       "$PMTK314,0,1,0,1,1,5,0,0,0,0,0,0,0,0,0,0,0,1,0");
        (void)nmea_send(session, "$PMTK301,2"); /* DGPS is WAAS */
        (void)nmea_send(session, "$PMTK313,1"); /* SBAS enable */
     }


Ignoring my hacks to make the MT-3301 driver suitable for my MT-3329
device, the 'event_triggermatch' change is needed to switch drivers to
the MT-3301 driver, since Generic-NMEA gets 'event_identified' first and
the MT-3301 driver never gets activated otherwise.

I guess my point is "identified early", for some value of "early",
doesn't seem to be the case for the MT-3301 driver in gpsd-3.7.

Regards,
Andy