On Mon, Feb 20, 2012 at 17:34, unruh <[email protected]> wrote: > On 2012-02-20, Dave Hart <[email protected]> wrote: >> On Mon, Feb 20, 2012 at 04:53, Mark C. Stephens <[email protected]> >> 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. Cheers, Dave Hart _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
