[time-nuts] Question about frequency counter testing
magnus at rubidium.dyndns.org
Thu May 17 18:54:04 EDT 2018
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 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.
>>>> 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
> 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.
More information about the time-nuts