On Sat, 27 Dec 2008 23:53:49 GMT, Unruh <unruh-s...@physics.ubc.ca>
wrote:
>George R. Kasica <geor...@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.
OK. That is the type of experience information I need to know. I have
no idea what is good or bad here with this device. Thank you.
>>>>>>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
OK. I've added back the GPS NEMA lines as well as the PPS lines and
thing seem to be working here. Will see how it goes over the next day
or so. This is exactly what I was looking to try to do.
Again, thank you very much.
Right now ntpq looks like this (after just a few min restarted @ 1200Z
12/28/08) I'm assuming things will settle back down over time and I
will once again start to use the local time sources instead of marking
them as false tickers?:
# ntpq -p
remote refid st t when poll reach delay offset
jitter
==============================================================================
xGPS_NMEA(0) .GPS. 0 l 16 16 377 0.000 12.677
5.862
xSHM(0) .PPS. 0 l 12 16 377 0.000 8.410
93.475
-eagle-local 192.43.244.18 2 u 99 128 37 0.166 724.868
0.714
-apollo-local 128.233.154.245 2 u 98 128 37 0.215 706.214
0.787
mumnunah.csse.u .INIT. 16 u - 64 0 0.000 0.000
0.000
+tick.usask.ca .GPS. 1 u 97 128 37 105.157 702.859
0.756
*clock.isc.org .GPS. 1 u 95 128 37 63.669 702.671
3.087
-time.nist.gov .ACTS. 1 u 94 128 37 72.814 691.122
24.052
-server.donkeyfl 18.26.4.105 2 u 93 128 37 30.919 706.994
22.203
+ip-72-167-54-20 164.67.62.194 2 u 93 128 37 83.165 702.973
137.172
-ns1.bluebottle. 64.202.112.75 2 u 88 128 37 25.726 712.661
3.246
_______________________________________________
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
