[time-nuts] Question about frequency counter testing
kb8tq at n1k.org
Sun May 13 18:47:10 EDT 2018
> On May 13, 2018, at 5:13 PM, Oleg Skydan <olegskydan at gmail.com> wrote:
> Hi Magnus,
> From: "Magnus Danielson" <magnus at rubidium.dyndns.org>
>> I would be inclined to just continue the MDEV compliant processing
>> instead. If you want the matching ADEV, rescale it using the
>> bias-function, which can be derived out of p.51 of that presentation.
>> You just need to figure out the dominant noise-type of each range of
>> tau, something which is much simpler in MDEV since White PM and Flicker
>> PM separates more clearly than the weak separation of ADEV.
>> As you measure a DUT, the noise of the DUT, the noise of the counter and
>> the systematics of the counter adds up and we cannot distinguish them in
>> that measurement.
> Probably I did not express what I meant clearly. I understand that we can not separate them, but if the DUT noise has most of the power inside the filter BW while instrument noise is wideband one, we can filter out part of instrument noise with minimal influence to the DUT one.
>> There is measurement setups, such as
>> cross-correlation, which makes multiple measurements in parallel which
>> can start combat the noise separation issue.
> Yes, I am aware of that technique. I event did some experiments with cross correlation phase noise measurements.
>> Ehm no. The optimal averaging strategy for ADEV is to do no averaging.
>> This is the hard lesson to learn. You can't really cheat if you aim to
>> get proper ADEV.
>> You can use averaging, and it will cause biased values, so you might use
>> the part with less bias, but there is safer ways of doing that, by going
>> full MDEV or PDEV instead.
>> With biases, you have something similar to, but not being _the_ ADEV.
> OK. It looks like the last sentence very precisely describes what I was going to do, so we understood each other right. Summarizing the discussion, as far as I understand, the best strategy regarding *DEV calculations is:
> 1. Make MDEV the primary variant. It is suitable for calculation inside counter as well as for exporting data for the following post processing.
> 2. Study how PDEV calculation fits on the used HW. If it is possible to do in real time PDEV option can be added.
> 3. ADEV can be safely calculated only from the Pi mode counter data. Probably it will not be very useful because of low single shoot resolution, but Pi mode and corresponding data export can be easily added.
> I think it will be more than enough for my needs, at least now.
>> From the 2.5 ns single shot resolution, I deduce a 400 MHz count clock.
> Yes. It is approx. 400MHz.
I think I would spend more time working out what happens at “about 400 MHz” X N or
“about 400 MHz / M” …….
>>> 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.
>> Exactly what you mean by FW now I don't get, for me that is FPGA code.
> I meant MCU code, to make things clearer I can use the SW term for it.
> Thank you for the answers and explanations, they are highly appreciated!
> All the best!
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
More information about the time-nuts