[ntp:hackers] NMEA - which sequence of sentence to use?
David J Taylor
david-taylor at blueyonder.co.uk
Wed Mar 16 14:58:28 UTC 2011
>> with the NMEA driver and no mode set, all supported sentences are
>> 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
>> 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.
Great minds think alike! What a pleasure to report a potential bug and
find that not only has been reported before, but that it's already been
> 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.
Yes, I had wondered why only the first sentence was timestamped with the
PPS edge in the Windows version, but hadn't realised that the the
subsequent sentences were sent to refclock_process(). They would each
have the "real" timestamp rather than the PPS timestamp.
> 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
Something we're all guilty of at times, I suppose.
> 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
Thanks for the detail, Dave, it does help to understand things.
Not that it may need action, but the background for my question was this:
- using the Sure Electronic GPS board, out of the box it sends several
sentences at at relatively slow 9600 baud rate, lasting about 450ms.
- the first sentence starts about 250 ms after the PPS edge (timings off a
video, not 'scope measured). It's a $GPGGA with about 69 characters, and
so must finish about 322ms after the PPS edge (very roughly).
- the last sentence finishes about 700 ms after the PPS edge
- when testing on one Windows XP system with the serialpps.sys driver,
there seemed to be a variability in the NMEA offset, rather like that seen
with the GPS 18x and its very late serial data. NTP version: ntpd
4.2.7p97-o. I saw values like -0.840s, +0.382s, +0.395s
- setting the baud rate to 115,200 cured the jumping NMEA offset.
- with the Sure set back to 9600 baud, setting the mode = 16 (9600 baud) +
2 ($GPGGA, the first sentence sent), also cured the problem.
So at least with the out-of-the-box configuration, setting the "look for
$GPGGA" flag seemed to be required on one system. I've added that note to
my Web page.
Thanks again for the most helpful information.
SatSignal software - quality software written to your requirements
Email: david-taylor at blueyonder.co.uk
More information about the hackers