Rising/falling edge detection

James Clark <[email protected]>
Newsgroups gmane.comp.time.chrony.user
Message-ID <CANz3_EY3egJ6OgtRRjuzQ_LG3iY6eH28duxRHNScQ8yWL-19BQ@mail.gmail.com>
I moved my chrony setup over to a PC with an i210 and an external u-blox
GPS. The default pulse width with u-blox GPS modules is 0.1s, and I haven't
changed that, so in the PHC refclock I'm specifying width 0.1. The
documentation for the width refclock option says:

Note that it reduces the maximum allowed error of the time source which
> completes the PPS
> samples. If the duty cycle is configurable, 50% should be preferred in
> order to maximise the allowed error.


I don't understand this. I would have thought 50% was the worst possible
configuration because it prevents the use of the time between pulses being
used to identify which is the rising edge.
But the behaviour of chrony is consistent with the documentation, and it's
picky about the offset on the SOCK refclock to which the PHC refclock is
locked.  On my system the delay of the SOCK refclock is about 0.2s, but if
I specify an offset 0.3 rather than 0.2, I don't get any PPS samples at all.

My expectation would be that if you have a width of 0.1, then you can
reliably use the interval between pulses to determine which is rising and
which is falling, and so the use of width shouldn't reduce the maximum
error of the time source at all. If I specify a delay of 0.5, isn't it
reasonable to allow anything from, say, 0.1 to 0.9 as being the completing
sample?

My config is:

refclock PHC /dev/ptp0:extpps:pin=0 width 0.1 poll 0 precision 1e-7 refid
PPS lock UART
refclock SOCK /run/chrony.clk.ttyUSB0.sock poll 0 offset 0.2 noselect refid
UART

James
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.