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<[email protected]> 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.
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
