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

David Lord snews at lordynet.org
Sun Jul 18 17:17:09 UTC 2010

jimmyterrence wrote:
> On Jul 18, 6:52 am, David Lord <sn... at lordynet.org> wrote:
>> jimmyterrence wrote:
>>> Is there a maximum fudge value above which the NMEA refclock throws
>>> away input? Both my 18xLVC GPS receivers output serial data about 550
>>> ms after the PPS signal. That works fine with gpsd, but I've been
>>> trying to set up the NMEA driver with pps compiled in the 2.6.34
>>> kernel and it doesn't seem to work.I thought I read somewhere that it
>>> accepts a max of 400 ms but I can't seem to find that anywhere. Could
>>> anybody tell me what the value is, and maybe point me to the line in
>>> refclock_nmea.c (if that's where it is) that governs that?
>> I don't have a Linux system handy but I've used my Garmin
>> no problem from both serial and with relatively poor
>> performance from USB. This will have been on Ubuntu 9.04
>> and up. I just created symlinks /dev/gps0 => /dev/tty00
>> and /dev/pps0 => /dev/tty00.
>> On NetBSD I've been trying parallel port device and hit a
>> problem due to a bug in ntpd (corrected in later versions
>> but these not available for NetBSD). For ntpd 4.2.4p6-o
>> ntp.conf has
>> tos mindist 0.8
>> and
>> server mode 1 minpoll 6 maxpoll 8 prefer
>> fudge time1 0.680 refid GPSb
>> Note that in my docs it states that time2 is not used
>> Without the fudge time1 the PPS doesn't kick in as time
>> from GPS without serial DCD is too far out.
>> PPSb is currently at offset 0.019 and has been getting
>> more deviation from 0.000 during summer with growth of
>> nearby trees. Even a mast of several metres is not
>> likely to give any benefit for more than a couple of
>> years at most. Most sats I've had in view when checked
>> is three and I don't think that's enough.
>> David
> I found the time2 information at http://www.ece.udel.edu/~mills/ntp/html/drivers/driver20.html
> time2 time
> Specifies the serial end of line time offset calibration factor, in
> seconds and fraction, with default 0.0.
> Is that old information? I took that to mean that I can fudge out the
> difference between the pps pulse and the serial information, which in
> my case is about 545 ms.

You should use the documentation for the particular version
of ntpd you are using.

The serial RX data for my Garmin seems to have an offset > 500ms
and also vary by at least 20ms. Once PPS synchronises the GPS
offset comes more or less in line with PPS but unless that fudge
time is used PPS will never be used. That was a known problem
that has been fixed but not yet made it to NetBSD I use.

My fix was to have "tos mindist 0.8" and "fudge time1 0.68"
but side effect can be a large startup offset.

> Also, I ran these commands:
> ln -s /dev/ttyS0 /dev/gps0
> setserial /dev/ttyS0 low_latency
> ldattach 18 /dev/gps
> after I ran the ldattach command, it created pps0, so the next line
> that Hal Murray had doesn't seem to do anything on my system. I
> checked before, and pps0 didn't exist.

With Ubuntu I just created symlinks same as for NetBSD and
didn't notice any problem.  I didn't know anything about
ldattach.  Right now I just did a "man ldattach" from Ubuntu
and maybe I would get better results but symlinks also worked.

If /dev/pps0 is being used I'd expect it to show straight
away from "ntpq -p".

Here the sequence for NetBSD and parallel pps after reboot
last night (not ntp related - new kernel) Jul 17 03:17:

Jul 17 03:24:
  remote  st t reach offset
   PPS(0)  0 l   17  -0.970
  *GPS(2)  0 l   77  37.963
  +server  1 u   77  -0.296

Jul 17 03:30:
  remote  st t reach offset
  oPPS(0)  0 l  377  -0.150
  +GPS(2)  0 l  377  52.735
  +server  1 u  377  -0.296


Jul 17 05:24:
  remote  st t reach offset
  oPPS(0)  0 l  377   0.068
  *GPS(2)  0 l  377  13.446
  +server  1 u  377   1.603

> root at gps:/dev# ll pps*
> crw------- 1 root root 253, 0 Jul 18 09:11 pps0
> I've let it run for a while, and nothing is showing up on the
> billboard
>  remote  refidst t when poll reach delay offset jitter
> ===========================================
>  GPS_NMEA(0).GPS.0 l    -   16    0    0.000 0.000 0.000

More information about the questions mailing list