Help me understand allan deviation measurements. - Page 1
Forum section: electronics / beginners

author: Vgkid
author_rank: Super Contributor
timestamp: November 07, 2015, 06:14:03 am
content: For the basics I do understand that allan deviation is a measurement of a oscillators stability. Since my prologix gpib came today I figured that I should try it out. For this test I compared my 5335A's 10811 oscillator against one of my C-Mac CFP-04A oscillators. rather than getting the usual curved allan deviation plot, I got a rather straight line(some lumps) with a negative slope.I figured that this would assume that the oscillators were drifting the same amount, but to get a number into the E^-17's would be like measuring the noise floor of the counter.* it has been a few months since I last looked into time-nutting, kind of rusty in that regard.

author: Andreas
author_rank: Super Contributor
timestamp: November 07, 2015, 06:47:27 am
content: Hello,I guess that the resolution of your measurement is not high enough.(containing no noise).So perhaps all measurementvalues show 10.0 (MHz)With best regardsAndreas

author: VK5RC
author_rank: Unknown
timestamp: November 07, 2015, 07:28:11 am
content: I don't know enough about how the 5335 uses its ocxo to comment on your graph, one interesting experiment I did was to use one 10MHz source as both the reference and the test signal, as a way of looking at the phase noise and other errors of the primary instrument.

author: awallin
author_rank: Frequent Contributor
timestamp: November 07, 2015, 07:29:01 am
content: 12digit/s counters such as the 53230A or SR620 should have a noise floor of about 2...3 E -11 / tau(s).So ADEV(1s) = 2..3e-11 for example.You are doing something seriously wrong in your data collection or data processing if you get 1e-14 at 1s.Without posting more details about your setup it's impossible to say anything more.

author: Vgkid
author_rank: Super Contributor
timestamp: November 07, 2015, 07:58:19 am
content: I think I'm making progress, changed from a time interval measurement to frequency. Ran a short test, took quite a while(over an hour).

author: Andreas
author_rank: Super Contributor
timestamp: November 07, 2015, 08:06:38 am
content: Hello,I guess you used the wrong sample interval this time for allan deviation calculation.With best regardsAndreas

author: awallin
author_rank: Frequent Contributor
timestamp: November 07, 2015, 08:16:51 am
content: Quote from: Vgkid on November 07, 2015, 07:58:19 amThat looks more reasonable. You need to have the same gate time (1s) in both your counter and the software so that the statistics go right..For fun, also do the same measurement with the counter measuring its own reference. i.e. just a cable from the back REF-OUT to the CH1 input. That should give a rough lower bound on the noise floor.Extrapolating from the 12digit/s counter value of 2e-11 at 1s with your 9-10 digit counter you should see maybe 2e-10 to 2e-9 at 1s

author: edpalmer42
author_rank: Super Contributor
timestamp: November 07, 2015, 05:43:14 pm
content: An AlDev measurement is actually a three-way measurement. At any time value, the number on the graph is the combination of the counter, the reference, and the device under test. Unless they're all similar, the result is mainly due to the worst of the three.As awallin and VK5RC mentioned, measuring the counter's internal oscillator is a good way to check the counter's noise floor. The 5335A has a minimum resolution of 1 ns. Since counters typically do better than their spec, you should expect to see a 1 sec. AlDev value that's somewhat less than 1e-9. For larger time values, the graph will extend down and to the right on the graph i.e. 1e-10@10sec, 1e-11@100sec, etc. Eventually it will become a horizontal line, but you might have to wait a crazy amount of time for that. This test gives the best numbers you'll ever see with that counter and it coult be argued that it isn't a 'real world' number since you're measuring a source that's synchronized with the counter's timebase.A more 'real world' noise floor measurement is to take an external oscillator (e.g. your 10811) and connect it to Channel A via a T connector. Then go through a cable to Channel B. This guarantees that there will be a delay between Channel A and B. Now measure the delay and calculate the AlDev. Make sure that the cable doesn't move during the measurement and keep the temperature stable. The results might be similar to or maybe somewhat worse than the above measurements.If the results of either of the above tests are signicantly better than expected, you've got some setting wrong and you need to sort that out before you start making real measurements.Wherever possible, you should use time interval measurements rather than frequency. When you use frequency, you're averaging the measurment over whatever gate interval you select. This can obscure the information you're trying to measure. Time interval measurements measure a single event. Some counters can average time interval measurements - make sure you don't do that. Also, some counters measure time interval better than they measure frequency due to their internal architecture. My HP 5370B and Wavecrest DTS-2077 are like that.It's usually a good idea to divide the signals down to a lower frequency before making the measurements. This prevents the phase offset between the signals from wrapping around. These wraps must be removed before analysis. Timelab does it automatically, but it's still better to start with clean data. If it's not convenient to divide them down, just keep it in mind and try to adjust the frequencies to minimize phase wraps.Once you've figured out how to make reasonable measurements you can start to understand what they mean.Ed

author: Vgkid
author_rank: Super Contributor
timestamp: November 07, 2015, 11:31:30 pm
content: So I ran it again, with some rather interesting results. The ending graph resulted in a negative slope as before, but when the measurement was about 76%(last time I checked) the resulting graph looked like the usual allan deviation graph.first pic is the resulting graph, second is the frequency difference graph.In the third image I have zoomed in into the first large peak, I noticed that at random the frequency would go from being really stable, to suffereing a rather large frequency shift, then going back to being stable. hmm

author: edpalmer42
author_rank: Super Contributor
timestamp: November 07, 2015, 11:55:43 pm
content: Glitches are a fact of life. There may be a problem with your setup or it could just be courtesy of Mr. Murphy. Zoom in on the glitches and use F4 to delete them. Answer 'Yes' to the question about maintaining phase continuity. The AlDev graph isn't valid unless the phase and frequency graphs are clear of glitches, phase wraps, jumps, or any other anomaly.Ed

author: DimitriP
author_rank: Super Contributor
timestamp: November 07, 2015, 11:58:46 pm
content: In the frequency difference graph the flattenes of the line (except for the glitch ) looks suspiciously .....flat

author: edpalmer42
author_rank: Super Contributor
timestamp: November 08, 2015, 12:07:05 am
content: Quote from: DimitriP on November 07, 2015, 11:58:46 pmThat's okay. The glitch causes the graph to autoscale and the wiggles are too small to see. Once the glitch is removed, the wiggles will reappear.Ed

author: Vgkid
author_rank: Super Contributor
timestamp: November 08, 2015, 12:15:43 am
content: here is a zoomed in pic of the flat section of the frequency difference graph.

author: DimitriP
author_rank: Super Contributor
timestamp: November 08, 2015, 12:30:10 am
content: Are you still measuring the C-Mac CFP-04A ? I don't know anything about it so maybe being "unstable" only towards an "up" direction is normal.

author: Vgkid
author_rank: Super Contributor
timestamp: November 08, 2015, 01:13:05 am
content: As an interesting note i found out that if i push slightly down on the desk the frequency shifts several 10's of Hz.As an aside the tuning voltage(provided by a precision psu) is stable. Shouldnt affect the readings much(less than 40uv p-p).

