Help me understand allan deviation measurements.

[KE5FX]

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.

That's a weird one, all right.  I haven't followed the whole thread but I loaded your file and it does look a bit unusual.  Try this:

f
g 300 to set a 300-second averaging window
r to look at the residual (make sure z mode is off)



You can see that the frequency drift settled down about 6 hours into the run, then, at 8 hours, the frequency of one of the sources jumped a bit.  That's what caused the phase wrap, or at least was associated with it.  It then started drifting back up.

Overall, your ADEV looks reasonable for a pair of rubidium standards that haven't been powered on for very long, and/or are in an unstable environment.  One or the other of your test sources needs some more time to settle down, it looks like.  Hit e and change the Trace History to 3, and you can see the effect I'm talking about:



Your later (darker) traces look more like my measurement of an LPro with an HP 5370B.

Moral of the story (or at least my post): look to the frequency-difference view to find out what's going wrong with your ADEV view.  It's very hard to use ADEV as an initial diagnostic.

[edpalmer42]

Hi John,

Good to hear from you!

Thanks for the info.  I knew that Timelab had more features than I was using.  I'll have to dig into the two you described.  Why do your graphs show the Sampling Interval as 1 sec.?  The actual interval was 0.1 sec.  Did you decimate the data before analysis?  Any reason, other than processing speed, to do that?

The FRT that I used runs 24/7 and has done so for a few years so it's well warmed up.  The aging is so low that it's a royal pain to measure.  I check it a couple of times a year against my Z3801A and try to calculate an aging number.  Maybe 1e-11/month, maybe less.

The LPRO has only been running for a few days.  The initial frequency drift was more than I expected, but after that phase jump it's performance has been good.

If you have time, could you read over this thread?  I'm trying to help Vgkid get started with AlDev, but he's having trouble with his data.  There's interference and noise present that I can't make head or tail out of.  The file you commented on was my attempt to describe an analysis to help him debug his situation.  I'm out of ideas on how to help him.

Ed

[KE5FX]

Hi John,

Good to hear from you!

Thanks for the info.  I knew that Timelab had more features than I was using.  I'll have to dig into the two you described.  Why do your graphs show the Sampling Interval as 1 sec.?  The actual interval was 0.1 sec.  Did you decimate the data before analysis?  Any reason, other than processing speed, to do that?

Just to speed up the load.  If something takes more than a few seconds to load and I don't care about short-term data, I will usually hit 'e' while it's loading and bump up the sample interval by 10x or so.

If you have time, could you read over this thread?  I'm trying to help Vgkid get started with AlDev, but he's having trouble with his data.  There's interference and noise present that I can't make head or tail out of.  The file you commented on was my attempt to describe an analysis to help him debug his situation.  I'm out of ideas on how to help him.

No prob!  Will check it out... watch this space...

Edit: The plots from Vgkid basically look OK at first glance, except for the ADEV ripple.  That's often caused by crosstalk.  Either the DUT and reference sources are coupled to each other somehow, or there is interference from another 10 MHz source in the vicinity.   Make sure the RF connection(s) to the counter are secure and well-shielded.  The oscillator(s) may need additional power supply bypassing as well.  Some of them can radiate and receive a lot of 10 MHz energy through their power leads. 

A calibration or maintenance issue with the counter might cause it as well but I'd suspect crosstalk first.  Take the reciprocal of the first 'dip' in the ADEV plot and look for two sources with a frequency offset that matches.  E.g., in the new_cfp_1hr_A.tim file, there's a dip near t=4s, so see if you have a couple of sources that are about 0.25 Hz apart.  The frequency difference shown in TimeLab is about 0.2 Hz so the source(s) connected to the counter may not be the problem.  But if you had a third 10 MHz source in the immediate area, that could account for it.

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

You're welcome.     The TimeLab license is basically a 3-clause BSD license.  It's compatible with the GPL, in that any user who follows the GPL's terms is automatically OK with respect to TimeLab's.  However, if you create a GPL'ed fork, any code that you adopted or derived from TimeLab remains available under the original license.  So if anyone else incorporates that code into their own product, they cannot be held to the "viral" terms of the GPL. 

[Vgkid]

Added decoupling caps to both the vcc(47uF,smallest I had...) pin, and the output(22pF). I also powered off the old cfpo4 that has been running. I will test the new one tonight, and update tomm.

[agronaught]

This has been an extremely interesting thread, in part due to me going through the same process with my HP 5335A counter. 

