[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gpsd-dev] Getting the driver-switching logic right
From: |
Andy Walls |
Subject: |
Re: [gpsd-dev] Getting the driver-switching logic right |
Date: |
Sun, 13 Oct 2013 12:56:35 -0400 |
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
Re: [gpsd-dev] Getting the driver-switching logic right, Greg Troxel, 2013/10/13
Re: [gpsd-dev] Getting the driver-switching logic right,
Andy Walls <=
Re: [gpsd-dev] Getting the driver-switching logic right, Jon Schlueter, 2013/10/13