Help me understand allan deviation measurements.

[Vgkid]

The c-mac has been powered on continuously for almost 2 months. The HP if not been running outright, has been under standby conditions for 3 months longer than the c-mac. Currently powering on the lpro.

[Vgkid]

just finished up running a short(1hr) plot of the cfp04 vs the lpro. there is definately an oscillation occurring in the allan variance plot.

[edpalmer42]

Notice that the 'period' of the oscillation in the AlDev graph is about 100 seconds, so the 'frequency' is about 0.01 Hz.  Noise like this can come from anywhere, but such a low frequency likely means that the two input signals are mixing together and you're seeing the difference frequency (aka the beat frequency).  Look at the residual phase difference (hit P, then R).  It's really obvious there.

Possible causes are:
- input levels to the counter are too high
- cheap or defective cables - in particular, poor or defective shielding
- coupling through a common power supply
- some type of ground loop between the oscillators

Problems like this are not unusual when dealing with Allan Deviation.  After all, you're pushing into the parts-per-trillion range!

Ed

P.S.  Instead of posting Excel files, just save the data from Timelab as a .tim file.  Then zip and post that.

[Vgkid]

I will try that. Will will upload last night 8hr run either tonight, or tomorrow. I have the counter set to a 1 second gate time(1.02s). When i viewed the frequency the hightst peak(which was rather frequent ) corresponded to the last digit changing by 2. The lowest peak would have dropped the count by 1.(.010 hz per count)

[Vgkid]

When I was reading about ocxo decoupling caps, this document from Connor Winfield proved to be excellent. I have much to implement.
http://www.conwin.com/pdfs/AN2093.pdf
also uploaded the zip files

[edpalmer42]

The Conner-Winfield document is good, but it might be premature to put a lot of effort into the OCXO. 

Something went a little crazy in the last 1.5 hrs of your data.  It could have been a temperature change, voltage change, or just the OCXO being perverse.  (They do that, you know!  )  Select that data on the phase graph and delete it.  Yes, you're allowed to do that.  The data doesn't reflect the true performance of the oscillator so it's okay to delete it.  Just like the glitches.  I'm not sure where legitimate deletions end and 'cherry-picking' begins.

Now go back to the AlDev graph and you'll find that at Tau=10K sec. your AlDev has improved by almost 10x, but you've still got those stupid oscillations!  The Lpro has AlDev specs of 2.5e-11@1sec and 2.5e-12@100sec.  The CFPO-4 datasheet doesn't list AlDev specs, but the phase noise specs are much better than the LPRO which suggests that the AlDev numbers will also be pretty good although the correlation between AlDev and Phase Noise is far from perfect.  Since both of them should be far below the measurements you've got, it suggests that the wiggles could be related to your counter!  The level where the wiggles are is similar to what I expect for the counter's noise floor.  Have you measured the counter's noise floor as I described earlier with the cables and T-connector?  If not, you should do so before you spend a lot of time on the CFPO.

This is the kind of analysis and detective work that often happens when you're making AlDev measurements.  What makes sense?  Are these results believable?  Too bad to be valid - Is something wrong?  Too good?  Yes, that can happen too.

Setting the oscillations aside for the moment, you may already be running into the limitations of your 5335 counter.  Its resolution spec of 1 ns. means an AlDev of 1e-9@1sec.  You're seeing 4.4e-10@1sec. so it's better than spec.  Imagine drawing a line through the straight section on the left of the AlDev graph, through the bottom of each wiggle, and on to the straight section on the right of the graph.  That's what you'd see without the wiggles.  The slope isn't what I expect to see, but I'm not familiar with the 5335.  I've attached a picture showing noise floor measurements for my counters.*

If this is the noise floor of your counter, it doesn't mean that your counter is worthless.  It does mean that you can't use it to make measurements at low values of Tau.  The results will get lost below the counter's noise floor.  That's a fact of life with every counter.  I made lots of useful measurements and learned a lot by using my Racal Dana 1992 which has a 1 ns resolution, just like your 5335.  I just accepted the fact that I probably was blind to anything below about 100 sec.  As you get better and better counters, you can make measurements at lower values of Tau.  If I wanted to look at an LPRO, the only counter I could use is the Wavecrest DTS-2077.  The others aren't really good enough.

