[ntp:questions] UTC Time from NMEA receiver one second behind DCF?

Unruh unruh-spam at physics.ubc.ca
Mon Aug 11 00:25:38 UTC 2008


Harald Brinkmann <hb7267 at gmx.de> 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?




More information about the questions mailing list