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

Unruh unruh-spam at physics.ubc.ca
Sat Dec 27 18:07:13 UTC 2008


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

>>George R. Kasica <georgek at netwrx1.com> writes:
>>
>>>I have one of these units running here under Red Hat Fedora Core 9 as
>>>follows based on a collection of a number of the on-line docs I've
>>>looked at. What I'd like to know is as follows:
>>
>>>1) Is this working well or poorly?
>Again, having no base of experience here, are what I'm seeing for
>numbers below good bad or ?? based on how I'm set up and is there
>anything I should be correcting?

>>>2) Is there any way I can use both the GPS time data AND the PPS
>>>signal without having to recompile the kernel as on FC9 its not that
>>>easy to do as it comes down as an RPM and I don't think the patches
>>>are built for it...
>>
>>You can, but not with the standard ntp drivers. I run the gps nmea into the
>>serial port and the PPS into the parallel port, and use a program I wrote
>>to time the parallel interrupt and deliver the result to the shm driver.
>>But that might be a bit too complex for you.
>As you state, too much work to do here, I don't really want to rewire
>the cable any more than it is already if I don't need to. It seems to
>be working well providing the PPS signal via DCD and getting powered
>by USB. Again, getting anything really odd compiled here (see #2
>above) isn't that simple for this box.

>>>3) I'd like to share the GPS/PPS signals via gpsd with another Linux
>>>system if possible would that be usable or accurate enough or should I
>>>just synch off this one at stratum 2?
>>The gps/pps signals are hardware signals. What do you mean "share them?" If
>>you mean installing a splitter so that the same PPS signal is delivered to
>>the two machines, yes you can do that. If you mean something else you need
>>to say what.
>I was hoping that gpsd would be able to simulate or transmit the pps
>similar to how it does with NEMA data but as you day they are hardware
>signals so apparently it cannot do that. Again, I don't really want to
>make the hardware any more convoluted than necessary here.

>>The standard ntp network route will mean that the second clock will have
>>its time disciplined to about 20usec, instead of the 2usec that a direct
>>PPS signal would deliver. 
>That's more than sufficient for what I'm doing here.

>>>3) Any other suggestions that anyone would care to make, I don't claim
>>>to be an expert here:
>>You need to say what you want. I could suggest that you give money to
>>Oxfam, but that might not accord with what you wanted to do. Ie, what are
>>you trying to do. 
>I thought the question was fairly obvious and I'm going to take it in
>the spirit of humor I'm assuming that you meant it. I was hoping
>someone would take a look at the info provided below and let me know
>if they see any obvious ways to improve on what I'm doing here or
>things I may be doing that are incorrect.

>Thanks,
>George

>>>Thank you very much.
>>
>>>George
>>
>>
>>
>>>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. 

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


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


>>
>>
>>>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. 
Your offset should settle down to about plus or minus .005 

The offsets from the external sources are irrelevant ( as long as they are
not greater than 500 or so-- 1/2 sec)



>>
>>># ntpq -p
>>>     remote           refid      st t when poll reach   delay   offset
>>>jitter
>>>==============================================================================
>>>*SHM(0)          .PPS.            0 l   13   16  377    0.000   -0.056
>>>0.013
>>>-mighty.poclabs. 64.202.112.75    2 u  800 1024  377   12.243    2.336
>>>0.316
>>>-clock3.redhat.c 66.187.233.4     2 u  946 1024  257   59.126    2.760
>>>42.876
>>>-192.157.38.60   192.36.143.150   2 u  807 1024  377  119.111    1.110
>>>0.037
>>
>>># ntpdc -c kern
>>>pll offset:           -5.7e-05 s
>>>pll frequency:        111.071 ppm
>>>maximum error:        0.009019 s
>>>estimated error:      1.3e-05 s
>>>status:               0001  pll
>>>pll time constant:    10
>>>precision:            1e-06 s
>>>frequency tolerance:  500 ppm
>>>-- 




More information about the questions mailing list