[ntp:questions] NTP PPS on windows losing sync due to bad serial port data.
gom at gom.invalid
Tue Feb 7 11:50:33 UTC 2012
I use NTP on my windows box with serial PPS on
a modded Sure board as per David Taylor's intructions
(thanks Dave ;-) )
Issue I ran into is that a some point the server lost the PPS.
But the GPS seemed to work OK, with blue flashing led etc.
I activated the -ddd debug and got
refclock_gtraw: fd 5 time 3537080327.329358 timecode 84
So the problem was that the serial data weren't split on
CR/LF between 2 GPS lines, and the received line wasn't
recognized as a valid one because it included parts of
the second line ($GPGSA)
So as a quickfix I modified the
refclock_gtlin in ntp_refclock.c,
and added a check to strip the line from the first encounter of CR
for (dp = lineptr; ((dpt < dpend)); dpt++)
for (dp = lineptr; ((dpt < dpend) && (*dpt != 13)); dpt++)
but this is only a quickfix
I think the lines from the serial port should be correctly
split on CR/LF in the ntp_iocompletionport.c code.
The code assumes that the refclock code will strip CR and LF,
which is true, but doesn't assume that ReadFile on a serial
interrupt doesn't stop the reading at the end of a line, so
you can receive in the input buffer a full line,
but also 0.5 line or 1.5 line...
Ideally the OnSerialReadComplete in ntp_iocompletionport.c shouldn't
be sending unprocessed messages from the serial port, but should
split them on the CR/LF, and keep the uncomplete portion to add to
the next line.
Oddly enough today this works, but I think I'm lucky that GPS
receivers make small pauses between lines.
Mine sometimes misbehaves and the ReadFile
receives multiple line fragments.
More information about the questions