[ntp:questions] Maximum time2 fudge value for NMEA refclock?

Terje Mathisen "terje.mathisen at tmsw.no" at ntp.org
Sun Jul 25 09:06:10 UTC 2010

jimmyterrence wrote:
> On Jul 22, 10:40 am, jimmyterrence<jimmyterre... at gmail.com>  wrote:
>> On Jul 22, 9:11 am, Rhys<u... at mailinator.org>  wrote:
>>> In article<mqilh7-0hi.... at p4x2400c.home.lordynet.org>,
>>> sn... at lordynet.org says...
>>>> Rhys wrote:
>>>>> In article<keqgh7-lgg.... at p4x2400c.home.lordynet.org>,
>>>>> sn... at lordynet.org says...
>>>>>> Rhys wrote:
>>>>>>> In article<i241ce$bu... at news.eternal-september.org>, david-
>>>>>>> tay... at blueyonder.co.uk.invalid says...
>>>>>>>> "Rhys"<u... at mailinator.org>  wrote in message
>>>>>>>> news:MPG.26b018b8126a17a1989681 at news.optusnet.com.au...
>>>>>>>> []
>>>>>>>>> Sorry I should have said, GPS18x. Now that its stabilised its still 20-
>>>>>>>>> 80ms positive out in ntpq, so either my offset didn't actually change,
>>>>>>>>> or in the wrong direction.
>>>>>>>> For NMEA alone, no PPS, you may get poorer performance then just with
>>>>>>>> LAN/Internet sync.  Just to remind me, you're somehow measuring one system
>>>>>>>> against another?
>>>>>>>>> Seems a regular thing for it to jump crazy on startup, makes fine tuning
>>>>>>>>> a little impossible. PPS takes 30 minutes i think to reappear, it might
>>>>>>>>> be kernal PPSing in the background vs NTP trying to synch to NMEA.
>>>>>>>> What do you mean "reappear"?  To be present on ntpq -p at all, or to have
>>>>>>>> the synced tag "o"?
>>>>>>>>> I was thinking about turning on more NMEA sentences to see if it
>>>>>>>>> stabilises NMEA, but getting to the Windows boot on that isn't easy now,
>>>>>>>>> and this main PC has no serial.
>>>>>>>> I would have thought that the fewer sentences the better, to be honest,
>>>>>>>> although I've seen one recommendation to use the sentences which include
>>>>>>>> the number of satellites locked (IIRC) so that you can get a measure of
>>>>>>>> how marginal GPS lock might be.
>>>>>>>> My own tests showed that while a serial-to-USB converter made accuracy a
>>>>>>>> lot worse, it could still be better than a LAN connection alone.
>>>>>>>>   http://www.satsignal.eu/ntp/NTP-on-Windows-serial-port.html#usb
>>>>>>>> Cheers,
>>>>>>>> David
>>>>>>> Using both 20 MMEA and 22 PPS references. PPS turned off on the NMEA,
>>>>>>> Kernel mode on the PPS. They seem to operate almost independantly.. PPS
>>>>>>> has zero reach, with no 'when' time, for about 1/2 an hour, it may be
>>>>>>> waiting for NMEA to get under a certain threshold, or for NTP to stop
>>>>>>> thrashing around the 500 PPM mark and align. Its present, just not doing
>>>>>>> anything.
>>>>>> That's what I see with separate gps and pps sources and
>>>>>> drivers. PPS does nothing until GPS (or other prefer peer)
>>>>>> is marked as selected. This can be an hour or more or never
>>>>>> depending what fudge offset is set for gps although with
>>>>>> 680ms fudge offset at moment, pps is selected and at reach
>>>>>> 377 in under 30 minutes from starting ntpd.
>>> Well its settled down ok now. Config NMEA offset is set around 600ms
>>> again, and using 'true' keyword for both as well. True on just NMEA
>>> causes PPS to drop out for being too far off. Noselects on all the lan
>>> clients.
>>> Therefore I've got a config at last that can self align on an airgapped
>>> lan, thanks to those who posted up their offsets and the link showing
>>> the offset chart, helps a lot for this kinda stuff.
>>> Now to figure out how to synch an LPRO...
>> I managed to set up a pps-enabled kernel on another linux box I have.
>> Same thing, works with gpsd, not with the NMEA driver. One thing I was
>> wondering, though, what pps pulse length does the NMEA driver seem to
>> want? I have the gps receiver set at 200 ms right now for gpsd.
> I solved the problem with the nmea driver (20) not working. Despite
> the documentation saying that it works at 19200 bps, it only works for
> me at 4800. I followed David Taylor's link:
>   http://www.satsignal.eu/ntp/FreeBSD-GPS-PPS.htm
> And in that document he links to Brian Doyle's Blog, where Brian says
> that he could only get the nmea driver working at 4800 bps. I used
> minicom to change the baud rate back to 4800, changed the mode in
> ntp.conf from 32 to 0 (default) and....
> Oh....it's triggering on the NMEA data and not the PPS signal.

This is where you might need a clock fudge for the NMEA signal to bring 
that more or less in line with the real time.

> Jitter's huge, and it's 700 ms off the other servers.

Yep, sounds like you either need NMEA adjustment or a tinker parameter 
to allow such a huge offset.

Here's my own GPS18 config (FreBSD), with ~315 ms offset. I am using a 
single GGA sentence, since that allows me to collect nr of sats and 
lat/long location statistics:

# NMEA + PPS refclock on /dev/gps0
server mode 2 minpoll 4 maxpoll 4 prefer # GPGGA
# Enable PPS, disable falling edge, disable kernel PPS, fudge NMEA time2
fudge refid "GRMN" flag1 1 flag2 0 flag3 0 time2 0.315

I get lines like these in clockstats:

55401 183.702 

Yes, that is the location of the metal bracket on the east end of my 
roof. :-)


- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

More information about the questions mailing list