On Friday 26 October 2007, Simon Arlott wrote: > On 26/10/07 21:23, Chuck wrote: > > hmm... this is what i have so far from messing around. this keeps the offset > > for the gps clock in reasonable range or else it is skewed off by 230ms or so > > and there is always an X by it. i suppose it doesnt matter since the pulse > > (gps1) is always * and is usually within 100 us at worst, 5us at best. > > > > there seems to be a considerable change from poll to poll. it never settles > > down into a nice small range hardly varying as i expected it to do. > > > > server 127.127.28.0 minpoll 4 maxpoll 4 > > fudge 127.127.28.0 time1 -0.200 refid GPS > > > > server 127.127.28.1 minpoll 4 maxpoll 4 prefer > > fudge 127.127.28.1 refid GPS1 > > Only the PPS signal is timed to the start of the second. The NMEA data is not. > When there's no fix the PPS signal will be (relatively) ok, but the time output > can be out of sync. Either combine the NMEA output with the PPS signal or only > use PPS. >
this is the output of ntpq -p taken just now. the shm(0) is with the -0.200 time1 fudge -time-C.timefreq .ACTS. 1 u 48 64 377 77.875 -17.696 0.812 -time-B.timefreq .ACTS. 1 u 50 64 377 77.680 -11.043 1.459 -71-13-91-122.st .ACTS. 1 u 46 64 377 40.806 0.975 1.467 pvtnist .ACTS. 1 u 11 64 40 11.228 6.268 0.001 -cpe-76-169-234- .GPS. 1 u 47 64 377 105.323 -4.815 2.295 -time.nist.gov .ACTS. 1 u 20 64 377 78.152 -12.600 1.560 nist1-ny.witime .INIT. 16 u - 1024 0 0.000 0.000 0.000 -avi-lis.gw.ligh .CDMA. 1 u 57 64 377 55.167 1.169 1.488 -time-a.nist.gov .ACTS. 1 u 17 64 377 46.988 0.609 15.301 +time-b.nist.gov .ACTS. 1 u 32 64 377 47.305 1.886 17.287 +SHM(0) .GPS. 0 l 13 16 377 0.000 7.359 7.280 *SHM(1) .GPS1. 0 l 15 16 377 0.000 -0.007 0.009 > -- > Simon Arlott > -- Chuck _______________________________________________ timekeepers mailing list [email protected] https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
