In message <[email protected]>, Bruce Griffiths writes: >Hej Magnus > >Magnus Danielson wrote: > >How exactly can one measure the resultant performance or even select the >optimum time constant and damping factor if one doesn't have a quieter >reference? >Can one really resort to some sort of N cornered hat?
I experimented with that, and you can actually get pretty far with simpler standalone means such as periodograms of zero crossings. My theory behind this is that the noise (of all kinds) is basically gaussian or other symmetric distributions. Consequently, the offset between your oscillator and the reference should also have a symmetric distribution of sign, subject to well known random "paradoxes" like the fact that repeatedly rolling 6 with dice doesn't prove you cheat, you might just be very very lucky. I have not fully developed this lead, and would welcome others to experiement and improve on it, it takes more patience and stability than my lap can muster when it must also work for my salary. The way I autotune the timeconstant of the PLL in NTPns is based on this lack of zero-crossings of the offset from the reference input: The first sign that a PLL has been torqued to hard is that the reference input is not able to steer the oscillator adequately and you can detect this very early, by monitoring how long runs you have where the offset from the reference stays the same sign: the runs on one side will get longer and more frequent than on the other side. You can also tell that the timeconstant is too short, because the runs are not long enough, indicating that the PLL follows the reference signal more aggresively than it need. Look in the main/pllmath.c file of NTPns to see my current implementation. (http://phk.freebsd.dk/phkrel/). One of my NTP servers use the same GPS PPS to steer the PRS10 Rb and for the NTP data feed, so the NTPns should obviously end up with a zero frequency error, since the PRS10 takes care of that. Consequently the PLL keeps stretching the timeconstant of the software PLL, until it had identified a 2e-18 rounding error in the frequency estimation code in the kernel. The third order code on the other hand, does not seem to do me much good yet, but maybe I simply don't have good enough kit for that to be dominant. The experiements I would propose requires that you can get hold of the reference/oscillator difference signal somehow, and then what you want to do is simply record runs of these values for various timeconstants and damping factors. The run them through a statistical package, or possibly even the DIEHARD tests, and see how different timeconstants score, the ones where the offset looks most random are optimal. Have fun :-) Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [email protected] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