author: Vgkid
author_rank: Super Contributor
timestamp: November 08, 2015, 06:33:12 am
content: I re ran it again, I will really have to learn to use this correctly, because I can't. The following screenshots were taken within several minutes of each other.

author: awallin
author_rank: Frequent Contributor
timestamp: November 08, 2015, 08:16:59 am
content: Quote from: Vgkid on November 08, 2015, 06:33:12 amADEV is only for quantifying noise processes.If you have systematic effects such as glitches or voltage/temperature steps etc. then the ADEV result will be more or less meaningless.You would need to look at the time-series of frequency measurements and either discard runs with glitches/steps, or perhaps manually delete the glitches.(ofcourse it's better to track down what is causing the glitches and fix that!)Playing around with 53230A and/or 53132 counters and paying reasonable attention to cables, grounding, powersupplies, etc. I have not seen glitches like that.

author: DimitriP
author_rank: Super Contributor
timestamp: November 08, 2015, 09:31:01 am
content: Since you mentioned flexing the desk causes a 10s Hz change, you should probably eliminate that first.If you have a wooden floor, chances are even walking around can make a differenceKinda hard to make suggestions sight unseen but either try different cables, or shorter cables, keep your cell phone tablet/computer monitor/laptop away from the measurment setup and turn off the ceiling fan etc etc.

author: HighVoltage
author_rank: Super Contributor
timestamp: November 08, 2015, 09:56:20 am
content: Can you post a picture of your setup?

author: Vgkid
author_rank: Super Contributor
timestamp: November 08, 2015, 04:36:36 pm
content: Mini update, fixed the desk issue. Another power cable was pushing up against the 5335A's cable. At least that removes the frequency shifts that were visible on the display. I then re ran it in period mode, and it was a clone of the first graph(the one that goes into the E^-17), untl i shut down everything.

author: CatalinaWOW
author_rank: Super Contributor
timestamp: November 08, 2015, 05:19:16 pm
content: Something to think about. If you are trying to evaluate the ultimate capability of an instrument, deleting glitches etc. may be a valid procedure. If you are trying to evaluate the performance of your installation as it is being used you can't just edit them out. They are reality.Same question goes for "fixing" glitches by using short cables, turning off ceiling fans etc. If the fix can't be used in normal operation of the equipment, any measurements you make with the fix in place are not relevant to the performance of your system. This may make for more difficult fixes, or lower real performance of the system, but that is the way it goes. So I encourage you to fix your glitches, but make sure that your fixes are applicable to your standard use of the system. Maybe it IS practical to turn the ceiling fan off whenever you are making a measurement.One of the best ways to make this point seem important is to think how you would respond to a manufacturer of one of your toys that you thought was underperforming who said that of course those specs only applied in a shielded room that was temperature and humidity controlled, operating from a battery supply.

author: DimitriP
author_rank: Super Contributor
timestamp: November 08, 2015, 07:47:54 pm
content: Quote from: Vgkid on November 08, 2015, 04:36:36 pmDid you save any of the measurement files? I'd be curious to run them here to see what I see.If they are too large to attach here, I'll PM you my email if you don't mind sharing.

author: Vgkid
author_rank: Super Contributor
timestamp: November 09, 2015, 08:13:28 pm
content: here are the frequency/phase difference measurements, (reading---measurement)I can still upload the images if you need them.I was thinking, should the counter be in talk, or listen mode. currently in talk.files to large,

author: Vgkid
author_rank: Super Contributor
timestamp: November 09, 2015, 08:21:29 pm
content: ^ I was only able to upload the frequency excel reading list, here is the current acquire window(gpib not connected)

author: DimitriP
author_rank: Super Contributor
timestamp: November 10, 2015, 12:07:51 am
content: I removed the big spurs and it looks "better"At least you can see there isA) some kind of disturbance in the force during the measuring period andB) some "settling" going on.If you start another session, leave them on for 24 hours before trying to collect data

author: Vgkid
author_rank: Super Contributor
timestamp: November 10, 2015, 12:43:22 am
content: 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.

author: Vgkid
author_rank: Super Contributor
timestamp: November 10, 2015, 06:00:07 am
content: 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.

author: edpalmer42
author_rank: Super Contributor
timestamp: November 10, 2015, 03:51:09 pm
content: 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 oscillatorsProblems like this are not unusual when dealing with Allan Deviation. After all, you're pushing into the parts-per-trillion range!EdP.S. Instead of posting Excel files, just save the data from Timelab as a .tim file. Then zip and post that.

author: Vgkid
author_rank: Super Contributor
timestamp: November 10, 2015, 09:20:19 pm
content: 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)

author: Vgkid
author_rank: Super Contributor
timestamp: November 11, 2015, 04:37:18 am
content: 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.pdfalso uploaded the zip files

author: edpalmer42
author_rank: Super Contributor
timestamp: November 11, 2015, 06:45:24 am
content: 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.

author: VK5RC
author_rank: Unknown
timestamp: November 11, 2015, 11:18:59 am
content: 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.pdfsee 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

author: edpalmer42
author_rank: Super Contributor
timestamp: November 11, 2015, 04:49:25 pm
content: Quote from: VK5RC on November 11, 2015, 11:18:59 amYes, 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

author: VK5RC
author_rank: Unknown
timestamp: November 11, 2015, 07:53:32 pm
content: Thanks, I don't know enough about the maths, I was wondering if that was the reason behind the anomalies in the data.

author: edpalmer42
author_rank: Super Contributor
timestamp: November 11, 2015, 08:30:39 pm
content: Quote from: VK5RC on November 11, 2015, 07:53:32 pmYou 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_varianceEd

author: awallin
author_rank: Frequent Contributor
timestamp: November 12, 2015, 06:01:32 am
content: Quote from: edpalmer42 on November 11, 2015, 08:30:39 pmThis 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_countersADEV 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...QuoteMy allantools python library has the algorithms in plain sight (unlike Stable32 or TimeLab...):https://github.com/aewallin/allantoolsit is fairly rigorously tested against Stable32 and gives identical results. patches welcome.Anders

author: edpalmer42
author_rank: Super Contributor
timestamp: November 12, 2015, 04:03:19 pm
content: Quote from: awallin on November 12, 2015, 06:01:32 am......Now you see why I try to avoid deadtime at all costs!Quote from: awallin on November 12, 2015, 06:01:32 amSo 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.comAnders, 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

author: awallin
author_rank: Frequent Contributor
timestamp: November 12, 2015, 06:04:26 pm
content: Quote from: edpalmer42 on November 12, 2015, 04:03:19 pmOops 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.pdfIf 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 andfor KE5FXAW

author: edpalmer42
author_rank: Super Contributor
timestamp: November 12, 2015, 07:00:24 pm
content: 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

author: Vgkid
author_rank: Super Contributor
timestamp: November 12, 2015, 11:01:09 pm
content: 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

author: edpalmer42
author_rank: Super Contributor
timestamp: November 13, 2015, 03:33:43 am
content: 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 youdon'twant 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

