[time-nuts] Re: Timestamping counter techniques : phase computation question

[Bob kb8tq]

Hi

> On Jan 31, 2022, at 2:32 PM, Erik Kaashoek <erik at kaashoek.com> wrote:
> 
> Thanks all for the good input.
> 
> @Magnus, I need some time to understand the math as it has been over 30
> years since when I used to do this kind of math.
> There is no intention to store the collected captures, only to present a
> measurement at the measurement interval, so currently I'm calculating
> the 5 running sums from the captures and at the end of the interval I do
> the regression calculation using these running sums like described in
> the Wikipedia article on linear regression.
> This is what I am storing now (Sum means running sum from start of
> measurement interval till capture number n):  Sum(X), Sum(Y), Sum(X*X),
> Sum (Y*Y) and Sum (X*Y) and n.
> 
> @Tom, thanks for checking, the range for the regression may have been
> 21, and the regression was done from the capture  up to the next 20
> captures so the presented regression outcome at the end of the table
> relied on 20 more  captures not present in the shortened table.
> Let me double check the calculations
> 
> @Atilla, the purpose is to have the best approach for the chosen
> interval into a single number (and possibly some statistical information
> like  an error estimator), it is fully understood that for long
> intervals and drifting/noisy oscillators this single number may have
> little meaning but how else would you get to a single "measurement"?
> Yes, I understand ADEV and the likes to be used as post processing for
> the measurements to have more insight in the performance of the oscillator.
> Most frequency counter present one number for each measurement (and
> possibly some info on the statistics of that number), for me the number
> and the statistics is enough if the interval can be set to any interval
> between 0.1 ms and 10 s (just to give some numbers)
> I will reread the two NIST documents you refer to. I can not access
> articles behind a paywall unfortunately.
> 
> 
> @Bob, The intended application for for this technique is:
> - Either using a single good quality clock to measure the
> characteristics of the events. It is understood the quality of the clock
> sets a lower limit to what can be observed about the events. - Or
> another, more interesting  application is where there is one, not so
> perfect, clock and two events streams, each with their own event count
> and clock captures. This, I hope, will allow to do measurements of the
> relations between the two event streams with an accuracy not (or not
> much) limited by the performance of the clock as any drift in the clock
> will be (almost) equal in each clock capture. Even with hugely different
> event intervals the measurement interval will always be at least one
> event interval and any statement on the relation between the two event
> streams will only have meaning at a timescale of the measurement interval.
> If one would use a two channel frequency counter with a not so good
> internal reference to measure the ratio or phase of two very good
> clocks, what would be possible? How will the uncertainty, noise and
> drift of the internal reference play a role in the performance or is
> there a way to "average out" the impact of the internal reference? For
> drift maybe yes, for noise maybe no.

The more variables you toss into the mix, the more ambiguous the results
become. Noise at one time interval is likely not the same as the noise
at another interval. It’s impact on the calculations will vary and thus the
results will not come out “as expected”. 

I think that setting up a single “good clock” and then measuring the other
sources against it makes a lot more sense. That way it at least all ties back
to a single baseline and does so with some level of consistency. 

Bob

> _______________________________________________
> time-nuts mailing list -- time-nuts at lists.febo.com -- To unsubscribe send an email to time-nuts-leave at lists.febo.com
> To unsubscribe, go to and follow the instructions there.