Harald Brinkmann <[EMAIL PROTECTED]> writes: >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? ;-) The Garmin 18LVC reveiver is about $60, and has a pps and serial output-- some wiring is required. It is not clear what is happening. what GPS receiver is it? What are you running to get the time off of it? >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
