Richard B. Gilbert wrote: > Harald Brinkmann wrote: >> This is my setup: >> >> I am using a Navilock NL-320U connected to a small Linux box running ntp >> 4.2.4p4-44.1 that came with the openSuSE 11.0 distribution. This is >> supposed to supply a time service to the local network without the use of >> external network ntp servers purely from the received GPS signal. >> >> I know that using a USB connection is not optimal, but the achieved >> accuracy is fine for my needs. >> >> Last Saturday (2008-08-02) I noticed for the first time that the time off >> the GPS unit was one second behind the DCF time, which I monitor on a >> separate radio clock. A reboot of the system did not help. On Sunday >> (2008-08-03) everything was back to normal. I noticed the same effect >> again on Friday evening (2008-08-08) and through yesterday (2008-08-09), >> but everything seems fine today (2008-08-10). >> >> I added a network server to my ntp configuration to double check the >> effect. This is how the output "ntpq -p" looks like when everything is >> fine: >> >> remote refid st t when poll reach delay offset >> jitter >> ============================================================================== >> LOCAL(0) .LOCL. 10 l 19 64 377 0.000 0.000 >> 3.906 >> *GPS_NMEA(0) .GPS. 3 l 22 64 377 0.000 14.902 >> 3.906 >> xptbtime2.ptb.de .PTB. 1 u 422 1024 377 66.375 -8.106 >> 5.216 >> >> And this is the output when I observe the one second lag: >> >> remote refid st t when poll reach delay offset >> jitter >> ============================================================================== >> LOCAL(0) .LOCL. 10 l 33 64 17 0.000 0.000 >> 3.906 >> *GPS_NMEA(0) .GPS. 3 l 30 64 17 0.000 -978.27 >> 11.515 >> xptbtime2.ptb.de .PTB. 1 u 31 64 17 67.160 1.002 >> 3.906 >> >> Looking at the raw NMEA output, the UTC info in there also seems to be >> one second slow. >> >> In all of this I presume the PTB time to be correct. >> >> My question is, has anyone else observed this and how can I fix this? >> >> Thanks >> >> Harald >> > > It sounds as if the GPS receiver you have was designed for navigation > rather than timing! > > Timing receivers typically have a Pulse Per Second (PPS) output and use > a binary protocol rather than NMEA to transmit the time to a serial port. > > Using the proper tool for the job should solve many of your problems.
Point taken. Didn't I mention I am a cheapskate? ;-) What flummoxes me is that I occasionally (and only in the last couple of days) have observed this offset of almost exactly one second. If this would happen to a receiver with PPS, the result would then be exactly one second off. I was hoping for some educated guesses how this might have happened. Maybe a GPS receiver bug in connection with the upcoming leap second? _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