Ultimately, counters are not the way to go when you're trying to make measurements at insanely low AlDev values.  You have to go to other measurement architectures.  That's not something you should get into at this time.  It'll make your brain hurt!

Ed


* (For anyone who's paying attention, yes, there's something wrong with my 5370B.  It should be much better than that!)

Edit:  Forgot the picture. 

[VK5RC]

Please correct me if I am 'barking up the wrong tree', I think the 5335 does not do continuous frequency-time measurements (1), i.e. there is a delay between measurements "dead time", I thought in this situation  the M-sample variance was the mathematical  tool to use. I am not sure what difference this will have on your data.

Other instruments e.g. 5371A (2), 53230A (3) use continuous or interval free frequency/period measurement, I have heard this also called "time stamping".

(1) http://www.keysight.com/upload/cmc_upload/All/EPSG084786.pdf         see p2 ;General ;Cycle
(2) http://www.keysight.com/en/pd-1000001409%3Aepsg%3Apro-pn-5371A/frequency-and-time-interval-analyzer?cc=AU&lc=eng
(3) http://www.keysight.com/en/pd-1893420-pn-53230A/350-mhz-universal-frequency-counter-timer-12-digits-s-20-ps?cc=AU&lc=eng

[edpalmer42]

Please correct me if I am 'barking up the wrong tree', I think the 5335 does not do continuous frequency-time measurements (1), i.e. there is a delay between measurements "dead time", I thought in this situation  the M-sample variance was the mathematical  tool to use. I am not sure what difference this will have on your data.

Other instruments e.g. 5371A (2), 53230A (3) use continuous or interval free frequency/period measurement, I have heard this also called "time stamping".

Yes, deadtime will have an affect on these measurements.  I made an 'executive decision' that deadtime was a complication that should be ignored for the time being.  There's more than enough things for a newbie to learn when trying to absorb the basics of Allan Deviation without burying him under a mountain of topics.

Ed

[VK5RC]

Thanks, I don't know enough about the maths, I was wondering if that was the reason behind the anomalies in the data.

[edpalmer42]

Thanks, I don't know enough about the maths, I was wondering if that was the reason behind the anomalies in the data.

You mean the wiggles?  No, that's definitely caused by interference (noise).  It could be external RF noise, power line interference, mixing between the oscillators and/or the counter, etc.  I've seen that before both on the bench and in various documents.  You can even see a bit of it on one of my noise floor graphs.

I either ignore the deadtime question completely or avoid it by configuring my measurements so there is none.  If you use 1 PPS as your start signal, and a higher frequency as your stop frequency, you can guarantee that your counter can make a measurement and recycle for the next one before the next start signal appears.  The only thing to watch out for is if your counter needs a start pulse to reset itself so you can only measure every second start pulse.  I think I've seen that behaviour, but I haven't really investigated it.

By the way, if anybody isn't afraid of the math you can check out the Wikipedia article on Allan Deviation.  There's also a list of reference documents and sites that have more info on AlDev and its cousins.

https://en.wikipedia.org/wiki/Allan_variance

Ed

[awallin]

I either ignore the deadtime question completely or avoid it by configuring my measurements so there is none.  If you use 1 PPS as your start signal, and a higher frequency as your stop frequency, you can guarantee that your counter can make a measurement and recycle for the next one before the next start signal appears.  The only thing to watch out for is if your counter needs a start pulse to reset itself so you can only measure every second start pulse.  I think I've seen that behaviour, but I haven't really investigated it.

This paper explains how ADEV is related to the area (integral) under the phase-noise curve:
http://www.researchgate.net/publication/6308454_Considerations_on_the_measurement_of_the_stability_of_oscillators_with_frequency_counters

ADEV is defined using a 'box' response to the frequency signal (hence the name pi-counters) and that gives a certain kind of weighting function when calculating the area under the phase-noise curve.
If you mess with this ideal box-shape such as making it triangular ('lambda-coutner', 53132 default?) or rounded ('omega-counter' (?) 53230 default?) or introduce dead-time (the + and - side of the box move apart) then you will not get the ideal weight-function in the phase-noise integral calculation.
It's almost absurd that to get correct ADEVs on the 53230A you have to use the *undocumented* RCON mode...

