[time-nuts] Homebrew frequency counter, need help

[Magnus Danielson]

Hi Bob,

On 12/14/2014 06:00 PM, Bob Camp wrote:
> Hi
>
>> On Dec 14, 2014, at 11:36 AM, Magnus Danielson <magnus at rubidium.dyndns.org> wrote:
>>
>>
>>
>> On 12/12/2014 06:15 PM, Bob Camp wrote:
>>> Hi
>>>
>>>> On Dec 12, 2014, at 11:44 AM, Li Ang <lllaaa at gmail.com> wrote:
>>>>
>>>> Yes, you are right. 5650_5650 is sig=ref case. prs10_5650 is sig=prs10 and
>>>> ref=5650 case.
>>>
>>> In the “both same (5650 / 5650) case” your linear regression filtering is faking you out a bit. The SR620 counter has exactly this same issue. That’s probably for the same reason. It’s a fine test to see if you have various problems under control. It’s not a perfect way to estimate the number of digits you will get on a real measurement. Using two independent sources is a better way to do that.
>>>
>>> When you have two identical signals, the TDC noise is the main issue. All the edges are arriving in the same relation to each other (same timing). The linear regression is (obviously) good at suppressing the sort of noise the TDC has. With two independent signals the noise is more complex. The edges arrive at various times relative to each other. More things contribute to the total noise. The linear regression is having a harder time suppressing that sort of noise. In some cases (as you observed) the linear regression is actually making things worse.
>>>
>>> If Magnus was here, he would be tossing empty beer bottles at me and saying — see Bob, sqrt(N) doesn’t always work ….
>>
>> Indeed, except I would not be tossing empty beer bottles at you, I might jokingly attempt do, but never actually throw it. One has to realize that the quantization noise of the TIC may seem to process as if it where white phase noise, but it isn't random noise, it is a systematic noise and if you fool around with the systematics is may work for you or against you.
>>
>> I do consider to pass another bottle of good beer to Bob for good behavior. :)
>
> …. as long as we don’t start tossing kegs at each other, I consider myself lucky :)

Maybe empty, the beer will be so hard to tap if you throw full kegs, 
even if full kegs have better impact to get the point through. :)

>>
>>> The filtering process used does need to be adapted to the noise of the total system.
>>
>> It's one of the forgotten parameters, and I've even seen good Sam Stein stand up and say "we used to do this wrong" on the same point, you need to publish and consider the bandwidth of your processing, as it *will* affect the ADEV plot (but only MDEV and TDEV somewhat).
>>
>>>>
>>>> Since I really want to reduce the noise, what is the best test set you
>>>> suggest? All the frequency source I have: FE5650 Rb , PRS10 Rb , MV89a*2
>>>> OCXO,
>>>
>>> If the MV89’s are in good working condition, they are the best thing to compare.The have the best ADEV of the group you have available I would check them for output level and stability before I trusted them. There are a lot of defective parts on the market. People get some, sort them and sell the bad ones. The bad ones just keep getting re-sold again and again … My guess is that they were good parts at one time and they got damaged when pulled off boards. If you use them, keep them on power at all times. Any OCXO will do better if you run it that way.
>>
>> In order to test if systematics is messing badly with you, measure the ADEV of the oscillator as it is steered (and stabilized) to a number of different frequencies. For larger offsets to the counter reference, multiple beatings occurs within the regression interval. You want that number to be an even number of beats, or the beat count to be so large that the phase of the last beat does not care. Linear regression helps out, as it weighs out the outermost measures compared to the central one, making the beating at the beginning and end not care as much.
>>
>> These are *systematic* noise effects, and as you play around with systematics and processing, you might have the systematics works for or against you, but at the same time, the random noise you try to measure will suffer the processing filtering, and you need to recall that. If you balance these properly, you can make good and correct measurements, it's just that few do.
>>
>> Oh, and only use ADEV, MDEV and TDEV to estimate random noises, system noises as they show up there should be estimated separately and removed from the random noise estimates. They have *way* different behaviors.
>
> … and this is where it gets complicated. I would toss in the Hadamard deviation into that mix as well.

The Hadamard deviation is a great tool as it is not sensitive to linear 
frequency drift as Allan deviation is. This would help to remove the 
systematic effect, just as a quadratic curve-fitting of the raw-data and 
ADEV of the residual.

Modified Hadamard deviation (MHDEV) is a good replacement for MDEV, with 
the same properties for drift. Similarly will Time Hadarmard Deviation 
(THDEV) replace TDEV. However, for longer taus you want better 
processing, so therefore you want to consider the TOTAL set of 
deviations, such that confidence intervals is better.

> If I had to only use three, I would include it with modified ADEV (MDEV) and TDEV. All three are available in TimeLab with the click of a button. If you start getting lots of data (9,000 points per second) I would toss in a frequency domain (FFT) analysis as well. FFT on phase data is not (as far as I know) a feature of TimeLab.

FFT on phase-data is only available in TimeLab when doing phase-noise 
measurements. FFT is the way to analyse systematic noise rather than 
random noise where ADEV and friends is being used. You need to separate 
them, and the ADEV plot is not good for both.

There is a set of FFT based ADEV-style measures, which uses FFT, 
filtering of the various ADEV styles. There is a nice set of articles 
covering that approach, and actually the only style of ADEV processing 
that I haven't yet implemented, even if I have done most others.

> To start with, on all of these measures, you are looking for bumps and spikes. They are telling you that something is wrong. If you flip over to the phase plot in TimeLab, spikes and abrupt steps in it also are telling you the same sort of thing. Exactly what this or that bump is telling you may not be obvious at first. Posting plots to the list is a great way to get things sorted out.

Bumps, spikes and slopes... ADEV isn't the only tool one should be 
using, FFT might be much better for systematic noises.

In the end of the day, there is an overbeleife in ADEV both as a scale 
as well as a processing tool, to analyze deviations, without considering 
the separation of various systmeatic effect and systematic noises, while 
ADEV and friends is there to analyze random noise types, it does not 
handle systematics good. Seems like we have to kill ADEV as the 
universal measure. Ah well.

>> Cheers,
>> Magnus - considering what beer will be best to start the evening with
>
> That means it’s 5 o’clock somewhere in the world …hmmm …. choice of beers … It’s winter over here, so the dark stuff is slowly taking over the inventory. I have a nasty suspicion that it’s winter in Sweden as well :). Probably something with stout in it’s name ….

Hibernation Ale from Great Divide Brewing in Denver, Colorado, USA was 
the choice for the evening. Good beer for handling the winter.

Cheers,
Magnus