author: Vgkid
author_rank: Super Contributor
timestamp: November 13, 2015, 11:15:34 pm
content: 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.

author: Vgkid
author_rank: Super Contributor
timestamp: November 14, 2015, 03:55:18 am
content: 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.

author: edpalmer42
author_rank: Super Contributor
timestamp: November 14, 2015, 07:05:44 am
content: 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

author: Vgkid
author_rank: Super Contributor
timestamp: November 14, 2015, 07:34:11 am
content: 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).

author: edpalmer42
author_rank: Super Contributor
timestamp: November 14, 2015, 04:03:57 pm
content: 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

author: plesa
author_rank: Frequent Contributor
timestamp: November 14, 2015, 05:59:12 pm
content: 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.

author: Vgkid
author_rank: Super Contributor
timestamp: November 14, 2015, 08:08:41 pm
content: 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.

author: Vgkid
author_rank: Super Contributor
timestamp: November 15, 2015, 04:09:29 pm
content: I reran both ocxo's against the internal 10811A

author: edpalmer42
author_rank: Super Contributor
timestamp: November 15, 2015, 08:48:14 pm
content: 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.zipEd

author: KE5FX
author_rank: Super Contributor
timestamp: November 16, 2015, 04:30:41 am
content: Quote from: edpalmer42 on November 15, 2015, 08:48:14 pmThat'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:fg 300to set a 300-second averaging windowrto look at the residual (make surezmode 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. Hiteand 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.

author: edpalmer42
author_rank: Super Contributor
timestamp: November 16, 2015, 05:19:23 am
content: 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

author: KE5FX
author_rank: Super Contributor
timestamp: November 16, 2015, 05:30:02 am
content: Quote from: edpalmer42 on November 16, 2015, 05:19:23 amJust 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.QuoteNo 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.Quote from: awallin on November 12, 2015, 06:04:26 pmYou'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 anyoneelseincorporates that code into their own product, they cannot be held to the "viral" terms of the GPL.

author: Vgkid
author_rank: Super Contributor
timestamp: November 16, 2015, 11:38:34 pm
content: 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.

author: agronaught
author_rank: Contributor
timestamp: November 17, 2015, 09:23:13 am
content: 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.pdfMy 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.

author: KE5FX
author_rank: Super Contributor
timestamp: November 17, 2015, 03:40:54 pm
content: Quote from: agronaught on November 17, 2015, 09:23:13 amTI 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.

author: Vgkid
author_rank: Super Contributor
timestamp: November 17, 2015, 07:23:07 pm
content: 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

author: KE5FX
author_rank: Super Contributor
timestamp: November 17, 2015, 07:45:29 pm
content: Quote from: Vgkid on November 17, 2015, 07:23:07 pmLooks 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.

author: edpalmer42
author_rank: Super Contributor
timestamp: November 17, 2015, 08:44:20 pm
content: Although the numbers aren't the greatest, this graph is lookingmuchbetter. 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

author: Vgkid
author_rank: Super Contributor
timestamp: November 17, 2015, 09:40:40 pm
content: 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.

author: edpalmer42
author_rank: Super Contributor
timestamp: November 17, 2015, 09:54:48 pm
content: 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

author: Vgkid
author_rank: Super Contributor
timestamp: November 17, 2015, 10:22:24 pm
content: No SA, the lpro and the c-mac are powered from 2 different power supplies, both linear.

author: edpalmer42
author_rank: Super Contributor
timestamp: November 18, 2015, 03:28:36 am
content: 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

author: Vgkid
author_rank: Super Contributor
timestamp: November 18, 2015, 05:23:05 am
content: 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.

author: DimitriP
author_rank: Super Contributor
timestamp: November 18, 2015, 06:27:39 am
content: Quote from: edpalmer42 on November 18, 2015, 03:28:36 amIf room temperarure wasn't messing with my 100ppm frequency counter I wouldn't have gotten into this. Now, it's too late.

author: edpalmer42
author_rank: Super Contributor
timestamp: November 18, 2015, 04:48:29 pm
content: Quote from: DimitriP on November 18, 2015, 06:27:39 amBut you still haven't gotten away from the temperature problem. Almost every OCXO has a spec for accuracy vs. temperature. If you lookreallyclosely, you'll find that humidity and air pressure also affect precision oscillators.Ed

author: DimitriP
author_rank: Super Contributor
timestamp: November 18, 2015, 07:44:59 pm
content: Quote from: edpalmer42 on November 18, 2015, 04:48:29 pmLuckily, I can't look into itthatclosely yet.

author: Vgkid
author_rank: Super Contributor
timestamp: November 23, 2015, 03:06:19 am
content: 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.

author: edpalmer42
author_rank: Super Contributor
timestamp: November 23, 2015, 05:17:51 am
content: 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

author: Vgkid
author_rank: Super Contributor
timestamp: November 23, 2015, 10:55:16 pm
content: 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?

author: DimitriP
author_rank: Super Contributor
timestamp: November 23, 2015, 11:06:21 pm
content: Quote from: Vgkid on November 23, 2015, 10:55:16 pmNo, it is stll "single channel" PM me if you have somethign interestingAs 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 ...

author: Vgkid
author_rank: Super Contributor
timestamp: December 02, 2015, 10:40:21 pm
content: 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.

author: DimitriP
author_rank: Super Contributor
timestamp: December 03, 2015, 09:45:00 pm
content: 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).

author: Vgkid
author_rank: Super Contributor
timestamp: December 03, 2015, 11:04:56 pm
content: 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.

author: Vgkid
author_rank: Super Contributor
timestamp: December 03, 2015, 11:29:38 pm
content: Quote from: DimitriP on December 03, 2015, 09:45:00 pmI'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).

author: Vgkid
author_rank: Super Contributor
timestamp: December 04, 2015, 12:20:18 am
content: Cables came late yesterday,quick run.did a comparision with the last measurement, just a png. Showing the results of 2 weeks of aging.

author: DimitriP
author_rank: Super Contributor
timestamp: December 04, 2015, 02:08:10 am
content: At least it's consistent ...

author: Vgkid
author_rank: Super Contributor
timestamp: December 04, 2015, 02:25:39 am
content: I modified the newer plot, and removed some of the peaks, from Tau from about 23s-_-50s they actually plotted extremely close to each other. almost perfectly overlapping.

