[time-nuts] Question about frequency counter testing

[Oleg Skydan]

Hi Magnus!

From: "Magnus Danielson" <magnus at rubidium.dyndns.org>
>> The leftmost tau values are skipped and they "stay" inside the counter.
>> If I setup counter to generate lets say 1s stamps (ADEV starts at 1s) it
>> will generate internally 1/8sec averaged measurements, but export
>> combined data for 1s stamps. The result will be strictly speaking
>> different, but the difference should be insignificant.
>
> What is your motivation for doing this?

My counter can operate in usual Pi mode - I got 2.5ns resolution. I am 
primary interested in high frequency signals (not one shoot events), and HW 
is able to collect and process some millions of timestamps continuously. So 
in Delta or Omega mode I can improve the resolution in theory down to 
several ps (for 1s measurement interval). In reality the limit will be 
somewhat higher.

So I can compute the classical ADEV (using Pi mode) with a lot of counter 
noise at low tau (it will probably not be very useful due to the counter 
noise dominance in the leftmost part of ADEV plot), or MDEV (using Delta 
mode) with the counter noise much lower.

I would like to try to use the excessive data I have to increase counter 
resolution in a manner that ADEV calculation with such preprocessing is 
still possible with acceptable accuracy. After Bob's explanations and some 
additional reading I was almost sure it is not possible (and it is so in 
general case), but then I saw the presentation 
http://www.rubiola.org/pdf-slides/2012T-IFCS-Counters.pdf (E. Rubiola, High 
resolution time and frequency counters, updated version) and saw inferences 
on p.54. They looks reasonable and it is just what I wanted to do.

> The mistake is easy to make. Back in the days, it was given that you
> should always give the system bandwidth alongside a ADEV plot, a
> practice that later got lost. Many people does not know what bandwidth
> they have, and the effect it has on the plot. I've even heard
> distinguished and knowledgeable person in the field admit of doing it
> incorrect.

That makes sense.

We can view at the problem in the frequency domain. We have a DUT, reference 
and instrument (counter) noise. In most cases we are interested in 
suppressing instrument and reference noise and leaving the DUT noise. The 
reference and DUT has more or less the same nature of noise, so it should 
not be possible to filter out reference noise without affecting DUT noise 
(with the simple HW). The counter noise (in my case) will look like white 
noise (at least the noise associated with the absence of the HW 
interpolator). When we process timestamps by Omega or Delta data processing 
we apply filter, so the correctness of the resulting data will depend of the 
DUT noise characteristics and filter shape. The ADEV calculation at tau > 
tau0 will also apply some sort of filter during decimation, it also should 
be counted for (cause we actually decimate the high rate timestamp stream 
making the points data for the following postprocessing). Am I right?

Here is a good illustration how averaging affects ADEV 
http://www.leapsecond.com/pages/adev-avg/ . If we drop the leftmost part of 
the ADEV affected by averaging, the resulting averaging effects on the ADEV 
are minimized. Also they can be minimized by the optimal averaging strategy. 
The question is optimal averaging strategy and well defined restrictions 
when such preprocessing can be applied.

If it works I would like to add such mode for the compatibility with the 
widely spread post processing SW (TimeLab is a good example). Of cause I can 
do calculations inside the counter without such limitations, but that will 
be another data processing option(s) (which might not be always suitable).

> I'm not saying you are necessarilly incorrect, but it would be
> interesting to hear your motivation.

The end goal is to have a counter mode when the counter produces data 
suitable for post processing for ADEV and other similar statistics with 
resolution better (or counter noise lower) that one shoot one (Pi counter). 
I understand that, if it will be possible, the counter resolution will be 
degraded compared to usual Omega or Delta mode, also there will be some 
limitations for the DUT noise when such processing can be applied.

> Cross talk exists for sure, but there is a similar effect too which is
> not due to cross-talk but due to how the counter is able to interpolate
> certain frequencies.

I have no HW interpolator. The similar problem in the firmware was discussed 
earlier and now it is fixed.

>>> 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.
>
> It suggest a very practical method for FPGA based counters, so that you
> can make use of the high rate of samples that you have and reduce it in
> HW before handing of to SW. As you want to decimate data, you do not
> want to lose the Least Square property, and this is a practical method
> of achieving it.

I have no FPGA also :) All processing is in the FW, I will see how it fits 
the used HW architecture.

Doing it all in FPGA has many benefits, but the HW will be more complicated 
and pricier with minimal benefits for my main goals.

> You do not want to mix pre-filtering and ADEV that way. We can do things
> better.

Are you talking about PDEV?

>> 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 processed?
>
> How does you get so different event-rates?
>
> If you have 5 MHz, the rising edge gives you 5E6 events, and which type
> of processing you do, Pi (none), Delta or Omega, is just different types
> of post-processing on the raw phase data-set.

So, if I want to compare "apples to apples" (comparing Delta and Omega/Pi 
processing) the single measurement of the Delta counter should use a half of 
the events (2.5E6) and the same number(2.5e6) of measurements should be 
averaged, is that right? The counter in Delta mode currently calculates 
results with 50% overlapping, it gives 10e6 stamps for the 1s output data 
rate (the counter averages 2 seconds of data).

All the best!
Oleg