[ntp:questions] ntp version 4.2.7p257-o
hart at ntp.org
Mon Feb 20 11:27:12 UTC 2012
On Mon, Feb 20, 2012 at 04:53, Mark C. Stephens <marks at non-stop.com.au> wrote:
>> I have not experienced the garbled characters. I was hoping your UART
>> being overrun at high bps was the cause, but I'm sure it can manage
>> 9600 cleanly. So I'm not positive the pending fixes will cure that aspect.
> Ah, I was aware that Hal had added some extra counters in the driver, and
> I was thinking (novel concept there) that perhaps there is an error with the
> new counters.
Hal's new counters are for debugging purposes only, and are not yet
integrated into ntp-dev, so they could not be the cause of your issue
with p257. When they are integrated, they will not affect operation
other than exposing these debugging counters via ntpq -c clockvar.
> 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
Perhaps there's some way to enable checksum generation via a
programming sentence from the PC.
More information about the questions