author: edpalmer42
author_rank: Super Contributor
timestamp: December 04, 2015, 03:52:16 am
content: Now you're into the black arts of ADev measurements. Add grounds, remove grounds, ground one end of the cable, ground the other end of the cable, try transformer coupling, try filters, amps, and attenuators, or pray to Dr. Allan to intercede on your behalf. Actually he's still alive so that wouldn't work.But it would probably be more productive to move on. Your results aren't bad, they're just imperfect. Welcome to the real world. The only way to understand Allan Deviation measurements is to do them on as many different oscillators as possible, both good ones and bad ones so that you can see and learn about some of the odd things that oscillators can do. As you test more oscillators you might find that your ripples go away. "Oh, that's what caused them! Doh!"If you become a full-fledged Time Nut, you'll be on a quest to find the best oscillator(s) you can to use as references to compare to a new device under test. You'll probably find that the best oscillator for short values of Tau (<~1000 sec.) is quartz. A really good quartz might be good up to 10K sec, but those are few and far between. For middle values of Tau (~1000 to 100K sec.) Rb will likely be best, but some models focus on low drift and don't care about ADev or phase noise. With quartz in particular, there's a lot of variation from unit to unit even for the same model. Two consecutive serial numbers might have drastically different performance. Throw in the fact that one came straight from the factory and the other came from a Chinese recycler and all bets are off.I've been surprised by the number of different areas that Time-Nuts stuff has led me into. Programming, phase locked loops, Arduinos, construction tricks, new test equipment, multi-GHz RF things that I've never played with, etc. One of my Rb standards let me insert an RF probe into the cavity and look at the RF signals at and around 6.834 GHz. I also measured the frequency response of the Cs tube in my Datum Cs frequency standard by varying the frequency around 9.192 GHz and measuring the 9 or 10 nanoamp output signal.Have fun!Ed

author: Vgkid
author_rank: Super Contributor
timestamp: December 10, 2015, 06:41:17 pm
content: I tested another oscillator, A C-mac stp2145A. Since these are used, they require the pins to be cleaned, sometimes tinned/detinned before a reliable connection can be made. I would often get a frequency reading of around 11.68Mhz initially, but it would drop as the ocxo warmed up, but not enough. I did not save the file after I powered it on for 4 hours, but there was no ripple in the graph, but the frequency stability was starting in the 1E-9's. I will see if I can find the initial one.I attached the 2 tim files as 1 zip file. Included are the original, and the modified version.

author: edpalmer42
author_rank: Super Contributor
timestamp: December 10, 2015, 08:33:17 pm
content: When an OCXO wakes up after a long sleep, it can take a month or more to work the kinks out. The rather ugly phase jumps in the original file could be exactly that. During this initial period you'll also see aging that's so fast it will affect your measurements. Many high-quality OCXOs state that aging can only be measured after 30, 60, even 90 days of continuous operation. Now add in the fact that it's a used unit from China that was probably picked up by a big crane, dropped 5 or 10 meters into a bin, had other big, heavy things dropped on it, maybe shipped overseas in an open bin, and maybe removed from the board by heating the board and banging it on a table. I'd be rather shaky too, if I endured that! I'm amazed that these things work at all, never mind often work quite well! Time will tell whether the crystal will ever settle down properly.Did you notice the last part of the data that gives a nice straight line? If you delete everything but that part, you'll find that the resulting ADev graph goes down into the low e-12 range! That's looking very nice! Both the frequency and phase plots are clean. The drift shown on the frequency page is -5e-9 which is decent. Hopefully, it will drop further as the unit runs. Maybe this oscillator survived the recycling process intact.11.68 MHz is completely wrong. An OCXO should never be more than a few KHz off-frequency even if it's stone cold. Use a scope to check the waveform and make sure that there isn't something terribly wrong. For example, if the output is CMOS/TTL and the counter is set to DC triggering at zero volts you'll get some very strange results. An internal fault in the oscillator that results in an extremely low output level could also cause gross errors because the counter is trying to dig through noise to find the signal. I've seen that once or twice.You mentioned that the frequency doesn't move far enough as the unit warms up. Does that unit have EFC capability? If so, you might need to hook it up to a pot to get the frequency correct. If the unit is old, it may have drifted far enough off frequency that it can't be corrected. I have cracked open a few oscillators to modify them to bring them back on-frequency. It's a lot of work unless it's a really, really good oscillator or just as a learning exercise. If an off-frequency oscillator has really good ADev, it's still useful as a reference to compare other oscillators to. The frequency error isn't important there. In fact, there are other ways to measure ADev thatrequirean off-frequency oscillator. Another interesting fact is that if the frequency starts high and drops as the unit warms up, it's probably an AT-cut crystal. If it starts low and rises, it's probably an SC-cut crystal. There are other crystal cuts, but those two are by far the most common.Here's a TimeLab hint for you. While you're in the middle of a data run, you can't edit the data. But you can save the .TIM file without affecting the data collection. Now you can reload the .TIM file without affecting the data collection. Now you can edit the saved data as much as you want. If you're doing a long data run, it's not a bad idea to save the .TIM file occasionally in case Murphy sticks his nose in where you don't want it!Ed

author: Vgkid
author_rank: Super Contributor
timestamp: December 11, 2015, 12:01:14 am
content: Should have clarified some stuff. For the 11.68MHz(I think it was 10.68,still far off) the frequency actually dropped as it warmed up, but not much. Unfortunately I scoped it and it did not show any strange abnormalities in the waveform, but even when using the counter in the scope it was still off. I had actually noticed this issue with the C-mac CFP0-4's, and the STP2145A's. The CFP0-4's are actually (*most likely) NOS. *I bought 50 of them, and at least 30 have sequential part numbers. Also the boxes that they came in were marked with C-Mac, and had evidence where the original shipping labels were taped on. The worst part is that some tape was placed over the shipping labels(so you can't read them), or even remove the tape.Back to the frequency issue.I noticed when I started testing the original box of CFP 's I noticed that they would often settle to 10.68M when I soldered wires to the ocxo. So I desoldered them, and grabbed another. I did this with 3 separate times, same issue. I grabbed another, all to the same effect. In frustration I desoldered the VCC/ground leads from the last ocxo under test. Grabbed a pair of spring clips and it worked. For fun I tried to “kill” one of the incorrect ocxo's. I cranked the voltage up to 30+V...and it worked, the ocxo that is. So I dialed the psu back to 12v, and it kept running. I marked that one, as to not use it. Skipping forward a few months. This time using the old CFP(the one used originally in this thread) I had the same issue as earlier, and switched to using spring clips. I eventually soldered it in so that it worked. Same thing for the new CFP that is currently running. A lot of fiddling was needed to get the correct output frequency. * The connections to VCC/Ground were solid.Onto the STP2145AWhen It came to powering up the ocxo the same issue had arisen, and I went through the same steps. This time I will document what it took to remedy this. When I first started using this for this current test. I cleaned the terminals with a cotton pad soaked in IPA. Soldered on he power connectors. Cleaned those off with IPA, and powered up the unit. Same thing, so I desoldered the wires(did not remove the excess solder), and attached some spring clips. Same large frequency offset. I grabbed my spare 2145A and powered it with spring clips, it worked. Perplexed I completely removed the solder(with braid) from the power pins. And cleaned those off, then resoldered the power wires. It worked this time. The strangest thing about this is that the ocxo drew a reasonable amount of current, it even dropped off as the ocxo warmed up. The voltage to the VCC pin was the same as the output of the psu, sometimes connection issues cause strange results.End novel.

