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

Unruh unruh-spam at physics.ubc.ca
Thu Jan 1 16:43:48 UTC 2009


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

>On Wed, 31 Dec 2008 17:57:25 GMT, Unruh <unruh-spam at physics.ubc.ca>
>wrote:

>>George R. Kasica <georgek at netwrx1.com> writes:
>>
>>>On Wed, 31 Dec 2008 00:20:45 GMT, "David J Taylor"
>>><david-taylor at blueyonder.neither-this-part.nor-this-bit.co.uk> wrote:
>>
>>>>Unruh wrote:
>>>>> "David J Taylor"
>>>>[]
>>>>>> With just the reference clock type 20, I get the accuracy needed.
>>>>>> The PPS line from the GBS-18 LVC is wired to the DCD line of the
>>>>>> serial port.  In my ignorance, I don't see why you even need the SHM
>>>>>> driver, but as I said before, I'm no expert!  I don't see why my
>>>>>> system picks up the PPS from just the type 20 driver, and yours does
>>>>>> not.
>>>>>
>>>>>
>>>>> Because you have the PPS kernel patch installed or it was
>>>>> automatically
>>>>> instaled in BSD? The OP does not and does not want to.
>>>>
>>>>Thanks.  Yes, I had to recompile the FreeBSD kernel to include this patch. 
>>>>I must have thought at the time that it was mandatory, or was advised to 
>>>>do this.
>>
>>>I'd be happy to put it in here, but doing so with the Fedora Core 9
>>>RPM based code is not something I'm familiar with. I'm used to working
>>>with straight source code for kernels ie make make install type steps
>>>(don't take those literally please I know the steps) or just leaving
>>>the RPMs alone. I just am not sure how or if the PPS patches I've seen
>>>will apply to the kernel version here on the FC9 box or how it will
>>>affect the system-obviously breaking it is not an option - well, it
>>>always is but not a good one since it archives a ton of weather data
>>>:). 
>>
>>I think it will gain you nothing over the shm option, except you will be
>>sitting there worrying and watching your computer compiling a kernel.
>>
>>However, has anyone done tests on the serial port interrupt to see how much
>>latency there is in that? Ie, If I use, say, shmpps and I trigger the serial
>>control line at time t, what is the time t+dt that shmpps reports as the
>>time of the trigger? And what is the fluctuation in dt? On the parallel
>>port interrupt service routine I have done that and the result was about
>>0-2usec. (in fact I suspect most of the noise in at least the short term
>>fluctuation of ntpd is from that source). But shmpps and gpsd have a whole
>>layer of serial port driver interposed between the interrupt and the
>>report. Does that made a difference?
>I likely have nowhere near the level of hardware/software knowledge or
>likely test gear to accomplish this.

TEst gear not needed. You just need to put out and time a signal onto the
parallel port and feed it into the serial port, timing the reception of the
signal. But that does require a lot of hacking. I was able to do it on the
parallel port because the program had already been written in
Alessandro Rubini and Jonathan Corbet's boot Linux Device Drivers
I just made minor adaptation ( or major ones when I used it as the basis
for my parallel port gps device driver)
However, I was wondering if anyone had done the same thing for the standard
serial port ioctl 




More information about the questions mailing list