# frequency measurement and time-frequency uncertainty

Started by July 25, 2018
```On 25.7.18 23:34, Randy Yates wrote:
> Hi Marcel,
>
> Marcel Mueller <news.5.maazl@spamgourmet.org> writes:
>
>> Am 25.07.2018 um 18:27 schrieb Randy Yates:
>>> We have a requirement to measure a 32.768 KHz TTL output quickly
>>> and with a certain accuracy.
>>>
>>> If one used an N-bit ADC sampling at F samples per second, what is the
>>> relationship between T_m and F_delta, where T_m is the minimum
>>> measurement time (say, in seconds) for a maximum frequency error of
>>> F_delta (say, in PPM)?
>>
>> Basically the inaccuracy is 1 cycle, i.e. if you measure 32 kHz for
>> one second you get about 1/32k = 30ppm.
>
> Where do you get this from?
>
>> The situation changes, if the waveform is *exactly* known. In this
>> case less than a single cycle might be sufficient to get the same
>> accuracy. It all depends on the definition of /exactly/ and of course
>> you ADC is precise enough.
>
> I'm not sure I follow you here, but let's say we know it's a sinusoid
> (the shape is sinusoid), but we don't know its amplitude, frequency, or
> phase. However we do know its frequency within a certain range.
>

TTL output is not a sinusoid.

For fast measurement, you have to time the rising edges
and invert the result.

--

-TV

```
```Am 26.07.2018 um 02:20 schrieb Randy Yates:

>
> Yes, it is a TTL signal, or more precisely, a square wave signal from a1
> to a2 volts (ideally a1 = 0 and a2 = 3.3V). (Actually it is an
> open-drain CMOS signal, see the Intersil ISL1208 IRQ*/FOUT pin.)

Why don't you simply use a time interval counter, like the Stanford
SR620?  12 digits in a second if your process is faster than a second.

like this:
<
https://www.flickr.com/photos/137684711@N07/38870750440/in/album-72157662535945536/
>

That was the European power grid frequency hickup in January when some
"dwarfs" in the extreme south east fought over who had to compensate
some blind power. It made the grid synchronous clocks late after some weeks.

The setup was just a wall wart transformer and 2 1K resistors to reduce
the voltage somewhat.

You might search the archives of the time nuts list at febo.com for
time interval counters & their principles.

regards, Gerhard

```
```spope384@gmail.com (Steve Pope) writes:

> I think in this case the length of the observation window is
> important, but one does not need to sample continuously
> throughout the observation window -- all you need is the
> time-position of one edge near the beginning of the window,
> another near the end of the window, and a count of the number
> of in-between edges.  This gives you the frequency.
>
> I've used this for frequency-tracking, it can work perfectly well.

OK, thanks for that Steve, but the fundamental question I have is:
how small can we make the "observation window" and still attain
a estimation certain accuracy (2PPM at 32.768 kHz)?
--
Randy Yates
Embedded Linux Developer
http://www.garnerundergroundinc.com
```
```>
> OK, thanks for that Steve, but the fundamental question I have is:
> how small can we make the "observation window" and still attain
> a estimation certain accuracy (2PPM at 32.768 kHz)?
>

http://www.dtic.mil/dtic/tr/fulltext/u2/a167992.pdf

mark
```
```On 26.07.2018 16:05, Randy Yates wrote:
>> I think in this case the length of the observation window is
>> important, but one does not need to sample continuously
>> throughout the observation window -- all you need is the
>> time-position of one edge near the beginning of the window,
>> another near the end of the window, and a count of the number
>> of in-between edges.  This gives you the frequency.
>>
>> I've used this for frequency-tracking, it can work perfectly well.
>
> OK, thanks for that Steve, but the fundamental question I have is:
> how small can we make the "observation window" and still attain
> a estimation certain accuracy (2PPM at 32.768 kHz)?
>

Depends on how wide you can make the anti-aliasing filter (and,
respectively, how high the ADC sampling rate could reasonably be so that
the Nyquist condition is satisfied).

If the width of a rectangular pulse is T, and the corner frequency of
the anti-aliasing filter is N/T, then the variance for estimating the
time of each transition would vary as 1/N (for N >= 1, kinda like that).
The idea is, the wider the anti-aliasing filter, the steeper transitions
you will get. Which will finally help you to estimate the frequency more
precisely.

the passband of the anti-aliasing filter)?

Gene.

```
```On Thu, 26 Jul 2018 07:14:16 -0700 (PDT), makolber@yahoo.com wrote:

>
>>
>> OK, thanks for that Steve, but the fundamental question I have is:
>> how small can we make the "observation window" and still attain
>> a estimation certain accuracy (2PPM at 32.768 kHz)?
>>
>
>
>
>http://www.dtic.mil/dtic/tr/fulltext/u2/a167992.pdf
>
>mark

That's for sinusoids.   This isn't a sinusoid, so assumptions may not
apply.

I think the thing to do would be to pick a potential methodology or
two and then do some analysis on those to see whether you can get to
your desired spec or not with those methodologies.  If so, go for it,
if not, look for another method.

e.g., take the jitter spec on the clock and see how much averaging it
might take to get down to 2ppm by timing edges, then how many periods
that would require, and see if it's a practical approach.   Or lock a
PLL to known reference signal and measure the difference.

A few practical methods have been suggested.  I think it just takes a
little work from there.   There's unlikely to be a cookbook formula to
plug in and give a general answer to a specific problem.

```
```theman@ericjacobsen.org (Eric Jacobsen) writes:

> On Thu, 26 Jul 2018 07:14:16 -0700 (PDT), makolber@yahoo.com wrote:
>
>>
>>>
>>> OK, thanks for that Steve, but the fundamental question I have is:
>>> how small can we make the "observation window" and still attain
>>> a estimation certain accuracy (2PPM at 32.768 kHz)?
>>>
>>
>>
>>
>>http://www.dtic.mil/dtic/tr/fulltext/u2/a167992.pdf
>>
>>mark
>
> That's for sinusoids.   This isn't a sinusoid, so assumptions may not
> apply.

I could just filter it... all that matters is the fundamental frequency.

> I think the thing to do would be to pick a potential methodology or
> two and then do some analysis on those to see whether you can get to
> your desired spec or not with those methodologies.  If so, go for it,
> if not, look for another method.
>
> e.g., take the jitter spec on the clock and see how much averaging it
> might take to get down to 2ppm by timing edges, then how many periods
> that would require, and see if it's a practical approach.   Or lock a
> PLL to known reference signal and measure the difference.

> A few practical methods have been suggested.  I think it just takes a
> little work from there.   There's unlikely to be a cookbook formula to
> plug in and give a general answer to a specific problem.

I appreciate all these practical suggestions, but I wanted to get a
theoretical, somewhat idealized result before I went further. E.g.,
if the theory revealed I could never get better than 15 seconds, it
ain't worth pursuing.

mark, I am picking through that paper. Thanks for that.

Also, thanks for your post, navaide - I'm going to try to dig up your
paper and have a closer look.
--
Randy Yates
Embedded Linux Developer
http://www.garnerundergroundinc.com
```
```Randy Yates  <randyy@garnerundergroundinc.com> wrote:

>spope384@gmail.com (Steve Pope) writes:

>> I think in this case the length of the observation window is
>> important, but one does not need to sample continuously
>> throughout the observation window -- all you need is the
>> time-position of one edge near the beginning of the window,
>> another near the end of the window, and a count of the number
>> of in-between edges.  This gives you the frequency.

>> I've used this for frequency-tracking, it can work perfectly well.

>OK, thanks for that Steve, but the fundamental question I have is:
>how small can we make the "observation window" and still attain
>a estimation certain accuracy (2PPM at 32.768 kHz)?

With the TTL signal (as opposed to a waveform that is actually
designed for this sort of purpose), I would model it based on the dV/dT
of the signal during its transitions (probably, the high-to-low
transition is faster, so always use that one).  Then I'd include
some additive gaussian noise with an amplitude of maybe 100 to 200
millivolts.

(Although it may be fruitful to measure the noise, or just eyeball it
on a scope.)

Put together these numbers to get a jitter component along the
time axis on each negative edge.  Then make sure the sample rate of
your comparator is sufficiently high such that the accuracy
will be noise-limited rather than sample rate limited.
If that is possible.

This should give you the answer you're looking for.  Or at least
the average accuracy as a function of observation length; you'd have to
look at it a bit more to estimate the worse case accuracy.

The above ignores the accuracy/jitter of your sampling clock,
which might also be limiting.

Steve
```
```On Thu, 26 Jul 2018 13:51:42 -0400, Randy Yates
<randyy@garnerundergroundinc.com> wrote:

>theman@ericjacobsen.org (Eric Jacobsen) writes:
>
>> On Thu, 26 Jul 2018 07:14:16 -0700 (PDT), makolber@yahoo.com wrote:
>>
>>>
>>>>
>>>> OK, thanks for that Steve, but the fundamental question I have is:
>>>> how small can we make the "observation window" and still attain
>>>> a estimation certain accuracy (2PPM at 32.768 kHz)?
>>>>
>>>
>>>
>>>
>>>http://www.dtic.mil/dtic/tr/fulltext/u2/a167992.pdf
>>>
>>>mark
>>
>> That's for sinusoids.   This isn't a sinusoid, so assumptions may not
>> apply.
>
>I could just filter it... all that matters is the fundamental frequency.
>
>> I think the thing to do would be to pick a potential methodology or
>> two and then do some analysis on those to see whether you can get to
>> your desired spec or not with those methodologies.  If so, go for it,
>> if not, look for another method.
>>
>> e.g., take the jitter spec on the clock and see how much averaging it
>> might take to get down to 2ppm by timing edges, then how many periods
>> that would require, and see if it's a practical approach.   Or lock a
>> PLL to known reference signal and measure the difference.
>

More importantly, jitter in the clock you're measuring.   The circuit
generating the clock should be analyzable for jitter expectations, or,
if it's coming out of an oscillator or PLL-conditioned oscillator, it

For that matter, it should have frequency stability specs, too, I'd
think.

Steve mentioned another approach to model jitter.   It's pretty easy
to see on an oscilloscope, too, to get a basic characterization for a
particular unit.   Digital scopes make it easy to evaluate jitter
excursions.

>> A few practical methods have been suggested.  I think it just takes a
>> little work from there.   There's unlikely to be a cookbook formula to
>> plug in and give a general answer to a specific problem.
>
>I appreciate all these practical suggestions, but I wanted to get a
>theoretical, somewhat idealized result before I went further. E.g.,
>if the theory revealed I could never get better than 15 seconds, it
>ain't worth pursuing.

And what I'm suggesting is that you can be led down the garden path
that way, or spend a lot of time doing analyses that aren't that
useful toward the actual problem.   The CRB analyses for frequency
estimation are pretty well known and understood and generally are for
sinusoids in AWGN.   That's not what you have.   You're right, you
could turn it into one, but then you also need to include the effects
and characteristics of your filter, e.g., it's Noise Figure, etc.,
etc.   The CRB isn't really a universal concrete tool, anyway, but is
a good reference point.

A little time with an oscilloscope to characterize the jitter, if it
isn't on a datasheet already, would probably go further toward giving
you an idea of measurement limitations using simple, robust methods.

>mark, I am picking through that paper. Thanks for that.
>
>Also, thanks for your post, navaide - I'm going to try to dig up your
>paper and have a closer look.
>--
>Randy Yates
>Embedded Linux Developer
>http://www.garnerundergroundinc.com

```
```In your case a transition occurs as time advances by every period (no missi=
ng transitions). The closed form solution then gives extremely simple expre=
ssions for the variance in reference time "P11" and in the period "P22" at =
the end of 'M' consecutive observed transitions.  Kalman's notation for mea=
surement error
variance is 'R' -- that includes combined effects of all contributors; cloc=
k jitter, interpolation error, etc.).  Then
P11 =3D R (2/M) (2M-1)/(M+1)    P22 =3D R (2/M) (6)/(M^2-1)
It is of interest to express RMS errors (square roots of the variances) for=
large 'M' -- denoting square root of 'M' and 'R' as 'm' and 'r' respectiv=
ely the RMS error in reference time and in the period are essentially  2r/m=
and  2(1.732)r/(Mm)  respectively.  This latter expression, rigorously de=
rived and quite easy to compute, is the idealized result you want. All you =
need is a value set for 'r' (make it conservative to be safe) and determine=
the lowest value of 'm' that will give you your allowable error in the per=
iod (period is obviously the reciprocal of frequency).

There are a few details, probably of minor importance to you.  The solution=
came from forming the least squares expression
[inverse {(H'H)}] H' z
(where ' here represents matrix transposition), followed by known expressio=
ns for sums of consecutive integers and their squares.  A slightly differen=
t covariance matrix is first formed by defining 'X(1)' as the initial refer=
ence time.  That matrix is then propagated to final reference time using a =
simple 2x2 transition matrix, producing the results just given.  Another ch=
ange that occurs with that propagation is a sign reversal of accompanying o=
ff-diagonal terms P12=3DP21 (also of less importance).  The navigation and =
tracking example is very similar but, again, involving other parameters (e.=
g., distance) that attach greater significance to initial-vs-final time (e.=
g., error in initial position carries implications differing from error in =
final position).
```