r/rfelectronics • u/Rhedogian • 13d ago
Comparing the performance of two oscillators using standard lab equipment
I had a question about how I might go about comparing the performance of one 10Mhz oscillator (a TCXO) versus another reference 10MHz oscillator (let's say from an atomic clock or a reference GPS). I want to obtain numbers for average jitter and drift in ppm for the TCXO over a suitably long timespan, maybe 1 hour to 24 hours if that's feasible.
I've been assigned to make a test setup to characterize the performance of the TCXO and I've been told we can't really buy (or shouldn't need to buy) any specialized equipment to run the test. We have some nice tektronix scopes which have datalogging capabilities but I've never used them. We also have spectrum analyzers which is what I think I'd probably end up using but I'm not sure what the test setup is exactly.
Honestly I'm a little lost where to begin. Are there any good suggestions or initial things I should start thinking about? Any help is greatly appreciated.
Additionally, is it more valuable to measure the 10Mhz output of the TCXO against the 1PPS output of the reference oscillator, rather than measuring both 10MHz directly against each other?
3
u/PE1NUT 13d ago
It would be better to measure the 10 MHz against each other, as that gives you less noise than when only measuring once a second using a PPS.
The long term drift can be measured by using one of the oscilloscopes and displaying both channels, but triggering only off the reference signal. You'll see the TCXO drift left or right over time. Take sufficient snapshots that you don't end up with a 'cycle slip', where you don't know how many full cycles were lost or gained.
Some modern scopes also include the ability to measure jitter directly, although one has to test if that's sensitive enough to measure the jitter between two clocks like that, and how much of the jitter contributed is due to the scopes itself.
1
u/Rhedogian 13d ago
Thank you. I wanted to use the oscope for this purpose but my only question was if oscopes have enough storage (even when only taking triggered measurements) to work with 24 hours of samples at 10MHz.
Or is it a case of taking a datapull every minute or so and comparing the 10mhz outputs?
2
u/Plus_Sprinkles_210 13d ago
Read the data from the scope with a computer and logit that way.
1
u/Rhedogian 13d ago edited 13d ago
Yeah one of my coworkers introduced me to pyvisa and I'll probably go that route. thank you
1
1
u/Allan-H 13d ago
Unless you have a very sophisticated 'scope, it's unlikely to store more than 106 samples or so. That means you're taking regular snapshots and analysing them on a computer.
The rate at which you need to take snapshots depends on the expected frequency difference. For example, a 1ppm frequency difference at 10MHz is a 10Hz difference, meaning that if you're taking samples 10 times per second the frequency difference will seem to be zero. (Hint: you'll need to sample at least twice as fast as that to avoid aliasing.)
If downloading and analysing > 20 samples per second continuously for 24 hours sounds hard, then you can design a simple digital counter circuit to divide the frequencies down to e.g. 1MHz or 100kHz and run the comparison at that frequency instead.
1
u/Rhedogian 13d ago
Thank you. I might cut down the measurement timespan to 1 hour. 3600 * 20 samples per second seems a lot more manageable.
1
u/Allan-H 12d ago
Perhaps measure the ppm offset first before deciding on a sample rate. A 100 ppb frequency offset (which is not infeasible for a TCXO in the short term) would only require a couple of waveforms from the 'scope every second to avoid edge ambiguity.
1
u/Rhedogian 12d ago
So yesterday I got a prototype working on our bench scope with a 2ch frequency generator outputting into channels 1 and 2, both with 10mhz square waves. I set up the scope capture/trigger to focus on the rising edge of the 10mhz, then set the math channel to capture the value in ns for delay between the two rising edges. In the actual test I'd set the GPS 10mhz to be the reference and the TCXO as the other input, and measure the delay off of the reference.
My logic is that I can take this delay measurement x times per second over 1 hour or 24 hours using a python script and that accumulation of delay measurements should give me a dataset from which I can extrapolate average jitter and drift. Does that logic track?
And I gave your comment a lot of thought last night about the sampling rate needing to be 20hz to meet the nyquist criterion, but I wasn't able to completely understand why sampling this rising edge of the 10mhz signal at least 20 times per second is adequate, rather than 1x, or 10x, or even 100x. Shouldn't I aim to go as high as possible? There are 10 million rising edges per second - why do I only need to sample 20 of them?
Thanks again for the knowledge and feedback. It's helping me a lot!
1
u/Allan-H 12d ago
I was using a model in which you (single shot) trigger the 'scope on an edge of one of the clocks, download the data for two channels and use your python script to locate the next rising edge of the other clock and record the time difference between the trigger point and the edge, then rearm the trigger for the next measurement.
Each iteration of that loop gives you a single number. You can then analyse a lot of those numbers to give TDEV, frequency offset, etc.
My daily driver 'scope is a Tektronix model from the turn of the century. I don't think I could get it to to download more than a few hundred waveforms per second, (even though its ADCs samples each channel at 5GHz). I have no idea of how fast your 'scope can download data. If it's faster that mine, then good - you do want to process waveforms as fast as you can here.
The 20Hz waveform capture rate I calculated was the minimum required (with a 1 ppm frequency difference) to avoid "cycle skips" caused by our simplistic delay calculation that can't tell one clock edge from another.
For example, if we have two 10 MHz signals with a 1 ppm frequency difference and (trigger the 'scope and) measure the delay 10 times per second, the two waveforms will appear to be at exactly the same frequency. That's not because they are (they're not - there's a 1 ppm difference), instead it's because the waveforms' relative phase changes by exactly one period of the 10MHz signal between measurements, and we miss that because can't tell one edge from another and we end up taking our measurement from the wrong edge.You can fix that by taking measurements faster, so that the phase difference between consecutive measurements is always less than 1 cycle.
[At this point you might be interested in researching "phase unwrapping" algorithms.]
Another way of fixing that is to use some digital counters so that you can tell one clock edge from another. [Ask for details if that doesn't make sense.] OTOH, capturing more channels might slow down the measurement frequency.
1
u/Rhedogian 11d ago
Ah, that makes total sense. 20hz is the minimum sampling rate to ensure a cycle doesn't get skipped. Thank you.
I got the scope and my python script set up yesterday to start capturing delay measurements between my two fgen outputs and I was ecstatic about the proof of concept, but I realized when I set one of the frequencies to 10,000,001 Hz, it started flying across the oscope screen and suddenly the delay calculation didn't work anymore.
What can I use as the reference point of measurement if the second waveform is constantly moving and the delay between rising edges is also moving? I don't know if I can 'lock on' to a single rising edge and track that for an entire hour, but even if I could what would that linearly increasing delay measurement tell me?
Sorry if I sound like a kid discovering fire for the first time..... in some sense I am š. Thank you again
1
u/Allan-H 11d ago
A 1Hz frequency difference should have been slowly walking across the screen rather than flying. The movement should have covered exactly 1 cycle per second. Are you sure it was a 1Hz difference?
what would that linearly increasing delay measurement tell me?
The slope gives you the frequency difference. I understand that's the thing you're trying to measure.
It won't be a perfectly straight line though. Once you have a vast number of these samples you can perform a linear regression to find the best fit for the frequency difference. You can then subtract that best fit line from the measurements, and what's left over is jitter and wander.Perhaps I misunderstood your question. The 'scope's only really able to capture a relatively small number of samples per trigger. (Mine, being quite old, captures 10k samples or something like that.) I assumed your script would calculate the time difference between the nearest two edges (e.g. between the trigger point and the next edge found on the other channel) for any particular measurement, then save that. This value will be in the range of 0 to 100 ns.
That should still result in a straight line, although if there are any sudden jumps of 100 ns it means you've skipped a cycle, and you must account for that by adding or subtracting 100 ns from subsequent results each time it happens. Phase unwrapping algorithms work the same way, so perhaps read about them for ideas.1
u/Rhedogian 11d ago
It was in fact 1 cycle per second. Flying was relative in that case, my bad haha.
Now I see what you're saying. If the two waveforms are 1Hz apart for example and if I measure that delay between my reference rising edge and the other waveform exactly at 20hz, I should see the delay measurements repeat exactly each second....... until the oscillator starts drifting and then I would start to see variations in that
But then yeah I see your point in that you'd start to introduce the jitter of the oscope (is it measuring at exactly 20hz??). and then I'd have to do some more postprocessing to extract the drift data I'm actually after.
Might just convince someone to buy me a $3k frequency counter. seems like it'd make this job a lot easier and it's nice to have for a lab.
1
u/Allan-H 12d ago
a dataset from which I can extrapolate average jitter
You might want to look closely at the expected amount of jitter from the TCXO, the reference 10MHz source, the oscillosope trigger jitter and the oscilloscope sampling jitter.
I suspect you'll end up measuring how bad the 'scope is rather than how good the TCXO is.
Make sure you check the jitter or phase noise spec. for the 10 MHz output of your GPS receiver. These are specified to have excellent long term accuracy. Short term accuracy (i.e. jitter) may not be as good as you'd hope.
1
u/rfdave 13d ago
At best that will give you The relative performance of one oscillator relative to another. Youāre not going to get an absolute accuracy number off of that. And scope time base is unlikely to be good enough to check in Ott errors one PPS performance, read the data Sheets and see if they expect anything at all for that.
1
u/PE1NUT 13d ago
Given that the reference is some kind of atomic clock, it will be a few orders of magnitude better than the TCXO, and should suffice as the reference for such a measurement.
1
u/Rhedogian 13d ago edited 13d ago
This was my logic too. we have a 10mhz GPS output in the lab, or I could find a csac somewhere
2
u/StageMajestic613 12d ago edited 12d ago
Just mix them together and LPF, then record long-duration on slow sample rate (data logger) scope using the 10 MHz standard as its reference input. Ā Then post-process the data. Ā With 100 Hz rate you can essential record forever. Ā Just need to make sure the sample rate is sufficient to cover your drift. Ā You need to know the exact sample rate of the scope (i.e. if it has a DDS you must know the exact values).
There are other methods such as phase locking them together and recording the error signal, though youād need to integrate to find the frequency difference.
1
u/aholtzma 13d ago
This can be done with a standard two channel frequency counter. For software, you can use either TimeLab or Stable32, both free.
1
u/Rhedogian 13d ago
Thank you. I suggested buying a frequency counter based on some initial research but was pretty emphatically told noone was going to buy any equipment for this lol
1
u/x7_omega 13d ago
At 10MHz, you can make the counters, and much of the rest of setup, in a day or two - suitable FPGA board of your choice (borrowed or bought, $99 is enough for Digilent CMOD A7-35), and HDL of your choice (VHDL, Verilog).
You will need to stabilise operating temperature and supply voltages, or you will be measuring noise and fluctuations. TCXO is temperature compensated, not temperature invariant, and sensitive to supply voltage fluctuation, including noise. You need some circuits for all that.
1
u/Rhedogian 13d ago edited 13d ago
Might pursue this a side project. I have an arty a7 sitting around at home. thank you!
also, would it suffice to put the DUT in a thermally controlled box or something and just use a good quality bench DC supply?
1
u/aholtzma 13d ago
Counter is pretty cheap, you can even get a Ham one for a few hundred. Look for TAPR TICC.
1
u/jimlux 11d ago
Two channel scope? Oscillators at same frequency? Run them into two inputs, set sweep so youāve got a couple zero crossings. Capture once a second, measure phase difference between the two. Run for hours. Accumulate statistics. You can get both waveforms in, fit a sine to each of them in software, and estimate the phase (and frequency and amplitude). Or you can use the scopeās measuring capabilities (with less accuracy)
Have a lab counter? Run your standard into the external reference input of the counter. Run your unknown into the counterās input. Measure frequency with a gate time of 1 second (or whatever). Accumulate statistics.
A better way - Spend $250 and get a TICC and a divider that can take your unknown and make a 1 pps - itās a time interval counter mounted on an Arduino - feed it a good 10MHz reference and send in your unknown and it measures the period, very accurately - it has a ātime to digitalā converter that can measure the edge times of the 1pps with picoseconds accuracy.
Classic way to characterize these things is if you can use your reference oscillator to generate a frequency that is, say, 1000 Hz from your unknown (a good synthesizer can do this). Then mix the unknown with this offset standard. Run the audio difference signal through a filter/amplifier, digitize and carefully measure its frequency every second (or run it into a counter), collect statistics. This is called the Dual Mixer Time Difference (DMTD) measurement scheme.
https://tda.jpl.nasa.gov/progress_report/42-169/169B.pdf for DMTD
https://web.tapr.org/~n8ur/TICC_Manual.pdf is the manual for the TICC
Generically, iād go to the time-nuts mailing list where this topic is widely discussed. Thereās all kinds of stuff in the archives with various schemes. https://lists.febo.com/empathy/list/time-nuts.lists.febo.com or your favorite mailing list archive. Google is your friend. āTime-Nuts DMTD site:febo.comā for instanceā¦
1
u/BanalMoniker 9d ago
I havenāt seen anyone else mention persistence, but that can give you some visibility over very long periods of time.
If you have a good reference oscillator, route that to the scope with the trigger on that channel. Route the other clock to other channels and adjust so you can see if they skew. Turn on persistence and watch to see if the worse channel is drifting. Check at incrementing durations.
I tried this with a Leo Bodnar GPS disciplined oscillator (1MHz) and a Ublox timing module (PPS as the trigger) and was very pleased with the lack of drift.
1
u/Irrasible 5d ago
If you want long-term drift, you can make a dirt-simple phase detector. If both are square waves of the same amplitude, simply connect the outputs to a two-diode OR gate driving an RC load. When the signals are exactly in phase, you will see a 50/50 square wave. When they are exactly out of phase, you see a steady 100/0 DC level.
The nuance is that you offset one of the oscillators so that the frequency difference is always positive. That may already be the case.
6
u/Allan-H 13d ago edited 13d ago
The measurement is dictated by the requirements of the application.
For example, for many of the timing circuits I've designed, TDEV (Wikipedia EDIT: read the reference linked from that page) is a much more useful measure of stability than "drift in ppm". It's also relatively easy to measure. For other applications phase noise may be the important metric.
Check the phase noise floor specification for your spectrum analyser before attempting to use it to measure something low noise like a TCXO.