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

Unruh unruh-spam at physics.ubc.ca
Tue Dec 30 17:24:05 UTC 2008


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

>On Tue, 30 Dec 2008 09:59:50 -0600, George R. Kasica
><georgek at netwrx1.com> wrote:

>>On Tue, 30 Dec 2008 09:42:06 -0600, George R. Kasica
>><georgek at netwrx1.com> wrote:
>>
>>>On Tue, 30 Dec 2008 07:25:55 GMT, "David J Taylor"
>>><david-taylor at blueyonder.neither-this-part.nor-this-bit.co.uk> wrote:
>>>
>>>>David J Taylor wrote:
>>>>> Richard B. Gilbert wrote:
>>>>> []
>>>>>> I think your best help/advice will come from another GPS18LVC user.
>>>>>
>>>>> I described my own simple setup here:
>>>>>
>>>>>  http://www.satsignal.eu/ntp/FreeBSD-GPS-PPS.htm
>>>>>
>>>>> but it's not Linux, and I don't feel competent enough to give
>>>>> "advice". It seems likely that the wrong edge is being detected, so
>>>>> why not try reversing the polarity?  I only use the:  127.127.20.1 
>>>>> reference clock, with GPS configured in the kernel.
>>>>>
>>>>> Cheers,
>>>>> David
>>>>
>>>>That should read:  with PPS configured in the kernel.
>>>>
>>>>The polarity switch is listed here:
>>>>
>>>>  http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver20.html
>>>>
>>>>as:
>>>>
>>>>flag2 0 | 1
>>>>  Specifies the PPS signal on-time edge: 0 for assert (default), 1 for 
>>>>clear.
>>>
>>>OK I've added the 
>>>
>>>flag2 1
>>>
>>>to both the GPS and PPS fudge lines and restarted here....so far not
>>>much change.
>>>
>>># ntpq -p
>>>     remote           refid      st t when poll reach   delay   offset
>>>jitter
>>>==============================================================================
>>>xGPS_NMEA(0)     .GPS.            0 l   18   16  376    0.000  -635.06
>>>10.323
>>>xSHM(0)          .PPS.            0 l    6   16  377    0.000  -628.03
>>>108.161
>>>
>>>
>>>George
>>
>>
>>Removing the GPS entry from the ntp.conf and taking out the flag2 1
>>items so I'm back to just PPS with shm driver and no gpsd running I
>>get almost immediately:
>>
>># ntpq -p
>>     remote           refid      st t when poll reach   delay   offset
>>jitter
>>==============================================================================
>>*SHM(0)          .PPS.            0 l    6   16   17    0.000    1.283
>>1.803
>> eagle-local     192.168.1.7      4 u    8   64    3    0.122  -32.943
>>0.865
>> apollo-local    192.168.1.7      4 u    6   64    3    0.240  -12.200
>>0.630
>>-220962.ds.nac.n 129.6.15.28      2 u    4   64    3   37.344   32.745
>>97.004
>>+mighty.poclabs. 64.202.112.75    2 u    3   64    3   11.679   15.479
>>186.690
>>+splenda.rustyte 192.43.244.18    2 u    2   64    3   47.755    5.733
>>86.910
>>
>>
>>What am I doing wrong here when I add back GPS data to break this
>>thing???


>Next step....I added back GPS NEMA data without the gpsd daemon (I
>don't pass the data out to anywhere so there's no real need for it)

What does "I added back GPS NMEA" mean? What program did you use to do
that? What reads teh NMEA data and passes it on to ntp.



>and I see

># ntpq -p
>     remote           refid      st t when poll reach   delay   offset
>jitter
>==============================================================================
>xGPS_NMEA(0)     .GPS.            0 l   13   16  377    0.000  -616.37
>10.466

Looks to me like you could get rid of that offset with a fudge.


>*SHM(0)          .PPS.            0 l   14   16  377    0.000   -0.557
>0.712
> eagle-local     192.168.1.7      2 u   36   64  377    0.153  -44.398
>0.607
> apollo-local    192.168.1.7      3 u   24   64  377    0.250  -16.713
>1.912
>-mirror          209.132.176.4    2 u   29   64  377   10.272    6.391
>135.974
>+tesla.fireduck. 198.82.1.202     3 u   28   64  377   36.123    2.841
>115.565
>+rikku.vrillusio 209.51.161.238   2 u   21   64  377   38.531   -3.260
>156.267


>I have good PPS and am getting GPS NEMA in as well but the offset for
>the NEMA data seems quite large....what would I do to fix that??

Use the fudge to get rid of that offset. nmea is very very slow. And I
suspect that you are having the Garmin report a huge number of nmea
sentences. That takes along time to parse. 

And it does not report on the resulting time until the sentences finish.
Having just the one standard sentence would reduce that time.




>George




More information about the questions mailing list