Hi Dave, thanks for bearing with me, I feel a bit dim under your brilliance!
After capturing data and computing average position for location for a few days I put it into timing mode and locked the co-ords in. Now the refclock driver says its unreachable, even though I can see (looks like) valid data ticking in with -d. I have switched the GPS back to survey mode and all is good again, looks like I can't use timing mode with this driver. Interesting journey though :) fudge is a cool technical term (usage: Oh Fudge, it broke etc) Mark -----Original Message----- From: Mark C. Stephens Sent: Sunday, 5 February 2012 10:28 PM To: 'Dave Hart' Cc: [email protected] Subject: RE: [ntp:questions] timing issue with a HP 58534A [root@NTP /usr/src]# ntpq -c "rv 0 frequency" frequency=3.042 time2 is -0.525 -----Original Message----- From: Dave Hart [mailto:[email protected]] Sent: Sunday, 5 February 2012 9:36 PM To: Mark C. Stephens Cc: [email protected] Subject: Re: [ntp:questions] timing issue with a HP 58534A On Sun, Feb 5, 2012 at 10:17, Mark C. Stephens <[email protected]> wrote: > How does that look after 12 hours? > > > [root@NTP /usr/src]# ntpq -p > remote refid st t when poll reach delay offset > jitter > ====================================================================== > ======== > *GPS_NMEA(0) .GPS. 0 l 8 16 377 0.000 -0.067 > 0.034 > +admin.non-stop. 210.9.x.x 2 u 22 64 377 0.278 1.503 > +0.027 ns1.unico.com.a 203.23.237.200 3 u 58 64 377 28.241 > +1.721 4.879 That looks healthy to me. Since you had messages about exceeding +/- 500 PPM previously, I'm curious what frequency correction it's settled down to: ntpq -c "rv 0 frequency" (or simply ntpq -crv and pick it out) Cheers, Dave Hart _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