author: edpalmer42
author_rank: Super Contributor
timestamp: December 11, 2015, 07:39:14 pm
content: I can't believe all the weird problems you've been having. Did all the members of the Murphy clan move into your neighborhood?? Soldered joints don't cause frequency errors! Clipleads don't give better connections! This is just nuts! You saw the sloppy wiring I did a few pages back and I still had better measurements than you're getting.I'm starting to wonder if there's something in your lab or nearby that's injecting noise into your circuitry. Maybe noise on the AC ground or RF noise being coupled into your circuits. Maybe a noisy switching power supply. Could be a cracked solder joint in a ground connection. Here are a few increasingly desperate ideas for you to try.I think your 5335A counter can do this. Take a signal that you can do a clean connection to. BNC to BNC - double-shielded if possible. NO CLIPLEADS!!!Measure theperiodon Channel A with statistics. Do the same on Channel B. Is the Standard Deviation similar on both channels? Yes, I know your counter agreed with your scope, but this is an easy test to do. You might want to do it to your scope as well, just to be sure. Your earlier test of the counter's noise floor was good, but I don't think it would pick up a bad ground on one channel.I think you said that you're collecting the Timelab data on a laptop. Shut it off, disconnect it from your counter and unplug the power brick from the wall. Redo the Standard Deviation test. Any change?Make sure that everything is plugged in to the same power source. Turn off everything you can that's not part of the measurement. This includes things like fluorescent or LED lights.You said that you don't have a spectrum analyzer. Any chance you can borrow one to look for noise sources? Could you borrow a different counter, preferably a different model?I made myself a poor-man's Faraday Cage out of a tin-plated steel biscuit tin that measured about 22x22x9 cm. I mounted both regular and isolated BNC connectors and added some holes with metal grommets for feeding through wires. The grommets prevent the sharp edge of the hole from cutting the wire insulation. Feedthrough capacitors would have been better, but I didn't have any handy. It works surprisingly well at attenuating RF. Be sure to sand off any paint or laquer that might prevent the top from making good contact with the body.This is really starting to bug me!!Annoyed Ed

author: edpalmer42
author_rank: Super Contributor
timestamp: December 11, 2015, 08:46:36 pm
content: Hey, all you lurkers out there, if you have any ideas that might help Vgkid, let's hear them!Ed

author: DimitriP
author_rank: Super Contributor
timestamp: December 11, 2015, 10:18:00 pm
content: Quote from: edpalmer42 on December 11, 2015, 08:46:36 pmHa...I was wondering when you were going to get "lonely"...I'd like to see a couple of pictures of the setup. Close up and overall.It does sound like Murphy lives next door....

author: edpalmer42
author_rank: Super Contributor
timestamp: December 11, 2015, 10:39:13 pm
content: Quote from: DimitriP on December 11, 2015, 10:18:00 pmI didn't really think an invitation was necessary. The more, the merrier! With over 2800 views on this thread there's got to be at least a few good ideas!Ed

author: DimitriP
author_rank: Super Contributor
timestamp: December 12, 2015, 01:12:39 am
content: QuoteChecking STD DEV of the counter's own timebase vs the oscillator in the "lab position" with "everything else" "normal" and then turned off (laptop, cell phone, tablet, soldering station,oscilloscope overhead lamp , whatever else is powered on , etc etc etc and then (especially if the numbers are close) taking the counter and oscillator in another area altogether and checking them again should reveal (hopefully) a dramatic difference in behavior

author: DimitriP
author_rank: Super Contributor
timestamp: December 12, 2015, 01:23:42 am
content: Quote from: edpalmer42 on December 11, 2015, 10:39:13 pmYou must have this thread confused with one about probes, soldering stations, soldering tips , which DMM or which oscilloscope to buy

author: Vgkid
author_rank: Super Contributor
timestamp: December 12, 2015, 07:59:53 pm
content: I will provide pictures later today.Ironically I actually ran one of the test(with the old ocxo) with nothing powered on in the room. The only things that were powered on were the psu's, the 5335A, and the laptop was running on battery(eco mode, screen closed,wifi off), same ripples in the graph. Though I initially plotted the stp over a short run(90min) only after it was powered on 2hr and no ripples were present. I did manage to find it.

author: Vgkid
author_rank: Super Contributor
timestamp: December 12, 2015, 08:06:11 pm
content: Here is the file.

author: DimitriP
author_rank: Super Contributor
timestamp: December 12, 2015, 08:16:52 pm
content: QuoteI thought I was following along, then I got lost.What's the "it" you managed to find? The source of the wiggles?What was causing them?

author: Vgkid
author_rank: Super Contributor
timestamp: December 12, 2015, 09:04:43 pm
content: 'It' was the timelab file that did not have any wiggled in it. Rather strange since the 28145asian had only been powered on 12 hours. Even though the sample run was 90min. The other runs had wiggles in them. I'm currently returning the test at the 90min sample run, to see if it still fails to produce those wiggles.

author: Vgkid
author_rank: Super Contributor
timestamp: December 14, 2015, 06:25:50 am
content: As requested here are the pics.A overview of the setup. The soldering iron is(has been) powered off for the duration of the test, along with everything else that is not essential on the bench.The first image shows what is in the plastic box. A STP2145A ocxo, running a (2) 10K(WW,%.05,??TC) resistor divider. The 2 thin leads are a twisted pair leading to my HP 3456A measuring the output of the Vref. It is rather stable over a day, though not perfect. The ocxo connects to a counter(50ohm) using a probe with alligator hooks.The second image shows a close up of the whole setup. it is not very pretty.The third image shows the CFP04 oscillator.* A cardbpard box actually covers the unit, and yes it is sitting on a box of ocxo's.A resistor voltage divider sets the output frequency. It is composed of (2) 11.8K(WW,.01%,TC5ppm), The output connects to the scope through a piece of RG58cable.A close up of the setup, the abundance of electrical tape is used to keep anything from shorting out. yes I did clean all terminals after applying the tape to remove any residue.

author: DimitriP
author_rank: Super Contributor
timestamp: December 14, 2015, 08:04:07 am
content: Since you are still in a "war of the wiggles", next time before testingA) I'd eliminate monitoring Vref so there are no long leads hanging off of it.B) I'd twist the twisted pairs much more tightly up to the point of connection so you only have an inch or so "straight"C) or I would give up on the twisted pair and use coax for power as wellD) I'd add a .01, 0.1 decoupling caps on the Vefc and Vin as wellE) Does the switch of the soldering iton switch the primary or the seconday off?.... I'd unplug it altogether.F) and I would unplug from the wall whatever other wall warts may be plugged in for good measure.Last thought just popped in before I hit enter...how about using one of the already tested ocxos as the reference for the counter? Hmmm I'll hit <Enter> now