By the way, if anybody isn't afraid of the math you can check out the Wikipedia article on Allan Deviation.  There's also a list of reference documents and sites that have more info on AlDev and its cousins.
https://en.wikipedia.org/wiki/Allan_variance

My allantools python library has the algorithms in plain sight (unlike Stable32 or TimeLab...):
https://github.com/aewallin/allantools
it is fairly rigorously tested against Stable32 and gives identical results. patches welcome.

Anders

[edpalmer42]

I either ignore the deadtime question completely or avoid it by configuring my measurements so there is none.  If you use 1 PPS as your start signal, and a higher frequency as your stop frequency, you can guarantee that your counter can make a measurement and recycle for the next one before the next start signal appears.  The only thing to watch out for is if your counter needs a start pulse to reset itself so you can only measure every second start pulse.  I think I've seen that behaviour, but I haven't really investigated it.

This paper explains how ADEV is related to the area (integral) under the phase-noise curve:
http://www.researchgate.net/publication/6308454_Considerations_on_the_measurement_of_the_stability_of_oscillators_with_frequency_counters

ADEV is defined using a 'box' response to the frequency signal (hence the name pi-counters) and that gives a certain kind of weighting function when calculating the area under the phase-noise curve.
If you mess with this ideal box-shape such as making it triangular ('lambda-coutner', 53132 default?) or rounded ('omega-counter' (?) 53230 default?) or introduce dead-time (the + and - side of the box move apart) then you will not get the ideal weight-function in the phase-noise integral calculation.
It's almost absurd that to get correct ADEVs on the 53230A you have to use the *undocumented* RCON mode...

......Now you see why I try to avoid deadtime at all costs! 

By the way, if anybody isn't afraid of the math you can check out the Wikipedia article on Allan Deviation.  There's also a list of reference documents and sites that have more info on AlDev and its cousins.
https://en.wikipedia.org/wiki/Allan_variance

My allantools python library has the algorithms in plain sight (unlike Stable32 or TimeLab...):
https://github.com/aewallin/allantools
it is fairly rigorously tested against Stable32 and gives identical results. patches welcome.

So then, you're one of the 6 people on the planet who actually understands this stuff.  Good to know!

For those not familiar with Stable32, it's a closed-source professional level program for analyzing oscillators.  It's basically the 'gold standard' for this type of analysis.  The cost is US$395.  Check out the web site.  There's lots of free documents that are interesting to people learning about oscillator analysis.  http://www.wriley.com

Anders, I'm puzzled by your statement regarding Timelab and its algorithms.  The source code is distributed with the program.  How can the algorithms not be in 'plain sight'?

Ed

[awallin]

Anders, I'm puzzled by your statement regarding Timelab and its algorithms.  The source code is distributed with the program.  How can the algorithms not be in 'plain sight'?

Oops I did not know that    - apologies. I just assumed that since it's available as a binary for windows the code is probably closed source.
I'll have to take a look at some point then! 

Not exactly sure what the license on p157 here means...
http://www.miles.io/TimePod_5330A_user_manual.pdf
If I took parts of the codebase, modified to compile under linux, would it be ok to put it all under GPL or LGPL?? I might ask JM himself I gues..

TimeLab is much more user friendly and modern compared to Stable32. The live-plot of ADEV etc. during data acquisition is particularly nice.
+1 and  for KE5FX

AW

[edpalmer42]

Hi Vgkid,

I wanted to run a similar test to the one that you're doing to see what my results would be.  I grabbed a cold Trimble 65356 OCXO, hooked it up, let it warm up overnight and then made some measurements. 

I've attached a picture of my Time-Nuts grade test setup.  As Dave would say, "A thing of beauty and a joy forever". ..........or maybe not...........  I used an HP 53131A counter (which has similar specs to your 5335) and compared the OCXO to my Efratom FRT Rb standard.  The connection between the counter and the FRT was a double-shielded BNC cable.

The second picture shows the results I got.  What's significant here is that despite my sloppy wiring, there's no trace of the kind of noise that you're seeing.  That's why I'm suspicious of your counter.  Actually, at this point, I'm suspicious of everything!  But I don't think that bypass capacitors and ground planes are going to fix your problem!

I've also included the .tim file of the measurements.

