[ntp:questions] ntp version 4.2.7p257-o

Dave Hart hart at ntp.org
Mon Feb 20 20:34:31 UTC 2012

On Mon, Feb 20, 2012 at 17:34, unruh <unruh at invalid.ca> wrote:
> On 2012-02-20, Dave Hart <hart at ntp.org> wrote:
>> On Mon, Feb 20, 2012 at 04:53, Mark C. Stephens <marks at non-stop.com.au> wrote:
>>> Why I say this is that that it's not related to the serial input as per:
>>> C:\Documents and Settings\Administrator>ntpq -c clockvar
>>> associd=0 status=0011 1 event, clk_no_reply,
>>> device="NMEA GPS Clock", timecode="$GPZDA,044739,20,02,2012,+00,00",
>>> poll=564, noreply=1, badformat=0, baddata=0, fudgetime2=-480.000,
>>> stratum=0, refid=GPS, flags=1
>>> the timecode looks great there, as does clockstats:
>> It doesn't look great to me.  I'd expect a checksum on the end of the
>> sentence consisting of a * and two hex digits 0-9/A-F.  I'm
>> disappointed the Sure isn't generating the checksum, as is
>> computationally trivial and serial transmission is far from inherently
>> error-free.  Earlier NMEA specification versions require the checksum
>> only for $GPRMC, but the latest NMEA version mandates checksum on all
>> sentences.
> Lets not jump overboard to swim with assumptions. Sure DOES generate
> checksums.
> Here is from my Sure board
> $GPGSV,4,3,14,19,16,316,18,27,07,083,17,29,06,156,,30,03,233,*7B
> Now, ntpq -c clockvar may be stripping them off, but do not blame Sure
> for that.

We've seen thanks to David Taylor $GPGGA checksums and thanks to you a
$GPGSV checksum, which are both encouraging.  I admit there's a
possibility of truncation in the quoted timecode, but it wouldn't be
due to ntpq in all likelihood, but ntpd and in particular
http://bugs.ntp.org/2140.  However, the evidence is also consistent
with the default Sure config not emitting a checksum with $GPZDA,
though I sure hope it's not true.

Dave Hart

More information about the questions mailing list