[gpsd-dev] What news on the Rialto? Recent work on gpsd.

[Eric S. Raymond]

Those of you who watch gpsd repository activity may have noticed that,
after a couple of months of quiescence, the project is moving again.
I've been doing some heavy development in the last five days. This
note is to explain why and discuss my near-future plans.

The current round of changes began with a novelty.  I'm actually getting
*paid* to work on this code!  There's an engineering company called
Trellisware which uses embedded GPSes in mobile digital radio networks
that makes internal use of GPSD; they've encountered a few problems
talking to UBX chips and want me to fix them.

Actually fixing their problem is waiting on an eval board to get here.
In the meantime, I've been working on clearing the issues queue so
that GPSD will be in a good clean state when I ship 3.10 with their
fix in it.

All but one of the handful of bugs previously lingering on the tracker
have been fixed and closed.  All pending patches have been merged or
rejected. In the process, I found and squashed a deep-seated bug in
the packet getter that I think explains several puzzlements, including
flakiness in handling TCP/IP GPS data sources and the report that
NTRIP was working over UDP but not TCP.

The bug was that in certain states the packet getter might lose sync
and close a device if the timing of writes from it was such that GPSD
saw a read end in the middle of what might be a valid packet -
that is, as opposed to being in ground state where no packet preamble
has been seen yet.

This never happens under UDP, because from UDP sources each datagram
is a full packet transmitted atomically. Serial writes over a USB or
RS-232 device from a GPS or AIS radio tend also to ship whole packets
at a time (or groups of whole packets) after buffering output
on-chip. Only in the TCP/IP case do network buffering effects
sometimes result in an atomic read boundary falling in the *middle* of
a packet transmission.

Once I understood this problem, the fix was trivial.  It's just
another guard on the code that detects sync failure and tries to
move to the next possible setting on the hunt loop; now, the parser
only does this when it's in ground state.  In any non-ground state
it just keeps reading.

Since clearing the bug queue I've been adding features.  Making
coverage of AIS more complete is the biggest struggle at this point:
the standards are fiendishly complex and scattered through multiple
obscure documents.  There's also a serious problem with test pairs - I
don't have enough of them.  The only reason I have confidence in this
code is that much of it is algorithmically generated, using
devtools/tablegen.py, from the tabular high-level descriptions in
www/AIVDM.txt - if those are correct, then the code is probably
correct. I still wish I had more test pairs.

Still, I persevere. I've just added support for three of the six
message layouts defined in the Inland AIS standard used on the Thames
and Danube rivers (I got a request for this from Austria a few months
back). I expect to add the other three Inland AIS messages before
3.10, and may take a swing at the PAWS/St.-Lawrence-Seaway messages.

I've also fixed a longstanding design mistake in the AIS code, for
which I apologize.  The "scaled" policy flag no longer affects the
output of AIS controlled-vocabulary attributes; now, both the
integer-index and text expansion of each such attribute is always
shipped (the latter in a synthetic attribute named by appending
"_text"). This change should not affect C clients; the clirent library
uses unscaled mode.

The one remaining bug on the tracker is an obscure USB Garmin issue
that I'm going to leave to Gary Miller when he has time. All in all,
the codebase seems to be in very good shape.  Years of work, a huge
test suite, and repeated audits with code checkers like Splint and
Coverity have paid off; I don't look at the codebase every week
because I don't *need* to, any more.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>

The price of liberty is, always has been, and always will be blood.  The person
who is not willing to die for his liberty has already lost it to the first
scoundrel who is willing to risk dying to violate that person's liberty.  Are
you free?       -- Andrew Ford