[ntp:questions] Garmin GPS 18LVC Setup but questions on best way
George R.Kasica
georgek at netwrx1.com
Sat Dec 27 20:49:38 UTC 2008
>>>>sym links from
>>>
>>>>/dev/gps0 -> /dev/ttyS0
>>>>/dev/pps0 -> /dev/ttyS0
>>>
>>>>running the gpsd and the 18LVC off ttyS0 at 4800 baud settings on
>>>>18LVC done as per quan web page docs to set NEMA and PPS auto Off etc.
>>>
>>>>setserial /dev/ttyS0 uart 16550A port 0x03f8 irq 4 baud_base 115200
>>>>spd_normal skip_test low_latency
>>>
>>>>/usr/sbin/gpsd -b -n /dev/ttyS0
>>>
>>>>./shmpps -d /dev/ttyS0 -s -l DCD -u 0 -c
>
>Ah, you are NOT running the kernel PPS. You are running the shm refclock
>using the timing of the serial port driver.
Correct. Getting the pps patch to work here with the rpm based kernels
for Fedora Core 9 has proven to be problematic. Has anyone got any
pointers or managed to get this working?
>
>>>
>>>>my ntpd.conf looks like:
>>>
>>>>server 127.127.28.0 minpoll 4 prefer
>>>>fudge 127.127.28.0 refid PPS flag3 1
>That is solely the shm refclock driver which is coming off your serial port
>interrupt. You do not have the serial nmea data coming in at all to your
>system it looks to me.
If I switch to the following settings I can seem to get NEMA data but
then I lose the PPS function which hurts the accuracy far more. Do you
know if shm can somehow allow both with some type of setting - ideally
that is what I'm trying to accomplish through the shm driver or
something else without hacking the kernel, etc??
server 127.127.20.0 minpoll 4 prefer
fudge 127.127.20.0 flag3 1 flag2 0
>>>>server 0.us.pool.ntp.org
>>>>server 1.us.pool.ntp.org
>>>>server 2.us.pool.ntp.org
>You are geting the information of the correct seconds from these external
>servers.
Correct.
>>>>And looking at ntpq stats shows me:
>You do not say when these were taken. ntp takes about 10 hours to settle
>down to its ultimate accuracy. If this was less than 10 hours, the figures
>mean nothing.
That was about 12 hours after setup. Here are stats from 12/27 @ 1440Z
which is about 40 hours of running on the ntpd config here (restarted
on 12/25 @ 2200Z approx).
# ntpq -p
remote refid st t when poll reach delay offset
jitter
==============================================================================
*SHM(0) .PPS. 0 l 15 16 377 0.000 0.004
0.002
-mighty.poclabs. 64.202.112.75 2 u 696 1024 377 11.718 -1.234
150.234
-clock3.redhat.c .CDMA. 1 u 688 1024 57 59.827 1.536
93.244
+192.157.38.60 192.36.143.151 2 u 691 1024 377 118.706 1.052
74.929
# ntpdc -c kern
pll offset: 2e-06 s
pll frequency: 111.093 ppm
maximum error: 0.006033 s
estimated error: 2e-06 s
status: 0001 pll
pll time constant: 5
precision: 1e-06 s
frequency tolerance: 500 ppm
>Your offset should settle down to about plus or minus .005
Looks lie its OK at .004 if I read this correctly.
>The offsets from the external sources are irrelevant ( as long as they are
>not greater than 500 or so-- 1/2 sec)
Again seem to look OK at around +/- 1.x
Thank you very much for the help.
George
More information about the questions
mailing list