Hi Oleg, On 05/18/2018 12:25 AM, Oleg Skydan wrote: > Hi, Magnus! > > -------------------------------------------------- > From: "Magnus Danielson" <mag...@rubidium.dyndns.org> >>> 2. Study how PDEV calculation fits on the used HW. If it is possible to >>> do in real time PDEV option can be added. >> >> You build two sums C and D, one is the phase-samples and the other is >> phase-samples scaled with their index n in the block. From this you can >> then using the formulas I provided calculate the least-square phase and >> frequency, and using the least square frequency measures you can do >> PDEV. The up-front processing is thus cheap, and there is meathods to >> combine measurement blocks into longer measurement blocks, thus >> decimation, using relatively simple linear processing on the block sums >> C and D, with their respective lengths. The end result is that you can >> very cheaply decimate data in HW/FW and then extend the properties to >> arbitrary long observation intervals using cheap software processing and >> create unbiased least square measurements this way. Once the linear >> algebra of least square processing has vanished in a puff of logic, it >> is fairly simple processing with very little memory requirements at >> hand. For multi-tau, you can reach O(N log N) type of processing rather >> than O(N^2), which is pretty cool. > > I had some free time today to study the document you suggested and do > some experiments in matlab - it was very useful reading and experiments, > thanks!
Thanks for the kind words! > It looks like the proposed method of decimation can be > efficiently realized on the current HW. The algorithm was crafted with the aim of achieving just that. It's really a powerful method. > Also as a side effect calculating large averaging in several blocks should > reduce floating > point associated errors which can reach significant values with careless > coding. Indeed. The framework provided should allow numerically precision to be crafted without too much difficulty, which is another goal. > Also all modes can be unified and can reuse the same acquisition code, > nice... :) As intended. :) The C sums is what you use of MDEV type of processing. >> I hope to have an updated version of that article available soon. > > Please share the link if it will be publicly available. Will do. >>>> From the 2.5 ns single shot resolution, I deduce a 400 MHz count clock. >>> >>> Yes. It is approx. 400MHz. >> >> OK, good to have that verified. Free-running or locked to a 10 MHz >> reference? > > Locked to OCXO (10MHz). OK. I saw some odd frequencies, and I agree with Bob that if you can, using two of those with non-trivial relationship can be used to get really good performance. Cheers, Magnus _______________________________________________ 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.
