OCXO Phase Noise Measurement in Primitive Conditions
I have my GPSDO developed well enough now that I'm correcting for the quantization error given by my LEA-6T. As I watch the phase difference plot, it seems a bit more noisy than it should be. I've also had to make the DAC pretty active to keep the phase noise on a short leash. So, I'm wondering what I have around here that I can use to measure the phase noise of my OCXO.
For test equipment I have:
My ex-telecom Rb that I turned on last night showed poor frequency stability over night, so I'm going to let it bake for a day or two to see if that improves.
An HP 10811 standard in my 5335A, and the 5335A itself to measure time interval. I have GPIB and I can capture the TI from the 5335A.
An ADR-291 Voltage Reference to lock the EFC of the OCXO to a known value.
My thought was to begin by locking the DAC to a single value and plot an ADEV against the Rb. Is there anything else I can do with this somewhat primitive time lab?
Bob - AE6RV
In message 1409158879.13035.YahooMailNeo@web142706.mail.bf1.yahoo.com, Bob St
ewart writes:
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@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.
Hi Poul,
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.
http://evoria.net/AE6RV/TIC/GPSDOe.png
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.
http://evoria.net/AE6RV/TIC/TIC.png
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
unwrapped.
http://evoria.net/AE6RV/TIC/Rb.png
Bob
From: Poul-Henning Kamp phk@phk.freebsd.dk
To: Bob Stewart bob@evoria.net; Discussion of precise time and frequency measurement time-nuts@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@web142706.mail.bf1.yahoo.com, Bob St
ewart writes:
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@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.
Poul-Henning,
On 08/27/2014 07:32 PM, Poul-Henning Kamp wrote:
In message 1409158879.13035.YahooMailNeo@web142706.mail.bf1.yahoo.com, Bob St
ewart writes:
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.
I followed the paper-trail back to an article by Judah Levine, that
describes it in the context of the ACTS system. It's translation over to
NTP is somewhat unfortunate, due to the difference in noise characteristics.
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.
The "Allan intercept" is rather the intercept point between the Allan
variance of the reference signal and that of the local oscillator. In
the original paper separate measurements made the intercept point more
or less a static value for those assumptions.
The noise of a packet network and the noise of a modem line of that time
is quite different in characteristics.
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.
I agree. As long as you are in the right neighborhood, you do fairly
well. You just need good enough models to properly model the
neighborhood you're in.
I have yet to seen a thorough ADEV/AVAR analysis of that cross-over
point for optimum performance, all I have seen is translation of the
phase-noise type rule-of-thumb analysis.
Cheers,
Magnus
I suspect that a big part of the reason why the curve is flat
is due to the noise-spectrum of GPS.
I also think that's why there is no mathematical foundation for
this concept: It may be GPS specific.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@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.