author: edpalmer42
author_rank: Super Contributor
timestamp: December 14, 2015, 04:07:47 pm
content: I agree with Dimitri's comments, although you shouldn't have to use coax for the power feeds.Have you always had the EFC twisted pair attached? I strongly agree with Dimitri that it should be removed. The EFC input is high impedance and is very sensitive. Any noise on the EFC line will cause FM modulation on the oscillator's output. This is identical to jitter which equals bad ADev. Make this the first change.I'm assuming that the (scope?) probe is x1. If it was x10, the attenuation would be brutal when used on a 50 ohm input. I've got a couple of 100 MHz probes that have a resistance in the 100 - 300 ohm range when switched to x1. Trivial when used with a 1 Mohm scope input, but more significant when used with a 50 ohm counter. It would also mess up the 50 ohm load on the oscillator. I don't know what the frequency response of a x1 probe would be when used on a 50 ohm input. Move the probe from the counter to a 50 ohm terminated scope input and check the level that the counter will actually see.I like the way you isolated the units from drafts with the cardboard and plastic boxes. I also like the way you connected the coax onto the CFP04 oscillator. I was thinking about the best way to do that and came up with the method you used.If it looks like the scope probe might be causing problems, replace it with another piece of coax.Ed

author: DimitriP
author_rank: Super Contributor
timestamp: December 14, 2015, 09:09:54 pm
content: QuoteYou must mean X1 in the italicized sentence above? Was this a reading test ?

author: edpalmer42
author_rank: Super Contributor
timestamp: December 14, 2015, 09:18:14 pm
content: Quote from: DimitriP on December 14, 2015, 09:09:54 pmNo, I meant what I said. A x10 scope probe expects to be used with a 1 Mohm input so it has ~9 Mohm in series. If it was used with a 50 ohm input, the attenuation would be ~50 to 9M or x180K instead of x10. I think that qualifies as 'brutal'........or maybe 'lethal' is a better word.Ed

author: Vgkid
author_rank: Super Contributor
timestamp: December 15, 2015, 12:36:06 am
content: The probe is in the 1X setting. I was measuring the efc outputvoltage with 3456A. Over 2 days the std dev was around .1E-9, while the V-min/max was less than 60 counts. It is around 8.0v, with center voltqge around 4.2. I think i could do better.

author: edpalmer42
author_rank: Super Contributor
timestamp: December 15, 2015, 05:05:10 pm
content: Quote from: Vgkid on December 15, 2015, 12:36:06 amIt's very unusual to monitor the EFC voltage directly because you're almost guaranteed to degrade the oscillator's performance by doing so. The correct way is to disconnect the monitoring leads and then check the oscillator's output. If it looks like there's a problem with the EFC, make changes and then see if the performance of the output has improved.You're wasting time by trying to measure the EFC voltage directly.Ed

author: Vgkid
author_rank: Super Contributor
timestamp: December 15, 2015, 07:00:02 pm
content: The efc test were done initially. For the stp's A-dev test, the wires were unsoldered from the pins/removed. The cfp04 didnt have any.Last night I tested the cfp04, at least it is consistent.grn-1day(,maybes less,not noted),pink-4wk,blue-6wk.

author: edpalmer42
author_rank: Super Contributor
timestamp: December 16, 2015, 04:26:33 am
content: So, the three traces are all for the same oscillator? Green - 1 day ago, Pink - 4 weeks ago, Blue - 6 weeks ago? And that oscillator has been powered up almost continuously over that period?The green trace has higher noise levels than the others. That's why it's been pushed up. Notice that at the 1 second point, it's at ~9e-10 whereas the other traces are ~6e-10. The lack of ripples in that graph may or may not be significant. It could be that the noise is masking the ripples.The part of the green trace from 200 seconds up looks quite good. A flat section like that shows the noise floor of the measurement. There is no hint of aging like there is in the red and blue graphs. But again, it might be that the noise is masking the aging.I don't know what else to tell you. If you want to buy some more oscillators to compare with what you've got, go for it.Some good brands of quartz oscillators are Wenzel, HP, Symmetricom, Oscilloquartz, and MTI. There are others - that's just off the top of my head. Stick to 10 or 5 MHz unless you have a reason to get something different. Newer units have the benefit of better technology, but older ones have the benefit of time to stabilize. The longer an oscillator runs, the better it gets. An old, high quality oscillator can be a magical thing - or a paperweight.Make sure that you get ones that have EFC - some don't.Rubidium oscillators on ebay have gotten expensive in the last few years and it's hard to tell the difference in specs between things like the LPRO, FE-5650/5680, or X72 so there's not much point in stocking up on them.Ed

author: Vgkid
author_rank: Super Contributor
timestamp: December 16, 2015, 04:50:46 am
content: I ended up having to retype the last post. Green-about 1 day powered on, pink-4wk power on. Blue- 6wk powered on.I did not do any editing to the blue traces file, no frequency spurs.I will attach the timelab file in a few.

author: Vgkid
author_rank: Super Contributor
timestamp: December 16, 2015, 06:03:35 am
content: Here is the TL file comparing the cfp04 to the lpro-101

author: Vgkid
author_rank: Super Contributor
timestamp: December 18, 2015, 01:40:36 am
content: Ran the lpro(ch1,50-ohm) against the HP10811. No oscillation occur, but it is rather different. Unfortunately the at the bottom of the graph is flat, but lumpy.Pics /files later.

author: Vgkid
author_rank: Super Contributor
timestamp: December 18, 2015, 07:20:30 am
content: Abra,Kadabra,Alakazam.The oscillation is still there. Instead of starting at the 20's=30's mark. It starts in the 400s mark.

author: DimitriP
author_rank: Super Contributor
timestamp: December 18, 2015, 06:53:21 pm
content: It is interesting in a magical, cant-get-rid-of-the-wiggles kinda way.I'm running out of assumptions

author: Vgkid
author_rank: Super Contributor
timestamp: December 19, 2015, 06:55:11 pm
content: I'm enentually going to get the other 5335A online. need to fix my car first.I assumed that the wiggles would be gone if I just ran the 10811 vs LPRO. Since the internal oscillator of the counter should be rather well shielded. Next I will put the stp/cfp in a AL box,, with coax running to the counter. Heck I my try your suggestion, of the twisted pair power connections(No coax unless I get desperate).Else

author: DimitriP
author_rank: Super Contributor
timestamp: December 19, 2015, 07:35:20 pm
content: QuoteTrustNo1Altough it's "shielded" by the tank that is the 5335, there are a couple of things I dont like.For one, it's right there in the air intake stream.Depending on the room temperature that must be causing the oven to come on "every so often".Even some bubble wrap around it so the air doesn't hit it directly would be an improvement.The second thing that I don't like very much is that whatever vibration the fan produces gets transfered to the oscillator since it's bolted directly on the PCB. The 10811 has "pretty good specs" concerning vibration but there is also a reason why HP produced the double oven , shock mounted version !

author: Vgkid
author_rank: Super Contributor
timestamp: December 27, 2015, 01:44:27 am
content: While working on the 6114A i noticed that the led grounded/ungrounded light on my Phillips surge protector either stays on,off, or as currently alternating between those states.Ordered some parts for my original 5335, so i will soon have another counter to try.

author: DimitriP
author_rank: Super Contributor
timestamp: December 27, 2015, 03:53:31 am
content: Sounds like it's time to replace the surge protector too...

author: Vgkid
author_rank: Super Contributor
timestamp: December 27, 2015, 09:16:12 am
content: It has gone back to showing grounded, and staying that way...I think an exorcism will be needed as well.

