[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