David Lord wrote:
> David Lord wrote:
>
>> that I can't get parallel (or serial) pps to work with just
>> ATOM driver flag3 0 | 1 (kernel discipline disable | enable)
>> and no other refclock, ie I'd like to just use another ntp
>> server as preferred with pps to condition the clock.
>
> Don't know what I did wrong previously but just removed
> 127.127.20.0 lines from ntp.conf, set me6000g as prefer,
> restarted ntpd and had following:
> oPPS(0) .PPSb. 377 -0.002 0.004 pps from GPS
> *k6x400 377 0.246
> +me6000g .PPSa. 377 0.106 pps from MSF
> -p4x2400c 377 0.533
>
> The above with parallel pps0 at ppbus and /dev/pps0
> created using mknod same as tried earlier.
>
> Also tried with p4x2400c as prefer and that's ok.
>
> Replaced /dev/pps0 with /dev/pps0 -> /dev/tty00
> disconnected parallel port, reconnected serial (DCD and RxD),
> restarted ntpd and that's working ok.
>
> Can't think what I've done different. Then again MSF
> wouldn't sync end of last week after I'd made a change
> to ntp.conf and then I noticed LED on receiver wasn't
> flashing.
Short term memory loss I think.
I'd no sooner posted that when oPPS(0) flipped to -PPS(0)
and continued flipping with offset increasing from 4u
to 145u. I then restarted with kernel pps selected
(flag3 1). That was no better, and same when I went back
to parallel port still with kernel mode pps. I even
mentioned this behaviour in a much earlier message.
Now back to parallel port with PPSAPI (no flag3) and so
far this does seem to be converging with PPS(0)
remaining selected as pps.peer for 25 minutes so far
(no doubt until I hit the send button). Offset has
converged from > 250us to 12us with jitter now at 4us.
cheers
David
|