author: Vgkid
author_rank: Super Contributor
timestamp: December 31, 2015, 04:22:01 pm
content: Mini update:Waiting on parts from mouser so i can fix the counter. I forgot about the relay socket last order.10.86 MHz issue, made a discovery.So the STP2145A and the CFP04 are wired in parallel to the same psu which is set to provide a luttle more current then is needed, under steady state conditions.On Tuesday we lost power after both ocxo's warmed up the psu switched from cc to cv mode. I checked the 2145A last night, no major issues. Checked the CFP04 that 10.86 MHz appeared again.powered off the psu, set the trip current higher(enough so that cc mode wouldnt engage) and powered on the psu.All is well.

author: Vgkid
author_rank: Super Contributor
timestamp: January 22, 2016, 07:28:52 am
content: Mini update V2:Rather than trying to spend time and hunt down the wiggles in the graph. A plot I ran last night(just posting Al Dev,FreqDev) showed some massive jumps in the graph. So these jumps have seemed to almost be present in every plot I have made once it has started getting cold,even noticed some starting off. In a previous post I mentioned that the surge protectors ground light would often flicker on/off, or just stay off. So I also noticed that(posted about this earlier) walking across the room/ sometimes moving the gear would majorly throw off the readings. So I swapped the power cords with others(more solid fit, at least with the counter), of both the counter, and the psu(powering the oscillators). Same effect.Next: I separated the 2 surge protectors, placing the counter/psu on the newer/better one...Same problem.Next: ran each surge protector from a different outlet...same.Next: ran the surge protector without a ground(used one of those 3prong to 2-prong adapters) ...same.Next: hooked up the surge protector up to the wall(no adapter), wiggled the plug, no movement. pushed on the plug, no weird changes.Next: I tried to replicate the actions of the anomalies, pushed on the desk. Sometimes this would get a change, but not always. Moved to the psu/ counter, same thing. walked across the room, sometimes a issue. Noticed that it only did anything near the center of the room. singled it out to a few square feet in the middle of the room.The only thing I can think is happening is that there is a bad connection in the chandelier in the room below mine.

author: DimitriP
author_rank: Super Contributor
timestamp: January 22, 2016, 09:11:50 am
content: Do you have a shortwave radio to take listen up, down and around 10 MHz to get an idea of what sort of "loose RF' you have there ?

author: edpalmer42
author_rank: Super Contributor
timestamp: January 22, 2016, 04:05:55 pm
content: Do you have a UPS? Try disconnecting everything from the wall and run it off of the UPS. Noisy power or ground could inject noise into your setup.Isn't it fun to play in the parts-per-trillion range?

author: DimitriP
author_rank: Super Contributor
timestamp: January 22, 2016, 07:38:16 pm
content: QuoteA long time ago, as long as the FM receiver's AFC could track it , an oscillator was deemed "stable enough".So it is a little bit of a change !

author: Vgkid
author_rank: Super Contributor
timestamp: January 22, 2016, 08:56:08 pm
content: An interesting aside to the large jumps is that i was using my 3456a to measure the output of my precision Lambda psu and couldnt notice any jumps. I was even using 1nplc and no filter.@ DimitriP: i believe I still have a SW radio. I wws probing a upset psu(for ripple issues, giving unstable readings) an could notice the 10mhz signal(not freq measureable) on the ripple.@ edpalmer: Last week I was browsing CL for one.

author: Vgkid
author_rank: Super Contributor
timestamp: February 08, 2016, 07:15:20 pm
content: I further went through and removed any switching psu's except the laptops(running it iff a battery for 2hr didn't help, didn't save that one). Also removed any other sources of 10mhz oscillators. Removed the one from the 5335A(both the ocxo, and the xo*) As evident in the graph, the oscillations are still there. Even used a twisted pair of power cables, and a different psu as well.Then ran the ocxo into frequency input, and into chA(effectively measuring itself) No oscillations in the graph.

author: DimitriP
author_rank: Super Contributor
timestamp: February 09, 2016, 08:49:13 am
content: One or more of our assumptions is completely wrong. Now we need to figure out which...

author: Vgkid
author_rank: Super Contributor
timestamp: February 10, 2016, 04:25:44 am
content: For those who are curious, I'm uploading the results of the test with only the ocxo's/RB powered up. * On the lpro box, a bunch of the outputs are terminated. The laptop is running on battery, hence the short run time.

author: edpalmer42
author_rank: Super Contributor
timestamp: February 10, 2016, 04:47:09 am
content: And when I zoom in on your data, here's what I see on the phase data screen. A low frequency beat signal that takes about 40 seconds to complete a cycle i.e. approx 0.025 Hz. It didn't show up in your noise floor tests, but every time you try to compare two oscillators, it's there. Until you can find the source and beat it to death, those oscillations will appear in all your data.Have you tried using a different counter?

author: Vgkid
author_rank: Super Contributor
timestamp: February 10, 2016, 05:02:25 am
content: I can use another 5335 in about a week. It might get interesting in a few months, I will move the whole setup to the garage.* I will try running the lpro against itself in a few days.**Reminding myself to pick up some sma terminators.**

author: edpalmer42
author_rank: Super Contributor
timestamp: February 10, 2016, 05:37:11 am
content: Can anyone else duplicate Vgkid's tests with a 5335? Is there something weird about that model that's causing this?Vgkid, maybe check your 5335 over carefully. Look for cracked ground traces, bad solder joints, loose screws, etc. One of these sort of things might not show up in a noise floor test because everything is local or internal but could mess up a real measurement where you're looking at external devices.

author: Vgkid
author_rank: Super Contributor
timestamp: March 14, 2016, 05:48:27 am
content: Remember that power issue I noticed when it came to the grounded light on the surge protector.Well I was checking my ocxo's. Touched the counter with 1 hand, and the metal bench with the other and noticed a tingling feeling.Grabbed the fluke 87, and measured 60v, did that with my other pieces of gear, the same thing. Though a few reported about 11v.I will troubleshoot further tomorrow.

author: DimitriP
author_rank: Super Contributor
timestamp: March 15, 2016, 03:02:53 am
content: QuoteBetter than strange voices coming from the TV !

author: Vgkid
author_rank: Super Contributor
timestamp: March 15, 2016, 05:01:09 am
content: ^^^Better than hearing a voice that answers you,when you are alone..(my 1 ghost experience)ended up unplugging everything from the bench. As i plugged in each instrument, i measured the voltage from the chassis to the bench everything reads 60v

author: Vgkid
author_rank: Super Contributor
timestamp: March 16, 2016, 05:26:20 am
content: Moved the bench so it is not against the baseboard heater. Now everything is at 15vrms:/

author: DimitriP
author_rank: Super Contributor
timestamp: March 16, 2016, 06:24:56 am
content: Common ground is not that common sometimes...Was this heater in use when you were taking measurements ?

author: Vgkid
author_rank: Super Contributor
timestamp: March 16, 2016, 11:58:23 am
content: Over the whole time, no.

author: Vgkid
author_rank: Super Contributor
timestamp: March 16, 2016, 08:56:27 pm
content: Progress is made...Not into the upper 7x10^-12, like the last one I ran, a few days ago(had oscillations in it).

