On 8/23/2011 22:26, A C wrote:
On 8/23/2011 21:26, David Lord wrote:
A C wrote:
On 8/23/2011 15:27, unruh wrote:
On 2011-08-23, Uwe Klein<[email protected]> wrote:
unruh wrote:
But from his test, his system is labelling both edges.
so he has bounces on the line?
either that or rise/falltime is so low and noise so high
that receiver hysteris is not sufficient to supress multiple
HL/LH changes?
No, his test shows that the line changes and then 100ms later it
changes
back and 900ms later it changes again (ie once per second it rises and
falls.) Ie, it is behaving exactly as it should if it were detecting a
pulse 100ms long.It is detecting both the rising and falling edge.
I just checked and the pulse is almost exactly 100 ms low going and
900 ms high (within about 1 ms) so it's 90% duty cycle high most of
the time with a swing low. The signal itself is clean down to
microvolt levels. The total voltage swing is about 12 volts (which
would stand to reason since I'm feeding the TTL level PPS output of
the GPS board through one channel of a MAX232 level shifter).
Therefore the machine is receiving a nice, clean PPS signal on DCD
(DCD pin was also verified yet again and is correct by hardware
specifications).
You seem to be saying that the rs232 signal is low going,
ie low for 100ms then high for 900ms?
Previously I had the impression the pulse was high going
and you were using 'flag2 0'.
Ntpd requires the prefer peer to be within mindist before
even considering the PPS and then the system clock has to
be within a millisec of the PPS. Using one of your other
sources as prefer peer and having NMEA disabled might give
you a better chance of getting the pps working without
having to bother about the time2 value.
At first I couldn't remember which way the pulse went. But having
measured it now the voltage goes low (which would be an assert under
RS232) for 100ms and then returns to high voltage for 900ms.
Either way, flag2 made no difference (I did try it both ways) but I'll
try it again using another network clock as the preferred peer and see
what happens.
I should point out that whenever I add the PPS refclock into the
configuration ntpd complains that it is not reachable and eventually I
get the message "clock_event clk_no_reply". Shortly after that ntpd
crashes (actually, it get stuck in some kind of loop waiting for
something but sending a SIGUSR1 several times to pump up the debug level
shows nothing.)
Any suggestions for the configuration now given the new data?
I've got a set of six network sources to provide basic timing.
The GPS_NEMA refclock is currently configured as:
server 127.127.20.1 minpoll 4 mode 1
fudge 127.127.20.1 time2 0.245 refid GPS
The last PPS_ATOM refclock was configured (but is currently disabled
because it crashes ntpd) as:
server 127.127.22.1
fudge 127.127.22.1 flag2 1 flag3 1 refid PPS
Can I add both? Should I add both? Or should I just enable one? If I
enable only GPS with PPS I'd be trying the last configuration I used for
that (with flag1 set):
server 127.127.20.1 minpoll 4 mode 1
fudge 127.127.20.1 time2 0.245 flag1 1 flag2 1 flag3 1
However, setting flag3 for the GPS_NMEA refclock also crashes ntpd. It
simply freezes waiting for something.
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
