On Mon, Feb 20, 2012 at 04:53, Mark C. Stephens <[email protected]> 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 sentences. Perhaps there's some way to enable checksum generation via a programming sentence from the PC. Cheers, Dave Hart _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
