[time-nuts] Question about frequency counter testing

[Magnus Danielson]

Oleg,

On 05/11/2018 04:42 PM, Oleg Skydan wrote:
> Hi
> 
> --------------------------------------------------
> From: "Bob kb8tq" <kb8tq at n1k.org>
>> The most accurate answer is always “that depends”. The simple answer
>> is no.
> 
> I have spent the yesterday evening and quite a bit of the night :)
> reading many interesting papers and several related discussions in the
> time-nuts archive (the Magnus Danielson posts in "Modified Allan
> Deviation and counter averaging" and "Omega counters and Parabolic
> Variance (PVAR)" topics were very informative and helpful, thanks!).

You are welcome. Good that people have use for them.

> It looks like the trick to combine averaging with the possibility of
> correct ADEV calculation in the post processing exists. There is a nice
> presentation made by prof. Rubiola [1]. There is a suitable solution on
> page 54 (at least I understood it so, maybe I am wrong). I can switch to
> usual averaging (Lambda/Delta counter) instead of LR calculation (Omega
> counter), the losses should be very small I my case. With such averaging
> the MDEV can be correctly computed.

If fact, you can do a Omega-style counter you can use for PDEV, you just
need to use the right approach to be able to decimate the data. Oh,
there's a draft paper on that:

https://arxiv.org/abs/1604.01004

Need to update that one.

> If ADEV is needed, the averaging
> interval can be reduced and several measurements (more then eight) can
> be combined into one point (creating the new weighting function which
> resembles the usual Pi one, as shown in the [1] p.54), it should be
> possible to calculate usual ADEV using such data. As far as I
> understand, the filter which is formed by the resulting weighting
> function will have wider bandwidth, so the impact on ADEV will be
> smaller and it can be computed correctly. Am I missing something?

Well, you can reduce averaging interval to 1 and then you compute the
ADEV, but it does not behave as the MDEV any longer.

What you can do is that you can calculate MDEV or PDEV, and then apply
the suitable bias function to convert the level to that of ADEV.

> I have made the necessary changes in code, now firmware computes the
> Delta averaging, also it computes combined Delta averaged measurements
> (resulting in trapezoidal weighting function), both numbers are computed
> with continuous stamping and optimal overlapping. Everything is done in
> real time. I did some tests. The results are very similar to the ones
> made with LR counting.

Yes, they give relatively close values of deviation, where PDEV goes
somewhat lower, indicating that there is a slight advantage of the LR/LS
frequency estimation measure over that of the Delta counter, as given by
it's MDEV.

Cheers,
Magnus