[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[gpsd-dev] SiRF IV flakiness explored
From: |
Eric S. Raymond |
Subject: |
[gpsd-dev] SiRF IV flakiness explored |
Date: |
Fri, 29 Aug 2014 07:04:52 -0400 (EDT) |
I have a TODO item from Hal Murray that reads:
*** SiRF IV flakiness ***
Symptom: device hangs when switching from SiRF to NMEA in gpsmon
(power cycle fixes this).
Underlying problem: SiRF IV has some constraints previous versions
didn't. You have to wait on ACK of the previous config commands
before sending another. The SiRF driver doesn't do this properly.
However, I no longer think the failure to wait for ACK has anything to
do with this. In fact, I am now doubtful there is anything at
all GPSD can do about it. Here is why....
As a very basic test, I connected my USB SiRF device and fired up
gpsmon. It came up in NMEA mode at 4800. I typed 'n' to switch
modes at it, observed success, typed 'n' to switch back to NMEA
mode and observed success.
I then did this several more times. I observed the freeze on the
fifth or sixth switch to NMEA.
I then unplugged and repeated this test. It froze on the first switch
back to NMEA.
Several more repetitions of the test produced freezes after a randomly
variable number of mode changes to NMEA. It never froze on switching
to SiRF binary mode. About half the time it would hang on the first
switch back. I never saw it survive as many flips (5 or 6) as in my
first test.
I then added a guard to the mode-switch function that would cause it
to emit an error message and not send the mode change if it was
waiting on an ACK for a previous mode switch. And rebuilt.
Following this change, I was able to flip back to NMEA 13
times before the freeze. The new error indication I added
was never produced. Of course, this may be a false negative
Ox81 is switch to NMEA, switch to *binary* does not appear
to produce an ACK at all.
During the entire experiment, mode changes were the only command
strings shipped to the device. (This sort of debugging is why gpsmon
is designed the way it is; it deliberately disables writes to the
device during the init sequence in the driver that normally ships
configuration commands.)
My conclusion: This is neither a problem in GPSD nor a problem GPSD
can solve. There is some kind of race condition in the SiRF-IV
firmware that cannot be prevented by waiting for ACKs. The best we
can do is warn users that this chip is flaky. Which is probably
a good idea anyway, as it trades away sensitivity in order to
reduce its power draw and is poor at getting fixes without a
clear skyview.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
All governments are more or less combinations against the
people. . .and as rulers have no more virtue than the ruled. . .
the power of government can only be kept within its constituted
bounds by the display of a power equal to itself, the collected
sentiment of the people.
-- Benjamin Franklin Bache, in a Phildelphia Aurora editorial 1794
- [gpsd-dev] SiRF IV flakiness explored,
Eric S. Raymond <=