[time-nuts] Limitations of Allan Variance applied to frequency divided signal?

[Tijd Dingen]

Magnus Danielson wrote:

> > http://en.wikipedia.org/wiki/Allan_variance#Non-overlapped_variable_.CF.84_estimators


> Nice to see people actually read and use what I wrote.


:-)


> If you use a prescaler of say 1/64 then it takes 64 cycles of the original
> signal to cause a cycle to the counter core. These are then time-stamped,
> i.e. a time-measure and an event counter measure is taken. To transform
> the event-counter value into the properly scaled event value, you then
> multiply the event counter by 64, since it took 64 times more events than
> counted by the counter. The time-stamps does not have to be modified.


Okay, that clears things up. Thanks!

> Notice that the pre-scaler is only used for higher frequencies.

Understood. I was just using the prescaler as an example for the "what if
if take every Nth edge".


> > Plus, I strongly suspect that all these commercial counters that can
> > handle 6 Ghz and such are not timestamping every single cycle
> > back-to-back either. Especially the models that have a few versions
> > in the series. One cheaper one that can handle 300 MHz for example,
> > and a more expensive one that can handle 6 GHz. That reads like:
> > "All models share the same basic data processing core and the same
> > time interpolators. For the more expensive model we just slapped on
> > an high bandwidth input + a prescaler."

> You never time-stamp individual cycles anyway, so a pre-scaler doesn't do
> much difference. It does limit the granularity of the tau values you use, but
> usually not in a significant way since Allan variance is rarely used for taus
> shorter than 100 ms and well... pre-scaling usually is below 100 ns so it
> isn't a big difference.

Well, I can certainly /try/ to be able to timestamp individual cycles. ;) That way
I can for example characterize oscillator startup and such. Right now I can only
spit out a medium resolution timestamp every cycle for frequencies up to about
400 Mhz, and a high resolution timestamp every cycle for frequencies up to
about 20 MHz.

Medium resolution being on the order of 100 ps, and high resolution being on
the order of 10 ps. The medium resolution is possibly even a little worse than
that due to non-linearities, but there is still a few ways to improve that. Just
requires an aweful lot of design handholding to manually route parts of the
fpga design. I.e: "I will do that later. much much later". ;->

But understood, for Allan variance you don't need timestamps for every indivual
cycle.

> > Anyways, any drawbacks to calculating Allan Variance of a divided signal
> > that I am overlooking here?

> No significant, it adds to the noise floor, but in practice the time-stamping and
> processing doesn't have big problems due to it.

Precisely what I was hoping for, thanks! :)

regards,
Fred