[ntp:questions] NTP PPS on windows losing sync due to bad serial port data.

Gom gom at gom.invalid
Tue Feb 7 11:50:33 UTC 2012


Hi,

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
$GPGGA,101848.000,4850.1433,N,00209.1896,E,1,6,1.87,118.1,M,47.3,M,,*58$GPGSA,M,3,

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

old:	
for (dp = lineptr; ((dpt < dpend)); dpt++)

new:
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 mailing list