[ntp:questions] Re: Basic MSF clock setup
jonathan at uk.me.buzzard
Tue Nov 11 11:49:01 UTC 2003
In article <aUsd88HVdKs$EwnR at nospam.oak-wood.co.uk>,
Chris Hastie <chris at nospam.oak-wood.co.uk> writes:
> It strikes my that it shouldn't be too difficult to adapt the GENERIC
> driver for raw MSF, based on the existing raw DCF mode. Would there be
> any advantage to doing this over using radioclkd2 and the SHM driver?
> Has anyone already done it? If not, is there a blindingly obvious reason
> why not?
There would be little or possibly negative advantage in doing so.
The pulse front edges are unlikely to be time stamped as accurately
using the RxD interface as the DCD line via either the Linux ioctl
or the PPS API. Another bigger reason is that the hardware you
have built is unlikely to interface to the RxD pin on the serial
port properly. Remember the hardware is being kept as simple as
possible to make it easier to build.
> The other thing I'm wondering about is PPS. In effect I have a PPS pulse
> at DCD, with the proviso that pulse width varies and occasional pulses
> are missing. I know radioclkd2 makes use of the PPS capabilities of
> FreeBSD, although I don't really understand how or what the implications
> of this are.
It get super accurate time stamps on the rising/falling start edge of
the second pulse.
> Reducing the poll interval of the SHM driver to try to
> improve synchronisation doesn't work as it ends up being reported
> unreachable for most of the additional polls and then being discarded.
> So I tried adding a PPS driver:
>|# ln -s /dev/pps1 /dev/ttyd0
>|server 127.127.22.1 minpoll 4
>|fudge 127.127.22.1 flag2 1 time1 0.0213
> This sort of works. Except every so often a poll of the PPS driver gives
> an unexpectedly high offset (40 to 45mS on the whole). Which leads ntpd
> to 'clock hop' between PPS and SHM somewhat, with PPS reporting quite
> large jitter at times. I presume this is caused by the occasional
> missing pulse.
>|fudge 127.127.22.1 flag2 1 time1 0.0213 flag3 1
> seems to mean that I never manage to catch these unusual offsets, but I
> do see PPS jitter shooting up every so often and the PPS signal being
> marked as an outlyer.
> Is there something else I should be doing? am I trying to do to much?
> Have I completely missed the point? Is using the PPS driver on a raw MSF
> signal a complete waste of time?
The best bet is to do some time pulse clock averaging in the SHM driver.
It improves jitter by an order of magnitude. Consider it a poor
man's PPS. If you really have need for PPS then you should use
a GPS unit. Remember the philosophy behind my radioclock is to have
really simple physical hardware with smart software to deliver a
previously unobtainable simplicity/price/performance ratio. It
does not attempt to rival the accuracy of a GPS unit, though it
can make for a dirt cheap backup time source.
Jonathan A. Buzzard Email: jonathan (at) buzzard.me.uk
Northumberland, United Kingdom. Tel: +44 1661-832195
More information about the questions