DSPRelated.com
Forums

frequency measurement and time-frequency uncertainty

Started by Randy Yates 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)? >
is the answer here? 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. What is your upper-limit for the ADC sampling rate (and, respectively, 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)? >> > >is the answer here? > > >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)? >>> >> >>is the answer here? >> >> >>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.
Ewe - sample clock jitter. Hadn't thought about that...
> 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)? >>>> >>> >>>is the answer here? >>> >>> >>>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. > >Ewe - sample clock jitter. Hadn't thought about that...
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 should already have jitter specs. 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).