[time-nuts] Question about frequency counter testing

[Oleg Skydan]

Hi, Magnus!

--------------------------------------------------
From: "Magnus Danielson" <magnus at 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! 
It looks like the proposed method of decimation can be efficiently realized 
on the current HW. 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.

Also all modes can be unified and can reuse the same acquisition code, 
nice... :)

> I hope to have an updated version of that article available soon.

Please share the link if it will be publicly available.

>>> 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).

All the best!
Oleg