Too good for Australia!
You could check the integrity of the counter by feeding the same rubidium signal into both the ref in and the counter input and see if it's bang on down to the last digit. You would expect it to be of course. You could also try this with different length coaxes to introduce a slight delay and see if that makes the least significant digit wobble.
You could check the integrity of the counter by feeding the same rubidium signal into both the ref in and the counter input and see if it's bang on down to the last digit.
You don't need a rubidium to do that, any oscillator will work.
And yes, of course it'll be spot on, even the cheapies.
You could check the integrity of the counter by feeding the same rubidium signal into both the ref in and the counter input and see if it's bang on down to the last digit. You would expect it to be of course. You could also try this with different length coaxes to introduce a slight delay and see if that makes the least significant digit wobble.
I wouldn't consider a function counter that can't even count its own reference "lower quality" or "out of spec", I'd consider it
defective crap. How hard is counting??
You don't need a rubidium to do that, any oscillator will work.
I'm not so sure. I would assume the frequency counter has its own high frequency oscillator which is supposed to be locked to the reference, but might lag ever so slightly to changes in the reference signal. If this is the case, it could be show the wrong value in least significant digit for an update here and there. The oscillator would probably have to be pretty crap for that to happen, but might be something to explore. You could even generate a 10 MHz signal which is deliberately modulated maybe by a modulator of 1 Hz and feed into both sides of the unit see if it ever shows anything but 10.000000000 MHz.
You don't need a rubidium to do that, any oscillator will work.
I'm not so sure. I would assume the frequency counter has its own high frequency oscillator which is supposed to be locked to the reference
No, that's not how counters work. The external reference becomes the direct clock for the counting logic. if you feed that same signal to the input, at worst you'll get +/1 count due to how the clocking is designed.
No, that's not how (most) counters work. The external reference becomes the direct clock for the counting logic. if you feed that same signal to the input, at worst you'll get +/1 count due to how the clocking is designed.
"Counters" (at least good ones) don't work that way, either. If they simply counted cycles per second, they'd always take a full second for each reading to get 1 Hz resolution. Some may measure the period, and report the reciprocal. They'll more often have some sort of interpolator, which allows them to measure fractions of cycles, with and use shorter gate times.
Phase noise and/or input comparator jitter and/or choice of gate time make it unlikely that you'll see an exact measure, even when self measuring the timebase.
No, that's not how (most) counters work. The external reference becomes the direct clock for the counting logic. if you feed that same signal to the input, at worst you'll get +/1 count due to how the clocking is designed.
"Counters" (at least good ones) don't work that way, either. If they simply counted cycles per second, they'd always take a full second for each reading to get 1 Hz resolution. Some may measure the period, and report the reciprocal. They'll more often have some sort of interpolator, which allows them to measure fractions of cycles, with and use shorter gate times.
Phase noise and/or input comparator jitter and/or choice of gate time make it unlikely that you'll see an exact measure, even when self measuring the timebase.
They don't count per second. They count per ref. clock cycle. Phase noise and jitter are random effects and wouldn't change the result. Delay also wouldn't count. Imagine hitting your hand on your table and counting the taps you hear.
You should do a comparison to the rubidium standard you got off ebay.
They don't count per second. They count per ref. clock cycle. Phase noise and jitter are random effects and wouldn't change the result.
No. The counter at hand has a 10 MHz ref clock. If it counted "per ref. clock cycle," any frequency less than 10 MHz would count as 0 or 1. Only the very old, or el cheapos, rely on simply counting during the gate time. Most modern "counters" might more properly called frequency meters.
While calibrating the time base in the video, the counter appeared to be using a 100 ms gate time, yet had a resolution (not accuracy) of .1 Hz. With a 10 MHz input, that's only 7 digits if simply counting (1,000,000 cycles), yet it produces a resolution of 9 digits. That's because it's doing interpolation of the signal, not simply counting. Interpolation commonly involves counts within the gate time, adjusted with a measurement of how long it takes for the next "count" to occur. And that's not measured using ref clock cycles - it's often a
ramp interpolator. Interpolation is also done at the start of the gate, since the signal cannot be assumed to be synchronous with the ref clock.
Interpolation depends on accurately locating a point on the waveform - something which is affected by both phase noise (movement of that point in the time domain) and input comparator jitter (measuring a sine wave will be less accurate than measuring a square wave, because of the need to accurately locate a point on the relatively shallow slope).
The technique of how the measurements are being done is irrelevant since it probably is linear to 10 or 100mHz. The timebase for all measurements is 10MHz. Remember, we are talking about Nitro's question that was if there will be any difference if you feed 10MHz in the input with a 10MHz source.
I just shot a quick video demoing this.
One in the queue already, so it'll be the video after that.
There's a good description of frequency meter measurement techniques
here
Dave, can you stop saying "I shot a quick video" please. Most of us have sussed that it is complete BS. You came this close (holds fingers up like Maxwell Smart, "missed me by this much") and then couldn't resist adding a bit more.
I know you are saying you shot a video quickly without your usual extensive preparation and research
but you say it like you're claiming it is a "short" video without the waffle.
No, when I say at the start it'll be a "quick" video, it means I have no intention of looking at the thing/subject in-depth, it doesn't necessarily mean it will be short, concise, or lack waffle.
Hook up the scopes 10mhz input to the rubidium, then hook up the counters 10mhz to the rubidium as well. Make sure to use equal length coaxes.
Take two coaxes with different lentgh now and hook up to both channels of the counter or two channels of the scope. You can now show accurate flight delay in coaxes. The counter can measure phase difference.
I use the technique tha Dave demonstrated to check my FE-5680A against my GPSDO, although observing the frequency difference takes a little longer - the last time I checked the two against each other it took more than an hour for the phase difference to go from 0o to 360o. That's about 3 parts in 1011.
Some perhaps interesting plots attached.
First shows stability of a Racal 1992 frequency counter time base with the Option 4E oscillator - highest stability oven offered by Racal at the time the counter was manufactured - compared against an HP 5065A Rubidium standard. If trying to set a standard counter time base oscillator to zero is difficult, setting a high stability oscillator is difficult squared or cubed, as you have to wait hours between adjustments to see the effect of the tweak.
Second shows a comparison between an HP 5065A Rb standard and an HP 5017A Cesium standard. Difference in frequency is 6 x 10
-13. (Not the same Rb standard used to generate the first plot.)
Third plot shows the Rb standard used in plot 1 compared with an HP Z3816A GPS disciplined oscillator. Difference is 1.1 x 10
-12 - GPS oscillator shows some spikes where the receiver lost signal for a brief period and hence the results may not be as reliable as the other two plots.
The plots all show quantization due to the finite resolution of the counter.
Data taken via the 1992's GPIB port, with a Prologix GPIB-USB adapter and collection software I wrote. Plotted with Origin, a scientific/engineering data analysis and plotting program.
Here's a Trimble Thunderbolt (GPSDO) vs. an Efratom FRS Rb. Measured using an HP 5370A Time Interval Counter. Ambient temperature is also plotted, you can see its effect. It changed about 250 ns in 2 days, a difference of about 1.5e-12 (about 35 millionths of a second per year).
Mmh, i never think that temperature is so important for a rubidium clock
Mmh, i never think that temperature is so important for a rubidium clock
Probably more important for Efratom FRS Rb!?