[gpsd-dev] SiRF III and IV problems

[Eric S. Raymond]

In mid-November Gary Miller reported that direct baud-rate changes
attempted via gpsctl on the SiRF IV don't work.

In March, Hal Murray reported similar failures with a GlobalSat
BU-353S4.  He said "It often ends up non-responsive: Neither gpsmon
nor gpsd will talk to it. Power cycle fixes things."

On April 21st Gaël Griffon <address@hidden> also reported 
problems with the GlobalSat BU-353-S4.  He reported good function in NMEA
mode.

I believed that at least part of what was going on here is that the SiRF IV
doesn't cope well with receiving a parameter change request before it
has shipped the ACK for any previous one.

Accordingly, on November 18 and 19 I added code to the SiRF driver
that watches for commmand ACKs and prevents sending control messages
when this is attempted.  I observed correct initialization on a SiRF
III.

But in late February Michael Tatarinov reported (tracker bug #41719) that
SiRF III was broken.  He seemed to be trying to say that it had the same
problem I thought I had fixed on Nov 18-19, but I have trouble
parsing his English.  He posted a workaround patch at

        http://z.grey.net.ru/gpsd-SiRF-workaround.patch

This patch disabled my changes of Nov 18-19 but added code to reduce the
volume of sentences shipped by the device.

This morning I ran some tests with the repository head version against
the following devices:

SiRF-II       BU-353
SiRF-III      BU-355
SiRF-IV       BU-353S4

With SiRF III beginning in NMEA mode: Using gpsmon, successfully
switched to binary mode and then from 4800bps to 9600ps.  However, an attempt
to change speed with gpsctl in direct mode then failed waiting for ACK.

I then applied the rest of Michael's patch, reverting my ACK-waiting
code.  Following this, SiRF-III speed changes worked from
both gpsmon and gpsctl. I therefore marked tracker bug #41719 fixed.

For completeness, I tested with an older SiRF-II. Both gpsmon
and gpsctl direct speed changes worked. 

Testing with SiRF IV: gpsmon speed changes work, but gpsctl speed
changes in direct mode do not.

I am not seeing failure to respond from the SiRF-IV under any
circumstance. Perhaps Michael's rate-limiting 

While investiating this, I discovered yet another SiRF-IV quirk. The BU-353S4
resets to 4800bps every time it is unplugged.  This is *not* true of earlier
SiRFs (I tested it immediately with the SiRF-III BU-355).

This transcript shows gpsctl -D 5 -f -s 19200 /dev/ttyUSB0 in action.

gpsctl:PROG: SiRF: Setting DGPS control to use SBAS...
gpsctl:WARN: SiRF: warning, write of control type 85 while awaiting ACK for a6.
gpsctl:PROG: SiRF: Writing control type 85:
gpsctl:IO: => GPS: a0a20007850100000000000086b0b3
gpsctl:PROG: SiRF: ACK 0x0b: 98
gpsctl:PROG: SiRF: Setting SBAS to auto/integrity mode...
gpsctl:PROG: SiRF: Writing control type aa:
gpsctl:IO: => GPS: a0a20006aa000100000000abb0b3
gpsctl:PROG: SiRF: ACK 0x0b: 88
gpsctl:PROG: SiRF: Enabling PPS message...
gpsctl:PROG: SiRF: Writing control type a6:
gpsctl:IO: => GPS: a0a20008a60034010000000000dbb0b3
gpsctl:PROG: SiRF: ACK 0x0b: a6
gpsctl:PROG: SiRF: Disabling subframe transmission...
gpsctl:PROG: SiRF: Writing control type 80:
gpsctl:IO: => GPS: 
a0a2001980000000000000000000000000000000000000000000000c00008cb0b3
gpsctl:PROG: SiRF: ACK 0x0b: a6
gpsctl:PROG: SiRF: disable MID 7, 28, 29, 30, 31...
gpsctl:PROG: SiRF: Writing control type a6:
gpsctl:IO: => GPS: a0a20008a60540000000000000ebb0b3
gpsctl:PROG: SiRF: ACK 0x0b: 85
gpsctl:PROG: SiRF: ACK 0x0b: aa
gpsctl:PROG: SiRF: NAK 0x0c: a6
gpsctl:PROG: SiRF: ACK 0x0b: 80
gpsctl:PROG: SiRF: ACK 0x0b: a6
gpsctl:PROG: /dev/ttyUSB0 looks like a SiRF at 4800.
/dev/ttyUSB0 identified as a SiRF at 4800 baud.
gpsctl:PROG: SiRF: sirf_speed(19200,N,1)
gpsctl:PROG: SiRF: Writing control type 86:
gpsctl:IO: => GPS: a0a200098600004b000801000000dab0b3
gpsctl:PROG: /dev/ttyUSB0 change to 19200N1 succeeded

After it's done, baud rate has *not* changed from the initial 4800
But note that when that speed-change command is issued, all previous
commands *have* been acked.

So the theory that the SiRF IV bugginess relates to a speed change 
being issued before previous commands seems to be busted.

Before I probe this further, I would appresiate it if others would
check my observations about the current repository head version.
Specifically,

* Both gpsmon and gpsctl direct-mode speed changes work on SiRF-II and
  SiRF-III.

* Direct-mode gpsmon speed changes work on SiRF-IV, but direct-mode 
  gpsctl speed changes do not.

* There are no longer hang problems at SiRF-IV startup.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>

"One of the ordinary modes, by which tyrants accomplish their purposes
without resistance, is, by disarming the people, and making it an
offense to keep arms."
        -- Constitutional scholar and Supreme Court Justice Joseph Story, 1840