[time-nuts] Question about frequency counter testing

[Magnus Danielson]

Hi Oleg,

On 05/18/2018 12:25 AM, Oleg Skydan wrote:
> 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!

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