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

[Andy Walls]

On Mon, 2013-10-14 at 18:34 -0400, Eric S. Raymond wrote:
> Andy Walls <address@hidden>:
> > 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.
> 
> Please test git head.  I took your fix of responding to the triggermatch
> event; I'd like to know if that suffices.

I will test on Friday.


> Is there any way to get a 3229 to distinguish itself from a 3301?

Maybe with a $PMTK605 Query_Release and $PMTK705 Date_Release response.
But that response only has obtuse firmware version number strings that
don't include the device model.

FWIW, the manual for my Trimble Condor device (which I suspect is a
custom MT-3329 device) is here:

http://www.trimble.com/embeddedsystems/condor-gps-module.aspx?dtID=documentation

See pages 123-140 of the Users guide for the proprietary NMEA sentences.
Notice the MT-3329 block on page 140. :)


> If there is maybe we could mainstream your setup changes too.

Actually the MT-3329 will probably gracefully accept the existing
sentences the MT-3301 emits.

1. $PMTK320 is unsupported, so the unit should respond with a NAK
$PMTK001 sentence to it.  I will need to test.

2. The difference in $PMTK300 is the two '0.0' vs. '0'.  I will need to
test if the unit will accept '0.0' values.

3. For $PMTK314, I had tested my unit previously. The unit will silently
accept enabling periodic reporting of messages that aren't supported.
It simply doesn't generate reports for the unsupported messages.  So my
change there is unnecessary.

Regards,
Andy