[ntp:questions] UTC Time from NMEA receiver one second behind DCF?
Harald Brinkmann
hb7267 at gmx.de
Sun Aug 10 19:37:52 UTC 2008
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?
More information about the questions
mailing list