On 2014-12-09, Sander Smeenk <ssme...@freshdot.net> wrote: > Hi, > > I run a stratum 1 server which has a Garmin LVC 18x connected to its ttyS0. > The GPS provides a PPS signal via serial and i use gpsd to provide the > NMEA sentences and pulse data in shared memory to NTP. > > This partly works. NTP syncs against the PPS signal but the NMEA signal > is always marked as falseticker even though i managed to bring down the > offset to -1.5??sec average by fudging the time a bit. The NMEA signal > offset fluctuates a lot. From ~ -65??sec to ~ +75??sec.
Who cares? If the system is locking on to the PPS that is far far greater accuracy than you will ever get from nmea. Over 10000 times better. Not sure what your preceived problem is. The nmea is only good for getting the seconds time. Not more accurate time. You do not want it involved in time setting if the PPS is working. > > The GPS provides 9600bps serial comms. Would it help to speed this up to > 19200bps? I've already disabled all NMEA sentence output for sentences that > "aren't useful for timekeeping" but at this moment i have to use external > clocks to sync against. I presume that the unreadable (to me) symbol was milli not micro seconds. I do not believe that one could get the nmea down to microseconds. As I understand it the gps device sends out the nmea when it has time. Ie, much of the fluctuation is internal rather then transmission, although of course transmission is variable as well (consiidering that the length of the sentences fluctuate). > > Few questions: > > 1) Can i get a 'true PPS sync' with this setup? > Eliminating gpsd so 'ntpq -p' shows 'oSHM(1)' instead of '*SHM(1)' ? What is untrue about the gpsd pps? > > 2) What could i possibly do to get NTP to sync/accept the NMEA data, > other than set it as a truechimer in the configuration? nmea will always have very bad fluctuations. You want to use the PPS. > > 3) Why does last_event show clock_alarm for the PPS SHM signal in assoc? > > > At this moment my 'ntpq -p' looks like: > >| # ntpq -np >| remote refid st t when poll reach delay offset jitter >| >============================================================================== >| 127.127.28.0 .NMEA. 0 l 10 16 377 0.000 -52.910 12.585 >| *127.127.28.1 .PPS. 0 l 9 16 377 0.000 -0.002 0.002 >| -193.67.79.202 .PPS. 1 u 50 64 377 3.690 0.331 0.073 >| +193.79.237.14 .PPS. 1 u 48 64 377 2.753 0.128 0.725 >| +80.94.65.10 .PPS. 1 u 63 64 377 3.226 0.005 0.498 >| -130.89.0.19 103.52.146.131 2 u 30 64 377 5.417 -0.100 0.041 > >| # ntpq -c rv >| associd=0 status=0415 leap_none, sync_uhf_radio, 1 event, clock_sync, >| version="ntpd 4.2.6p5@1.2349-o Wed Oct 9 19:08:06 UTC 2013 (1)", >| processor="x86_64", system="Linux/3.13.0-39-generic", leap=00, stratum=1, >| precision=-23, rootdelay=0.000, rootdisp=0.386, refid=PPS, >| reftime=d8318503.7827c0d3 Tue, Dec 9 2014 15:26:11.469, >| clock=d831850e.45ff40f3 Tue, Dec 9 2014 15:26:22.273, peer=53550, tc=4, >| mintc=3, offset=0.001, frequency=-19.125, sys_jitter=0.003, >| clk_jitter=0.001, clk_wander=0.000 > >| # ntpq -c as >| ind assid status conf reach auth condition last_event cnt >| =========================================================== >| 1 53549 9024 yes yes none reject reachable 2 >| 2 53550 964b yes yes none sys.peer clock_alarm 4 >| 3 53551 931d yes yes none outlyer 1 >| 4 53552 9424 yes yes none candidate reachable 2 >| 5 53553 9424 yes yes none candidate reachable 2 >| 6 53554 931d yes yes none outlyer 1 > > > Thanks for any input! > > -Sander. _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