Ed

[Vgkid]

So I ran the plot to graph the noise, the first file has a sample interval of .29s, which is about the rate the gate time led flashes at.  The delay between the 2 channels was 3-4 nS. Sometimes it would switch back and forth between the 2 values really slowly. Other times it change back and forth between the 2 values every update.
The second file is with the time interval set to 1s, considering that itis a whole 10x lower, I don't think that this is correct.
**looking at the previous graphs(cfp04) the 1s recordings are lower than the 'noise' graphs. Interesting

[edpalmer42]

The first file (5335baseAldev) looks good.  A little better than spec @ 1 sec and trending down exactly as it should.  The second file (5335baseAldev_1sec) looks like it might be making multiple measurements, averaging them, and then rounding the result off to the nearest ns.  That's why almost all the values are 4 ns.  If one measurement take ~.29 sec., then you'll get 3 measurements in 1 sec.  If one of them is 3 ns, the average will round up to 4 ns. Averaging multiple readings is what you don't want to do because it makes things look better than they are.

So the problem isn't the counter.

I did some more tests here.  I replaced the cable between the Rb standard and the counter with a cable I know is crappy.  No change in the results.  Then I wrapped the two crappy coax cable together for about 1 meter.  Still works.  Then I removed the ground lead from the output cable from the oscillator.  The only way for the OCXO signal to get to the counter is through whatever stray capacitance happens to exist between grounds.  The signal level dropped significantly, but it did it.  Still no wiggles like you're seeing.

What other hardware do you have available?  Counters, oscillators?  You don't need to use the LPRO, just any two oscillators to compare.  One or both could be in other pieces of test equipment as long as the signal is output on the back panel.  Do you have a GPSDO or just a GPS with a 1PPS output?  It makes a perfect start pulse.

Ed

[Vgkid]

Im re running it with another cfpo4, this one has only been powered only 10hrs(I think im the first one to use these). Testing it against the internal 10811, to see if those wiggles are present.

[Vgkid]

I'm uploading the specs and the first real run of the oscillator against the HP's internal one. package 40, A1.
also uploading the Aldev chart, the ocxo only has 15 hours on it.

[edpalmer42]

This run looks a bit better.  The interference is still present, but the level is lower and it fades out quicker than before.  One problem that's more obvious now is the odd slope at the beginning of the graph.  Ignoring the interference, it takes about two decades of time for the AlDev to drop one decade.  I've never seen that slope before.  It's always a one-to-one relationship like you saw in the noise floor graphs.

