[ntp:questions] Fwd: Re: NetBSD GPS/PPS using 4.2.6p3
A C
agcarver+ntp at acarver.net
Sun Aug 21 21:55:55 UTC 2011
On 8/21/2011 14:31, Chris Albertson wrote:
> Are you certain the electrical connection is correct, correct RS232 voltages
> and correct polarity. The polarity of the serial data and the control
> signals is reversed from each other. Can you place a scope on the PPS
> signal at the serial port. You problem looks to me as if either (1) there
> is not PPS signal) or (2) there is no interrupt handler (deriver) catching
> the PPS.
>
> On Sun, Aug 21, 2011 at 1:10 PM, A C<agcarver+ntp at acarver.net> wrote:
>>
>> No reply from the PPS clock at all.
>
Yes, electrically everything is fine. As mentioned earlier, the test
code present in the ntp distribution (pps-api.c) actively identifies the
changing state of DCD:
# /usr/src/ntp-4.2.6p3/util/pps-api /dev/ttyb
0.000000000 0.000000000 0 0 0.000000000
1313962564.096278031 0.000000000 1 0 -1313962564.096277952
1313962564.096278031 1313962564.996312981 1 1 0.900034950
1313962565.096299309 1313962564.996312981 2 1 -0.099986328
1313962565.096299309 1313962565.996303261 2 2 0.900003952
1313962566.096299589 1313962565.996303261 3 2 -0.099996328
1313962566.096299589 1313962566.996299540 3 3 0.899999951
1313962567.096299867 1313962566.996299540 4 3 -0.100000327
1313962567.096299867 1313962567.996304817 4 4 0.900004950
1313962568.096295146 1313962567.996304817 5 4 -0.099990329
1313962568.096295146 1313962568.996298096 5 5 0.900002950
1313962569.096294424 1313962568.996298096 6 5 -0.099996328
Another piece of test code from the NetBSD developers (ppstest.c) also
sees the change:
# /usr/src/ppstest /dev/ttyb
Clear timestamp: 0.000000000, sequence: 0
Assert timestamp: 1313962653.096260820, sequence: 1
Clear timestamp: 1313962653.996297727, sequence: 1
Assert timestamp: 1313962654.096264053, sequence: 2
Clear timestamp: 1313962654.996296959, sequence: 2
Assert timestamp: 1313962655.096260285, sequence: 3
Clear timestamp: 1313962655.996297190, sequence: 3
Assert timestamp: 1313962656.096259516, sequence: 4
Clear timestamp: 1313962656.996294421, sequence: 4
Assert timestamp: 1313962657.096262747, sequence: 5
So the DCD transition is being seen. I had originally asked over on the
NetBSD group about this first before coming to ntpd questions. That is
where I obtained the ppstest code and then later I discovered the test
code within the ntpd source distribution. The NetBSD list also
suggested that I compare kernel traces on the two programs. It seems
that ntpd's pps-api code behaves a bit differently than ntpd itself when
it interfaces with the kernel. I can provide traces to anyone that
would like them for both the pps-api test program and ntpd 4.2.6p3.
The one specific difference I can see through by searching for "PPS" on
the trace logs is that pps-api issues PPS_IOC_GETCAP first, then
PPS_IOC_SETPARAMS, followed by PPS_IOC_FETCH. However, ntpd skips
PPS_IOC_GETCAP entirely and starts with PPS_IOC_SETPARAMS followed by
PPS_IOC_KCBIND and then begins the PPS_IOC_FETCH.
Here are filtered versions of the tops of the two traces:
pps-api:
4384 1 pps-api CALL ioctl(3,PPS_IOC_GETCAP,0xefffe73c)
4384 1 pps-api CALL ioctl(3,PPS_IOC_SETPARAMS,0xefffe744)
4384 1 pps-api CALL ioctl(3,PPS_IOC_FETCH,0xefffe75c)
4384 1 pps-api CALL ioctl(3,PPS_IOC_FETCH,0xefffe75c)
4384 1 pps-api CALL ioctl(3,PPS_IOC_FETCH,0xefffe75c)
4384 1 pps-api CALL ioctl(3,PPS_IOC_FETCH,0xefffe75c)
ntpd:
127.127.22.1 flag2 0 flag3 1 refid PPS\n\n
11255 1 ntpd CALL ioctl(7,PPS_IOC_SETPARAMS,0x1052d204)
11255 1 ntpd CALL ioctl(7,PPS_IOC_KCBIND,0xefffdf8c)
11255 1 ntpd CALL ioctl(7,PPS_IOC_FETCH,0xefffe68c)
11255 1 ntpd CALL ioctl(7,PPS_IOC_FETCH,0xefffe68c)
11255 1 ntpd CALL ioctl(7,PPS_IOC_FETCH,0xefffe68c)
11255 1 ntpd CALL ioctl(7,PPS_IOC_FETCH,0xefffe68c)
I can provide the full ktrace files or dumps of them.
More information about the questions
mailing list