Hi
> On May 13, 2018, at 5:13 PM, Oleg Skydan <olegsky...@gmail.com> wrote: > > Hi Magnus, > > From: "Magnus Danielson" <mag...@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” ……. Bob > >>> 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! > Oleg > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
