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

Mark C. Stephens marks at non-stop.com.au
Mon Feb 6 16:58:53 UTC 2012


That clarifies things a lot, Mr. Hart.

Both of the ntp servers have an * not an o. and I'd really like to squeeze some more accuracy out of it ;)

[root at NTP ~]# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*GPS_NMEA(0)     .GPS.            0 l   11   16  377    0.000   -0.238   0.039
-admin.non-stop. .GPS.            1 u   35   64  376    0.272   11.374   0.380
 . 
 .
 .

Concentrating on the freebsd box:

 7 Feb 00:22:51 ntpd[5091]: ntpd exiting on signal 15
 7 Feb 00:22:52 ntpd[5117]: proto: precision = 2.236 usec
 7 Feb 00:22:52 ntpd[5117]: ntp_io: estimated max descriptors: 11095, initial socket boundary: 20
 7 Feb 00:22:52 ntpd[5117]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
 7 Feb 00:22:52 ntpd[5117]: Listen and drop on 1 v6wildcard :: UDP 123
 7 Feb 00:22:52 ntpd[5117]: Listen normally on 2 em0 192.168.5.112 UDP 123
 7 Feb 00:22:52 ntpd[5117]: Listen normally on 3 lo0 fe80::1 UDP 123
 7 Feb 00:22:52 ntpd[5117]: Listen normally on 4 lo0 ::1 UDP 123
 7 Feb 00:22:52 ntpd[5117]: Listen normally on 5 lo0 127.0.0.1 UDP 123
 7 Feb 00:22:52 ntpd[5117]: peers refreshed
 7 Feb 00:22:52 ntpd[5117]: Listening on routing socket on fd #26 for interface updates
 7 Feb 00:22:52 ntpd[5117]: GPS_NMEA(0) serial /dev/gps0 open at 9600 bps
 7 Feb 00:22:52 ntpd[5117]: GPS_NMEA(0) 8011 81 mobilize assoc 60778
 7 Feb 00:22:52 ntpd[5117]: 192.168.5.8 8011 81 mobilize assoc 60779
 7 Feb 00:22:52 ntpd[5117]: 0.0.0.0 c016 06 restart
 7 Feb 00:22:52 ntpd[5117]: 0.0.0.0 c012 02 freq_set kernel 119.785 PPM
 7 Feb 00:22:53 ntpd[5117]: GPS_NMEA(0) 8024 84 reachable
 7 Feb 00:22:53 ntpd[5117]: GPS_NMEA(0) 903a 8a sys_peer
 7 Feb 00:22:53 ntpd[5117]: 0.0.0.0 c415 05 clock_sync
 7 Feb 00:23:19 ntpd[5117]: 192.168.5.8 8024 84 reachable
 7 Feb 00:24:13 ntpd[5117]: GPS_NMEA(0) 931a 8a sys_peer

I can't see any sign of a whinge?

[root at NTP /etc/rc.d]# ntpdc -c kerninfo
pll offset:           -0.00020659 s
pll frequency:        107.709 ppm
maximum error:        0.007036 s
estimated error:      3.9e-05 s
status:               2001  pll nano
pll time constant:    4
precision:            1e-09 s
frequency tolerance:  496 ppm
pps frequency:        119.785 ppm
pps stability:        0.000 ppm
pps jitter:           0 s
calibration interval: 4 s
calibration cycles:   0
jitter exceeded:      0
stability exceeded:   0
calibration errors:   0

Also can't see any PPS there either.

It's definitely running the PPS kernel I built: 
[root at NTP /etc/rc.d]# uname -a
FreeBSD NTP 8.2-RELEASE-p6 FreeBSD 8.2-RELEASE-p6 #1: Sun Feb  5 10:39:17 EST 2012     root at NTP:/usr/obj/usr/src/sys/PPS  i386

[root at NTP /etc]# cat /etc/make.conf
KERNCONF= PPS GENERIC
# added by use.perl 2012-01-25 15:59:06
PERL_VERSION=5.10.1

[root at NTP /usr/src/sys/i386/conf]# cat PPS
#
# PPS -- Generic kernel configuration file for FreeBSD/i386 PPS
#
include GENERIC
ident PPS-GENERIC
options PPS_SYNC

and then 
make buildkernel KERNCONF=PPS
make installkernel KERNCONF=PPS

I'll go back and do the last 2 steps and reboot and see how it goes.
Actually really beginning to like working with bsd.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Looking at the windows box:

C:\Program Files\NTP\bin>ntpq -c peer
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*GPS_NMEA(1)     .GPS.            0 l   12   16  377    0.000    2.901   0.158
+ntp             .GPS.            1 s   47   64  377    0.308  -11.099   0.240
 .
 .
 .

C:\Program Files\NTP\bin>ntpq -c kern
associd=0 status=0415 leap_none, sync_uhf_radio, 1 event, clock_sync,
pll offset:            0
pll frequency:         0
maximum error:         0
estimated error:       0
pll time constant:     0
precision:             0
frequency tolerance:   0
pps frequency:         0
pps stability:         0
pps jitter:            0
calibration interval   0
calibration cycles:    0
jitter exceeded:       0
stability exceeded:    0
calibration errors:    0

Aha, in event viewer I see:
Using user-mode PPS timestamp for GPS_NMEA(1)   

Could there be something amiss with my PPS pulse?

I stuck a 74AC04 invertor between the rs422 receiver and the max232 on the weekend as I noticedthe pulse was inverted on DCD. 

Pulse on DCD looked like:
__  __  __
     U    U    U
Inverting effectively changed it to a positive pulse
  __ n__n__n

I have just realised it is a design flaw on my gadget box, data lines behave opposite to signal lines on rs232. Adding an invertor fixed this.

I may just drop in a 1488 line driver for DCD. Added bonus of faster rise time of 45ns too. I can grab the +/- 12v off the max232 ;)

There you go, raving again...


Thanks Dave, gulp...

-----Original Message-----
From: Dave Hart [mailto:hart at ntp.org] 
Sent: Tuesday, 7 February 2012 1:02 AM
To: Mark C. Stephens
Cc: questions at lists.ntp.org
Subject: Re: [ntp:questions] timing issue with a HP 58534A

On Mon, Feb 6, 2012 at 13:50, Mark C. Stephens <marks at non-stop.com.au> wrote:
> This is probably the wrong question to ask, but anyway, I have flag1 1 for refclock 20 in my config.
>
> Under freebsd how do I verify it is using PPS timestamps?

On any platform, with flag1 1 for the NMEA driver, PPSAPI is attempted.  If it fails, you will see the driver whinge to syslog.  If it succeeds and PPS is working, you'll see 'o' tally code in the first column of ntpq -p output (PPS peer) rather than '*' (system peer).

With flag3 1 (kernel hardpps, that is, kernel sync directly to PPS without ntpd involvement) you can check for PPS indicated in one of several similar outputs:

ntpdc -c kerninfo
ntpq -c kerninfo (requires recent 4.2.7 ntpq and ntpd) ntptime

Cheers,
Dave Hart




More information about the questions mailing list