It turns out that the slope of the graph tells you what kind of noise is present in the measurement.  The one-to-one type noise is called "white phase" or "flicker phase" noise.  Those are two seperate types, but AlDev can't seperate them.  The two-to-one noise that you're seeing is called "white frequency", also known as "white fm" noise.  I found a document at NIST ( http://tf.nist.gov/phase/Properties/twelve.htm ) that states that white FM noise is commonly found in Rb and Cs standards.  Have you checked the output of your LPRO for any problems?  Ideally, check with a scope and a spectrum analyzer.

Is this recent run comparing the LPRO to the second CFPO?  If so, maybe try comparing the two CFPO oscillators.  We don't need the Rb to make this measurement.  As long as the frequency between the oscillators doesn't drift too far apart Timelab can handle it.  If the noise and/or interference is coming from the LPRO you'll see the difference with just a few minutes of data so the drift should be minimal.

I wonder if the LPRO (or the CFPO) could be putting out a harmonic that's confusing the counter.  I recently got tripped up by high frequency noise in a similar measurement.  Do you happen to have a couple of 10 or 15 MHz low pass filters (or any low pass filters) that you could throw into the circuit?  I realize that they're not the most common thing to have around, but they do help when you're wandering around in the PPT neighborhood.

Ed

[Vgkid]

That was being tested against the HP's internal ocxo, the lpro has not been hooked up yet. I'm attaching a image of the first run, the new cfp0 only had 5 hours on it.
**On the previous plot, I'm wondering if the strange graph is a result of the measurement having to be aborted at the 66% mark(lost power).

[edpalmer42]

Okay, then I have no idea where your interference is coming from or why you've got that odd slope on the AlDev graph.

Aborting the data collection won't have any effect on the graph.  I'm sure you've noticed that as the data is collected, the right-hand end of the graph moves around, sometimes quite dramatically, while the earlier parts of the graph become stable.  Aborting the data run has the same effect as reaching the end of the data run - whatever data is on the right side of the graph has a larger error band than data on the left side of the graph.  Hit Ctrl-E to display the error bars and you'll see what I mean.

Ed

[plesa]

I tried to repeat your measurement with RbXO and my counter but I cannot connect Timelab to my counter is there any trick? I tried IP address with port but it does not work.
I have few double oven oscillators, 2x OCXO IsoTemp 131-191 and others oscillators to compare.

[Vgkid]

I had mine configured in talk only mode, i cant remember if it would give an error in listener mode. Though how I understand it, listener mode could fully control the counter.

[Vgkid]

I reran both ocxo's against the internal 10811A

[edpalmer42]

There's still way too much noise and interference here.  I'm baffled.  Grasping at straws here, try adding a small capacitor (20 or 30 pf) across the output of the oscillator.  Maybe that will help cut down any high frequency noise that's coming either out of or into the circuit.  Can you post a sketch or photo showing how you've got everything connected?

I powered up an LPRO to see if there was something odd about that model, but it's running fine.  I'm comparing it to my FRT.  The data run was going so well that I just let it run - it's still going on.  I'm powering the LPRO from an ordinary variable lab supply with clipleads.  The 10 MHz output is connected by a crappy cable.  I've attached a quick drawing showing what I'm doing.  My data has some wiggles, but they die out quickly.  I think I'm getting a bit of interference between the channels in the squarer/divider board.  Squaring up the circuit reduces trigger noise and gives better results.  Dividing the frequency down reduces the number of phase wraps.  I made my measurements with a Fluke/Philips PM6681 counter in Time Interval mode using the 'Single' mode.  Dead time may have an effect on these measurements.

I'm going to walk through the data for this run to give you an idea of how to do the analysis.  I hope it will help you to troubleshoot your situation.  Obviously, the values will vary with the counters and oscillators used, but the analysis will be the same.

Start with the black line on the AlDev graph which is the raw data.  Notice that the graph follows a straight line down.  This is the counter noise floor.  The performance of the oscillators is completely masked by the counter.

There may or may not be a flat bottom section between the falling and rising portions of the graph.  This is the combined noise floor of the counter and oscillators.

The rising part of the graph means that drift is coming into play.  The drift is actually the sum of the drifts of the two oscillators.  This can be tricky because if they're drifting in the same direction the drift might look much lower than it really is.  If they're drifting in opposite directions, the result will look much higher than it really is.  If you're comparing a quartz oscillator to either a Rb standard or a GPSDO, the rising portion is almost totally due to the quartz oscillator.  One thing to note is that if your data run is long enough to get to 86400 seconds (i.e. one day), you've just measured the daily drift on your oscillator.  This is the most common way of specifying a quartz oscillator.  Rb oscillators are usually specified in terms of drift per month.

When I looked at the Phase Difference (Linear Residual) graph, I saw that there was an anomaly at about 29000 seconds.  There was a significant change in the slope of the graph.  On a hunch I looked at the Original Phase Difference graph and saw that the anomaly happened at the same instant as a phase wrap.  The effect that the phase wrap had on the slope of the graph is very odd.  I can't explain it.  I hope that I see another phase wrap before the data run ends.  I decided to delete the data that came before the phase wrap.

Normally, drift is removed before you look at AlDev.  AlDev looks at aspects of the oscillator's stability that are fundamentaly different than drift and drift just confuses the analysis.  So my next step was to remove both the linear and quadratic drift components from the data.  The results of all this manipulation are shown in the blue line.

Since I was comparing two units that may or may not have similar specs, I can't really say that the blue line represents the LPRO.  Normally, you use a reference that is much better than the device under test.  That way you can be certain that your results reflect the performance of the device under test.  If you're measuring two units that might be similar you have to make assumptions.  At these levels, even two units that are the same model number are far from identical so your assumptions are probably invalid!

The .tim file is too big to attach here so I uploaded it to Mediafire.  Here's the link:

http://www.mediafire.com/download/wq3q8jublm2ekw8/LPRO_vs._FRT.zip

Ed