[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 
>> 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.

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
> accordingly.

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.
> Cheers,
> 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
Web:  http://www.satsignal.eu
Email:  david-taylor at blueyonder.co.uk 

More information about the hackers mailing list