[ntp:questions] Maximum time2 fudge value for NMEA refclock?
jimmyterrence at gmail.com
Sun Jul 18 13:27:42 UTC 2010
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
> server 127.127.20.2 mode 1 minpoll 6 maxpoll 8 prefer
> fudge 127.127.20.2 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.
I found the time2 information at http://www.ece.udel.edu/~mills/ntp/html/drivers/driver20.html
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.
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.
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
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