gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] Modifying (severly) hardware.html


From: Eric S. Raymond
Subject: Re: [gpsd-dev] Modifying (severly) hardware.html
Date: Wed, 15 Apr 2015 06:31:50 -0400
User-agent: Mutt/1.5.23 (2014-03-12)

Hal Murray <address@hidden>:
> I guess I have a 3339.  (I was wondering.  It's been sitting on my to-do pile 
> for a while.)
> 
> >From gpsmon log after I typed "i":
> 
> $PMTK705,AXN_2.31_3339_13101700,5632,PA6H,1.0*6B^M
> $PMTK001,320,3*31^M
> $PMTK001,300,3*33^M
> $PMTK001,314,3*36^M
> 
> $PMTK001,301,3*32^M
> $PMTK001,313,3*31^M
> $PMTK001,424,1*30^M
> 
> Is that enough to figure out how to support the 3339?  If not, is there 
> something simple I can type to get more info or would it be a lot easier if 
> you had access to it?  I think the data sheet is on the breakout board web 
> page.

The MTK3301 driver contains this:

    .trigger        = "$PMTK705,",      /* firmware release name and version */

That means that, in theory, gpsd should notice that version report as
an indication that it's looking at an MTK device. The way it's supposed to work
is this:

1. gpsd's hunt loop cycles through RS232 parameter combinations looking for
a recognized packet type.

2. gpsd achieves sync with the MTK when it recognizes a checksummed NMEA packet.

3. gpsd issues a device-type probe, same thing the gpsmon 'i' code ships.

4. The probe elicits the packet burst above.

5. One each NMEA packet assembled, the generic NMEA driver looks at all
   driver trigger strings.

6. It sees $PMTK705, and thereby knows to switch to the MTK3301 driver.

What we need to do is figure out where in that chain gpsd is dropping the ball.
Running at -D 5 might prove enlightening.

> Another thing we need is a list of USB chips that do/don't support
> PPS.  How does that very with OS?

They're independent. There are two variables:

1. Does the serial-to-USB chip pass PPS events handed to the serial
side out the USB side as interrrupt packets?  The PL2303 does. FTDI
chips do not.  Chip-vendor documentation of this point varies from
shitty to nonexistent, usually the latter.

2. Does the OS have the capability to latch on the USB packets
represented by handshake-line state changes produced in the RS232
emulation?  Concretely, can it do TIOCMIWAIT or RFC2783?
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]