[time-nuts] Question about frequency counter testing

Oleg Skydan olegskydan at gmail.com
Sat May 12 14:38:32 EDT 2018


From: "Magnus Danielson" <magnus at rubidium.dyndns.org>
> ADEV assumes brick-wall filtering up to the Nyquist frequency as result
> of the sample-rate. When you filter the data as you do a Linear
> Regression / Least Square estimation, the actual bandwidth will be much
> less, so the ADEV measures will be biased for lower taus, but for higher
> taus less of the kernel of the ADEV will be affected by the filter and
> thus the bias will reduce.

Thanks for clarification. Bob already pointed me to problem and after some 
reading *DEV theme seems to be clearer.

>> Does the ADEV plots I got looks reasonable for the used "mid range"
>> OCXOs (see the second plot for the long run test)?
> You probably want to find the source of the wavy response as the orange
> and red trace.

I have already found the problem. It is HW problem related to poor isolation 
between reference OCXO signal and counter input signal clock line (it is 
also possible there are some grounding or power supply decoupling problems - 
the HW is made in "ugly construction" style). When the input clock frequency 
is very close (0.3..0.4Hz difference) to the OCXO subharmonic this problem 
become visible (it is not FW problem discussed before, cause counter 
reference is not a harmonic of the OCXO anymore). It looks like some 
commercial counters suffers from that problem too. After I connected OCXO 
and input feed lines with short pieces of the coax this effect greatly 
decreased, but not disappeared. The "large N" plots were measured with the 
input signal 1.4Hz (0.3ppm) higher then 1/2 subharmonic  of the OCXO 
frequency, with such frequency difference that problem completely 
disappears. I will check for this problem again when I will move the HW to 
the normal PCB.

> If fact, you can do a Omega-style counter you can use for PDEV, you just
> need to use the right approach to be able to decimate the data. Oh,
> there's a draft paper on that:
> https://arxiv.org/abs/1604.01004

Thanks for the document. It needs some time to study and maybe I will add 
the features to the counter to calculate correct PDEV.

>> If ADEV is needed, the averaging
>> interval can be reduced and several measurements (more then eight) can
>> be combined into one point (creating the new weighting function which
>> resembles the usual Pi one, as shown in the [1] p.54), it should be
>> possible to calculate usual ADEV using such data. As far as I
>> understand, the filter which is formed by the resulting weighting
>> function will have wider bandwidth, so the impact on ADEV will be
>> smaller and it can be computed correctly. Am I missing something?
> Well, you can reduce averaging interval to 1 and then you compute the
> ADEV, but it does not behave as the MDEV any longer.

With no averaging it will be a simple reciprocal counter with time 
resolution of only 2.5ns. The idea was to use trapezoidal weighting, so the 
counter will become somewhere "between" Pi and Delta counters. When the 
upper base of the weighting function trapezium is 0 length (triangular 
weighting) it is usual Delta counter, if it is infinitely long the result 
should converge to usual Pi counter. Prof. Rubiola claims if the ratio of 
upper to lower base is more than 8/9 the ADEV plots made from such data 
should be sufficiently close to usual ADEV. Of cause the gain from the 
averaging will be at least 3 times less than from the usual Delta averaging.

Maybe I need to find or make "not so good" signal source and measure its 
ADEV using above method and compare with the traditional. It should be 
interesting experiment.

> What you can do is that you can calculate MDEV or PDEV, and then apply
> the suitable bias function to convert the level to that of ADEV.

That can be done if the statistics is calculated inside the counter, but it 
will not make the exported data suitable for post processing with the 
TimeLab or other software that is not aware of what is going on inside the 

> Yes, they give relatively close values of deviation, where PDEV goes
> somewhat lower, indicating that there is a slight advantage of the LR/LS
> frequency estimation measure over that of the Delta counter, as given by
> it's MDEV.

Here is another question - how to correctly calculate averaging length in 
Delta counter? I have 5e6 timestamps in one second, so Pi and Omega counters 
process 5e6 samples totally and one measurement have also 5e6 samples, but 
the Delta one processes 10e6 totally with each of the averaged measurement 
having 5e6 samples. Delta counter actually used two times more data. What 
should be equal when comparing different counter types - the number of 
samples in one measurement (gating time) or the total number of samples 


More information about the time-nuts mailing list