jimmyterrence wrote:
On Jul 18, 6:52 am, David Lord <sn...@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 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.
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
r...@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
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
