[ntp:questions] timing issue with a HP 58534A

Mark C. Stephens marks at non-stop.com.au
Sat Feb 4 10:10:36 UTC 2012


You hit the nail on the head so to speak:

[root at NTP ~]# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
xGPS_NMEA(0)     .GPS.            0 l   15   16  377    0.000  495.991   0.016
*admin.non-stop. 203.35.83.242    2 u   44   64   77    0.446    0.319   0.164
 130.220.30.32   .STEP.          16 u    -   64    0    0.000    0.000   0.000
 chronos.ise.can .STEP.          16 u    -   64    0    0.000    0.000   0.000
+ns1.unico.com.a 203.23.237.200   3 u   14   64  377   28.897   -1.359   7.578
+ntp.hiltech.com 149.20.64.28     2 u   10   64  377   87.497    4.514  13.151


GPS initially was selected but eventually got marked as false ticker.

I am going to drag a silly scope down there to have a look at the timing pulse, I have a vague suspicion it maybe inverted by the rs422-rs232 convertor which I built. Although unrelated to this issue, I came across this today while building a 'gadget box' for a trimble acutime:

TTL out of rs422 convertor goes into the max232 like this :       
                    __   
_______|   |___________
 
But the rs232 comes out of the max232 inverted, like this:
_______        ____________
                  \__/

The slew rate on rs232 is not so good for timing is it ):


Mark



-----Original Message-----
From: Dave Hart [mailto:hart at ntp.org] 
Sent: Saturday, 4 February 2012 4:00 PM
To: Mark C. Stephens
Cc: questions at lists.ntp.org
Subject: Re: [ntp:questions] timing issue with a HP 58534A

On Sat, Feb 4, 2012 at 03:04, Mark C. Stephens <marks at non-stop.com.au> wrote:
> I put that in because without noselect I get this:
>
> [root at NTP ~]# ntpq -p
>     remote           refid      st t when poll reach   delay   offset  
> jitter 
> ======================================================================
> ========
> xGPS_NMEA(0)     .GPS.            0 l    4   16  377    0.000    0.931   
> 0.012 xtime.non-stop.c 210.9.x.x     2 u   61   64  377    0.340  
> -496.02   0.236
>
> [root at NTP ~]# cat /etc/ntp.conf
> #
> #keysdir /etc/ntp
> keys /etc/ntp/keys
> trustedkey 1
> requestkey 1
> controlkey 1
>
>
> # GPS NMEA
> server 127.127.20.0 mode 16 minpoll 4 maxpoll 4 fudge  127.127.20.0 
> flag1 1 # time2 -0.400
>
> # GPS PPS
> #server 127.127.22.0 minpoll 4 maxpoll 4 prefer #fudge  127.127.22.0 
> flag3 1
>
> #Inhouse reference
> server 192.168.5.8 iburst maxpoll 9
>
> logconfig =allall
> driftfile       /etc/ntp/drift
> enable stats
> statsdir /var/ntp/stats
> statistics loopstats peerstats clockstats
>
> Both are now false tickers. Could it be this GPS gumming up the works?

It appears despite my claim, fudge time2 -0.525 or so is needed for NMEA to properly associate the PPS with the correct second.  Moreover, you're running into the "man with two watches never knows what time it is" problem -- there's no tiebreaker if there's disagreement.  Add more network sources, and/or "noselect" all sources except NMEA, at least until you get NMEA behaving well.

Cheers,
Dave Hart




More information about the questions mailing list