Hi Magnus!
From: "Magnus Danielson" <[email protected]>
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
_______________________________________________
time-nuts mailing list -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