I was originally getting plots as outlined by the OP, including the oscillation at high Tau shown in the recent posts.   In my case (and I'm still working through it) I noted a fairly rapid phase shift between the in internal OXCO and the LPRO-101 reference.   This frequency difference wasn't enough to show up on the meter when in frequency mode but was notable (and still is) in time interval mode.

In my case the original setup of the counter post-repair wasn't done with a higher accuracy meter as I don't have one, as it turns out it was more a best efforts setup.   I've now used my DSO in XY mode (lissajous figure) to tune the oscillator as well as I can and now have to it to a calculated 1.1E-10, still a little higher than ideal but a big improvement on where it was at.    I may be able to improve on that slightly if I can find a better pot tool, although I may simply live with it.

Since doing this I'm finding the plots generated in Timelab are what I anticipated in the first place, albeit I'm now running my first extended test (8 hours) since tweaking the OXCO to the current performance level with timelab reporting 1.25E-10 at 10s which is much better, no sign of the oscillation in the plot (yet) either.

So something you may want to check as the internal oscillator will most definitely be affecting the readings.   I followed the details outlined in the OCXO manual to tune it.

https://www.febo.com/pages/hp10811/HP10811AB-Manual.pdf

My next step is to make a couple of divider circuits for use in TI mode.

Of course, the above could have nothing to do with the problem and I've accidently fixed other issues... lol..  I'm a novice at this as well.

Cheers.

[KE5FX]

Of course, the above could have nothing to do with the problem and I've accidently fixed other issues... lol..  I'm a novice at this as well.

Cheers.

TI measurements bring their own set of pitfalls, most notably phase wraps.  If you're stopping the count with a signal whose period is 100 ns, that means that any frequency difference greater than 50 ns/sec can't be detected and unwrapped properly by TimeLab.  5E-8 is not a very big frequency offset!  Using a divider will help, and obviously your technique of presetting the frequencies with a scope is a good idea, as long as the sources don't drift too far apart during the measurement.

Using the counter in frequency mode will bias the statistics somewhat, depending on the counter model.  But in my experience most people have bigger problems to deal with in their stability measurements than obscure mathematical biases.  I usually suggest sticking with frequency-count mode unless you have specific reasons for moving to TI measurements.  With some common counters like the HP 53131A/53132A, the statistical quality of phase data taken in frequency-count mode is really quite good.

[Vgkid]

I reran the test using the new cfp0 last night against the lpro. No osicillations in the allen Dev graph, but no dips into the lower frequency stability sections(looking at the prev graph). There are 2 spikes in the frequency deviation of a large amount, I/m wondering if the cobbled up collection of adapters could be to blame. I do plan on setting some sma to bnc adapters.
//Added file

[KE5FX]

I reran the test using the new cfp0 last night against the lpro. No osicillations in the allen Dev graph, but no dips into the lower frequency stability sections(looking at the prev graph). There are 2 spikes in the frequency deviation of a large amount, I/m wondering if the cobbled up collection of adapters could be to blame. I do plan on setting some sma to bnc adapters.
//Added file

Looks like the frequency glitches correspond to phase jumps of exactly 100 ns (for the first one, zoomed in below) and 50 ns (for the second one).



So that suggests your counter reported a jump of exactly 1 Hz, and later a jump of 0.5 Hz, from one reading to the next, unless I'm missing something.  Hard to say for sure since the original frequency readings are lost, but it sounds like that could be a counter artifact of some kind.

[edpalmer42]

Although the numbers aren't the greatest, this graph is looking much better.  The graph starts at the counter's 1 sec. resolution (good!) and drops down to a flat noise floor.  The right hand side is rising which could be aging, but it could also just be the end of the graph flopping around.  It does that - sometimes quite dramatically!  Hit Ctrl-e to see the error bars.  There isn't enough data to trust the upward slope at the right hand side of the graph.  Your earlier test shows that the counter's noise floor is far below what you're seeing here so the relatively high noise floor must be due to the CFPO, LPRO, or external noise.

You could edit out the two frequency glitches, but they don't have much effect on the results.

You haven't mentioned your power supply.  What are you using?

How are you connecting the oscillator(s) to the counter?  Are you using 50 ohm coax connections or something like a scope probe?  If you're using a scope probe, you need to add a 50 ohm termination across the oscillator.  That will help suppress noise, particularly external noise, and improve the oscillator's waveform.

Ed

[Vgkid]

Im using a linear Tenma power supply, ripple wise it is in the mV range. It connects to the ocxo through about 8in of 18awg wire. The ocxo is decoupled by a 47uF cap on the power sipply, and 22pF on the output. It connects to the counter using a rg58 cable. The counter is in 50ohm mode, sometimes it will give some strange results in 1meg mode.

[edpalmer42]

Are you running both the LPRO and CFPO from the same power supply?  If so, that could have been the source of your AlDev ripples.  Your 47uf capacitor may have helped there.  I made up a couple of test modules to help in that situation.  I scavenged a couple of common mode chokes from old switching supplies.  Put film capacitors across input and output and attach wires.  You've got inline filters that work on DC power lines to block noise from going from one device to another that's on the same supply.

Keep the OCXO running and see if the AlDev graph improves.  The aging will definitely improve.  The noise floor might improve, but don't hold your breath.

Do you have a spectrum analyzer that you can use to look at the outputs of the LPRO and CFPO?

Ed

[Vgkid]

No SA, the lpro and the c-mac are powered from 2 different power supplies, both linear.

[edpalmer42]

Okay.

At this point, you have to decide what you want to do.  If you're just interested in calibrating your equipment, you've probably got all the measurement equipment and references you need.  Beyond this point you're nudging into Time-Nuts territory.  You keep looking for better oscillators, but then you need better equipment to measure the oscillators.  It never ends.  Don't ask how I know this.

Ed

[Vgkid]

That is similiar to how my electronics collection started. First came a broken gr1689, then a 6.5 digit Solartron 7065  meter, then a fluke 1952. Lets just say that the fluke was ber, and the Solartron was really out of calibration... I still have both.

[DimitriP]

Okay.

At this point, you have to decide what you want to do.  If you're just interested in calibrating your equipment, you've probably got all the measurement equipment and references you need.  Beyond this point you're nudging into Time-Nuts territory.  You keep looking for better oscillators, but then you need better equipment to measure the oscillators.  It never ends.  Don't ask how I know this.

Ed

If room temperarure wasn't messing with my 100ppm frequency counter I wouldn't have gotten into this. Now, it's too late.

[edpalmer42]

If room temperarure wasn't messing with my 100ppm frequency counter I wouldn't have gotten into this. Now, it's too late.

But you still haven't gotten away from the temperature problem.  Almost every OCXO has a spec for accuracy vs. temperature.  If you look really closely, you'll find that humidity and air pressure also affect precision oscillators.

Ed

[DimitriP]

If room temperarure wasn't messing with my 100ppm frequency counter I wouldn't have gotten into this. Now, it's too late.

But you still haven't gotten away from the temperature problem.  Almost every OCXO has a spec for accuracy vs. temperature.  If you look really closely, you'll find that humidity and air pressure also affect precision oscillators.

Ed

Luckily, I can't look into it that closely yet.   

[Vgkid]

1 week later I reran the test over 25 hours. I really need another laptop in order to run it longer, it kills me.
Looking better, though the oscillations are still there.Under the aldev plot, not the modified plot.
Added a plot in which I removed the several large frequency jumps. They seem to be present in both plots using the lpro, I do wonder if it is a connector issue.

[edpalmer42]

When I look at the Phase Difference (Linear Residual) graph, I see a nice straight line followed by a noisy, jittery section.  The pattern then repeats.  It could be a connection problem or an internal fault in one of your oscillators.

Ed

[Vgkid]

 Thanks, i will order the connectors after Thanksgiving. So the next update will be in a few weeks. Will timelab natively run under Linux. Im searching craigslist for a cheap laptop(wishful dreaming).
@ DimitriP, did you ever get your 5335 fixed?

[DimitriP]

Thanks, i will order the connectors after Thanksgiving. So the next update will be in a few weeks. Will timelab natively run under Linux. Im searching craigslist for a cheap laptop(wishful dreaming).
@ DimitriP, did you ever get your 5335 fixed?

No, it is stll "single channel"   PM me if you have somethign interesting

As for your logging problem....
If you can collect data under linux a rasberry Pi will be cheaper than almost any laptop.
Another idea I had yeasterday when I saw your post was to use a "logging" HPIB adapter... whcih can be built for less than a laptop but not as cheap as a Pi ...
Food for thought ...

[Vgkid]

Put a new fan in my counter an "ADDA Hypro", the 10 db reduction in volume is nice.
My sma cable/bnc adapter will be here tomm. So an update over the weekend will happen.
@ DimitriP  wait until after the holidays. A partout thread is in the works.

[DimitriP]

Will you share the part# for the fan ?  I wen't looking ...soooo many choices!
As for the 10db reduction in noise, I'm guessing this is estimated not "measured" ? 
Did you make a recording of the noisy vs the quiet version?

Going back to you strange oscillation, I noticed with two 5335's on top of eachother the fans generate some interesting audible effects and those vibrations are probably effecting the counter and whatever else is one the same surface.  With 10811 rigidly mounted on the counter's PC board, "stability" becomes an even more relative term.

I'm trying to say next time you take measurements, try to make sure the counter and the oscillator are not one the same vibrating surface (ie table).

[Vgkid]

I was using a db meter app on my phone, so it would not be perfect. The covers were off, and the phone was sitting on the chassis, but  I was holding it in place(it could still pick up vibrations). I still find it hard to believe that the old fan was so loud. I ran it with an external psu when I was holding it.
Fan: ADDA AD0824MX-A70GL-LF(80x80x25) the old papst was (80x80x38)
posted the old vs New mp3's.

[Vgkid]

I'm trying to say next time you take measurements, try to make sure the counter and the oscillator are not one the same vibrating surface (ie table).

I'm not even running the internal 10811 now, just the lpro.Though that is on the same shelfing unit, but not on the same shelf. The OCXO under test is actually sitting on a box(also full of ocxo's), that is on the floor(with another empty box covering it).