[ntp:hackers] NMEA - which sequence of sentence to use?

Dave Hart davehart at gmail.com
Wed Mar 16 13:57:28 UTC 2011

On Wed, Mar 16, 2011 at 07:45 UTC, David J Taylor
<david-taylor at blueyonder.co.uk> wrote:
> with the NMEA driver and no mode set, all supported sentences are processed,
> and the last received is used.  I wonder whether someone could enlighten me
> as to why the last, rather than the first, is used.  I would have thought
> that the first sentence was nearer to the true second.
> What am I missing?

Insider knowledge :)

Take a look at http://bugs.ntp.org/1691 where it was recently changed
to use the first recognized sentence rather than all, which was almost
like processing the last one, except it stuffed garbage into
refclock_process() for each of the not-last sentences.  This fix was
last November, and made it into 4.2.6p3, but the corresponding
documentation update happened in ntp-dev only.  That is, the
documentation from 4.2.7 driver20.html referring to using the first
recognized sentence needs to be backported to any 4.2.6p4 prerelease
that may occcur.

There's a bit more backstory here.  When I first looked at the NMEA
driver (in 4.2.4p6, careful dyslexics) it claimed the default mode 0
meant ANY/ALL sentence was used in the documentation and comments, but
it lied.  In fact, mode 0 was in practice mode 1 and used only $GPRMC.
 I "fixed" that and (re-)introduced the refclock_process()
overstuffing when multiple enabled sentences were received.  I was
happy because it allowed me to modify the GPS configuration to send
different sentences without having to make a corresponding change to
ntp.conf each time, but I was also being careful to have the GPS send
only one sentence per second to take advantage of the
most-definitely-Windows-only user PPS hack in ntpd, which works only
for the first serial line received after the PPS assertion.

I haven't tried to tease out the actual history, but it seems likely
to me someone came across a similar problem with mode 0 long ago and
fixed it by treating mode 0 as mode 1, failing to update the docs

As of 4.2.6p3 and 4.2.7p76, the first recognized sentence is used,
thanks to Juergen Perlinger's suggestion and my followup.  Over that
same time period, Juergen had a patch pending to clean up
refclock_nmea.c which I sat on for far too long before integrating.
It's possible he had fixed this issue with that patch before my
4.2.7p76 then 4.2.6p3-RC9 changes.

Dave Hart

More information about the hackers mailing list