author: Vgkid
author_rank: Super Contributor
timestamp: March 18, 2016, 08:00:53 pm
content: Oscillations are still present, atleast they are reduced, as compared to previous measurements. Still trying to figure out why all of the gear is floating at 15v, beats 60v...Attached the TL file, the finished one was run over 2 days, 24hr. The other was run over 6 hours last nght.On the 24 hour run, what would make the graph look like this, as opposed to the usual AlDev graph?

author: edpalmer42
author_rank: Super Contributor
timestamp: March 19, 2016, 03:09:29 am
content: What is it about the 24 hour graph that looks wrong to you?Ed

author: Vgkid
author_rank: Super Contributor
timestamp: March 19, 2016, 09:30:00 pm
content: So if i allowed the counter to count for 1more hour(allowing my to remove the 3 spurious freq jumps)/ drew a line following the curve. Would this allow me to approximate the 24 hour drift rate?

author: edpalmer42
author_rank: Super Contributor
timestamp: March 19, 2016, 09:59:05 pm
content: Quote from: Vgkid on March 19, 2016, 09:30:00 pmYou need to run longer than 24 hours to get a 24 hour Allan Deviation value. In Timelab, if you use Ctrl-E to turn on the error bars for the Allan Deviation screen, you'll see that the end of the graph has really wide error limits. So you might have to run your test for 2 or 3 days before the one day value is reasonably well defined.Ed

author: Vgkid
author_rank: Super Contributor
timestamp: March 19, 2016, 11:26:48 pm
content: Ok, might be a while.Equipment voltages are down to around 1v wrt the bench.

author: Vgkid
author_rank: Super Contributor
timestamp: April 08, 2016, 06:02:03 am
content: So I ran the CFP04, and the STP2145A for 48 hours. The CFP04 had only ben powered on almost 1 month, the STp2145A has been powered on for several months.

author: edpalmer42
author_rank: Super Contributor
timestamp: April 09, 2016, 04:51:44 am
content: The cfp04 graph looks okay. If you had run the test longer, the lowest part at 1000 - 2000 sec. wouldn't have changed, but the hook on the right hand would have disappeared, the graph would have risen smoothly from the lowest readings, and the 1 day results would have been 1 or 2 e-10. A reasonable result that shows some low tau limitations in your measurement system.The 2145A graph is somewhat suspicious. The AlDev goes out to almost 80K seconds and it doesn't show any aging yet. The phase plot shows a frequency change at ~121K seconds, but that hasn't yet appeared in the AlDev results. If I remove the data after the frequency change, things get even more suspicious. Are these measurements time interval measurements versus the LPRO or frequency measurements?Ed

author: Vgkid
author_rank: Super Contributor
timestamp: April 09, 2016, 08:27:32 am
content: Frequency measurement, I can not seem to get the TI mode to give me anything other than negatively sloped line. I do want to see if i can arm the counter from a 1pps signal.

author: edpalmer42
author_rank: Super Contributor
timestamp: April 09, 2016, 04:36:08 pm
content: Quote from: Vgkid on April 09, 2016, 08:27:32 amThat's suspicious. If you measure the time interval between two oscillators at slightly different frequencies, the result should gradually drift through all values until it reaches an interval equal to the period of the frequency involved and then wrap back to zero. The numbers could increase or decrease depending on which oscillator is faster or slower. On a graph it will look like a sawtooth. e.g. for two 10 MHz signals, the result should go from 0 to 100 ns. If the frequency difference between the sources is too high, you won't see the sawtooth, it will just look like random numbers in the same range. If your counter can't do that, it makes me think there's something wrong with your counter which casts suspicion on all your results.I know that earlier in this thread, KE5FX recommended frequency measurement. I've always preferred time interval because some counters workmuchbetter in that mode. My HP 5370B and Wavecrest DTS-2077 are like that. Also, with time interval, you can be sure that you're only measuring one interval and aren't doing any averaging which will artificially improve your results. I think that's what's happening in your recent results.Ideally, the start signal would be 1 PPS and the stop signal would be whatever the DUT (Device Under Test) provided. Configure the counter to use its internal reference. It should be able to take the reading and reset before the next pulse so deadtime shouldn't be an issue.I'd recommend that you take another look at time interval mode. Timelab understands phase wraps and does a pretty good job of unwrapping them.Ed

author: edpalmer42
author_rank: Super Contributor
timestamp: April 20, 2016, 11:06:32 pm
content: Hi Vgkid,I just made an interesting discovery that I wanted to pass on to you.I always wondered why the slope on your graphs was so shallow. All my graphs start out at the counter's resolution and drop 1 decade for every decade of time. Yours are more like one decade drop in two decades of time. I recently decided to measure frequency and use it for AlDev calculations. I don't think I've ever done that. Guess what? Same shallow slope.The problem is that since it takes so long for the shallow slope to get down to the e-12 area, the OCXO has already passed its lowest value and is starting back up due to aging. It also seems like it has a relatively high noise floor so that further distorts the measurements. I think that's why your results haven't been particularly good.This doesn't explain your oscillations, but it's still useful info to have.Ed

author: Vgkid
author_rank: Super Contributor
timestamp: May 06, 2016, 07:48:14 pm
content: @ Ed, thanks for that piece of information. I have always wondered about the shallowness of my slopes, when looking at others al-dev graphs.

author: awallin
author_rank: Frequent Contributor
timestamp: May 07, 2016, 06:30:54 am
content: Quote from: edpalmer42 on April 20, 2016, 11:06:32 pmfwiw in frequency counter mode I made noise-floor measurements of a 53230a counter:http://www.anderswallin.net/wp-content/uploads/2015/06/RCON_vs_CONT.pngby default it uses a CONT mode which has a lot of internal averaging and a 1/sqrt(tau) slope. calculating ADEVs from this data is questionable.The undocumented RCON mode looks more like a time-interval measurement noise floor and the slope is 1/tau.not sure if the counting mode is adjustable on other counters. on new computerized counters it should be possible.

author: Vgkid
author_rank: Super Contributor
timestamp: July 25, 2016, 07:01:12 pm
content: Mini update: no fix on the allen deviation graph. The main cfpo4 has still been kept under power, though it was powered off for about a week. Previous to being de-powered it has been behaving well. Though it will be depowered(along with everything else) for a week.Regarding the ocxo wrong frequency turn on bug, I tested 14 cfp04's, and they did not display this glitch.In related news, I managed to break one of the ocxo's. Teardown if you want it.

author: edpalmer42
author_rank: Super Contributor
timestamp: July 25, 2016, 09:01:38 pm
content: A while ago I was making some measurements and direct cable connections weren't appropriate so I used a scope probe for one channel of the TIC. The results were trash - I had lots of wiggles. I was going to investigate it more before posting it, but never got around to it.Are you still using a probe on one channel?Ed

author: Vgkid
author_rank: Super Contributor
timestamp: July 25, 2016, 09:27:51 pm
content: Direct connection for frequency. I do need to pick up come bnc cables to do some bulk testing(much much later).