[ntp:questions] Garmin GPS 18LVC Setup but questions on best way

Unruh unruh-spam at physics.ubc.ca
Sat Dec 27 23:53:49 UTC 2008


George R. Kasica <georgek at netwrx1.com> writes:

>>>>>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?

Why do it? There is nothing wrong with the shm driver. It will discipline
the clock as well as (better than?) the kernel patch.



>>
>>>>
>>>>>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??

Have both!. Nothing says you need to use only one or the other. Use the
shm pps as the preferred but the nmea to get the seconds right. 
The pool servers are then simply as a backup.
Ie also use 127.127.28.0 as a server.


>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