[time-nuts] OCXO Phase Noise Measurement in Primitive Conditions
bob at evoria.net
Wed Aug 27 15:00:22 EDT 2014
I'm not really sure what you mean by the term "timeconstant" WRT my GPSDO
and not some other algorithm.. So, to avoid a discussion of that, let
me just post links to some plots and note that there are very few and
very small corrections for the position term by the PID controller. I'm using a sort of deadband filter for the p
term damping set at 10 counts summed for direction.
The first is to the last 2 hours on the GPSDO, and it has a lot of
information on it. Blue is the DAC. It has a lot of bits, so it's
scaled down to make it usable. True values are on the left in hex,
though the resolution is multiplied by an additional 3.75 or so in
hardware. The red is the phase in hundreds of ps measured by my TIC after correction for quantization errors. The green is raw ambient temperature which obviously doesn't have enough gain to be useful. The purple is the TI of the Rb to the GPSDO output in ns as a comparison
for the final plot.
The next plot is an ADEV of approximately the same timeframe for the
corrected TIC from above. The green is the TIC the blue is the ADEV.
And finally is an ADEV of approximately the same timeframe of the Rb
against the OCXO output as measured by my 5335A. Here the Rb phase is
From: Poul-Henning Kamp <phk at phk.freebsd.dk>
To: Bob Stewart <bob at evoria.net>; Discussion of precise time and frequency measurement <time-nuts at febo.com>
Sent: Wednesday, August 27, 2014 12:32 PM
Subject: Re: [time-nuts] OCXO Phase Noise Measurement in Primitive Conditions
In message <1409158879.13035.YahooMailNeo at web142706.mail.bf1.yahoo.com>, Bob St
So here is a pretty interesting way to optimize a GPSDO that I've
been playing with for some years. I don't have a formal mathematical
formulation of it.
It is somewhat related to what Dave Mills calls "the Allan intercept"
except this you can actually measure and not just estimate.
You run several (long!) test-series with different timeconstants
in your PLL, and you record the resultant EFC and phase offset
as a function of time.
If your timeconstant is too short, you will have a lot of
high-frequency signal in the EFC, too long and you get too
much high-frequency signal in the phase offset.
The optimal timeconstant is where you have the least sum of
spectral power where the two curves cross each other.
My experience so far is that the curve around the optimum is
very flat, getting the timeconstant wrong by a factor of two
hardly changes the resultant performance.
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
More information about the time-nuts