DSPRelated.com
Forums

Frequency offset estimation.

Started by Andrey May 12, 2004
Randy Yates wrote:

> Jerry Avins <jya@ieee.org> writes:
>> ... For example, with a 500 MHz ECL >>clock and a 20 cycles of the measured waveform, its period is measured >>with a precision of 100 picoseconds > > > Where did 100 picoseconds come from? I would think the precision is 1/2 of > 1/500 MHz = 1 nanosecond.
1/20 of 1/500 MHz = 0.1 nanosecond. ... Jerry -- Engineering is the art of making what you want from things you can get. &#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;
Randy Yates wrote:

(snip)

> Do you know what technique a (analog) frequency counter uses to > perform its measurement?
I am not sure about the analog part, but I think there is a reason that the name frequency COUNTER is used. Traditionally digital frequency counters, at least count the number of cycles over some time interval, such that the frequency is the count divided by the interval. The uncertainty in the count is one, as you don't know where in the cycle you start and stop, such that the frequency uncertainty is 1/(count interval). This is without any FFT. Now, for FFT the basis functions have an integer number of cycles over the time interval, and each will contribute to the output spectrum so again the frequency resolution is 1/(sample interval). If you can accurately measure the length of a period, you can determine the frequency over a shorter time interval. As far as an analog frequency measuring device, I would use an analog circuit which generates a pulse of a fixed width on zero crossing and a low pass filter, or let the analog (mechanical) meter's inertia do the low pass filtering. I presume that was much more common before digital electronics became cheap. -- glen
Jerry Avins <jya@ieee.org> writes:

> Randy Yates wrote: > >> Jerry Avins <jya@ieee.org> writes: > > >>> ... For example, with a 500 MHz ECL >>>clock and a 20 cycles of the measured waveform, its period is measured >>> with a precision of 100 picoseconds >> Where did 100 picoseconds come from? I would think the precision is >> 1/2 of >> 1/500 MHz = 1 nanosecond. > > 1/20 of 1/500 MHz = 0.1 nanosecond.
True, but I don't see this as an answer to my question. The counter input is a 500 MHz clock, isn't it? How can the counter measure anything finer than 1/2 of the clock period? For example, let's say I enable the counter for 11 nanoseconds. It's going to count 5 clocks and report the width of the enable period as 5 * 2 nanoseconds = 10 nanoseconds. How would it get within 0.1 nanosecond? The *precision* can never be more than +/- 1/2 of a clock period. -- % Randy Yates % "...the answer lies within your soul %% Fuquay-Varina, NC % 'cause no one knows which side %%% 919-577-9882 % the coin will fall." %%%% <yates@ieee.org> % 'Big Wheels', *Out of the Blue*, ELO http://home.earthlink.net/~yatescr
In article <pt93dc97.fsf@ieee.org>, Randy Yates  <yates@ieee.org> wrote:
> How can the counter measure anything finer than 1/2 of the clock period?
By averaging (or collecting other statistics) over more than on measurement (say 20 measurements of zero crossing intervals). IMHO. YMMV. -- Ron Nicholson rhn AT nicholson DOT com http://www.nicholson.com/rhn/ #include <canonical.disclaimer> // only my own opinions, etc.
Hello,

Thanks all for your tips. I write a little about my problem:

This is a soft modem with supporting v.34 protocol. It has 4 stages
(according v.34 protocol), second stage is probing/ranging telephone
line parameters. I trying to analyse L1  L2 signals, that were
described in v.34 specification:
------------------------
Two line probing signals, L1 and L2, are used to analyse channel
characteristics. L1 is a periodic signal with a repetition rate of 150
+- 0.01% Hz which consists of a set of tones (cosines) spaced 150 Hz
apart at frequencies from 150 Hz to 3750 Hz. Tones at 900 Hz, 1200 Hz,
1800 Hz, and 2400 Hz are omitted. The initial phase of each cosine is
given in Table 17. L1 is transmitted for 160 ms (24 repetitions) at 6
dB above the nominal power level. L2 is the same as L1 but is
transmitted for no longer than 550 ms plus a round trip delay at the
nominal power level.
-----------------------
Sampling frequency is 8000 Hz, length of L1 signal is 160 ms (1280
counts). Length of L2 signal is usually no more that 160+80 ms.

I need to find the parameter of frequency offset for signal in 1050 Hz
between received signal (1050 Hz + some offset) and ideal signal (1050
Hz).

It's described in protocol as:
-----------------------
Frequency offset of the probing tones as measured by the answer modem
receiver. The frequency offset number shall be the difference between
the nominal 1050 Hz line probing signal tone received and the 1050 Hz
tone transmitted, f(received) &#4294967295; f(transmitted). A two's complement
signed integer between &#4294967295;511 and 511 gives the measured offset in 0.02
Hz increments.  The frequency offset measurement shall be accurate to
0.25 Hz.
----------------------

How can i take this accuracy, using only 1280 samples ? I think, fft
and Goertzel isn't a good decision.
rhn@mauve.rahul.net (Ronald H. Nicholson Jr.) writes:

> In article <pt93dc97.fsf@ieee.org>, Randy Yates <yates@ieee.org> wrote: >> How can the counter measure anything finer than 1/2 of the clock period? > > By averaging (or collecting other statistics) over more than on > measurement (say 20 measurements of zero crossing intervals).
That improves accuracy, not precision. -- % Randy Yates % "Watching all the days go by... %% Fuquay-Varina, NC % Who are you and who am I?" %%% 919-577-9882 % 'Mission (A World Record)', %%%% <yates@ieee.org> % *A New World Record*, ELO http://home.earthlink.net/~yatescr
Randy Yates wrote:

> Jerry Avins <jya@ieee.org> writes: > > >>Randy Yates wrote: >> >> >>>Jerry Avins <jya@ieee.org> writes: >> >> >>>> ... For example, with a 500 MHz ECL >>>>clock and a 20 cycles of the measured waveform, its period is measured >>>>with a precision of 100 picoseconds >>> >>>Where did 100 picoseconds come from? I would think the precision is >>>1/2 of >>>1/500 MHz = 1 nanosecond. >> >>1/20 of 1/500 MHz = 0.1 nanosecond. > > > True, but I don't see this as an answer to my question. The counter > input is a 500 MHz clock, isn't it? How can the counter measure anything > finer than 1/2 of the clock period? For example, let's say I enable the > counter for 11 nanoseconds. It's going to count 5 clocks and report > the width of the enable period as 5 * 2 nanoseconds = 10 nanoseconds. How > would it get within 0.1 nanosecond? The *precision* can never be more than > +/- 1/2 of a clock period.
To avoid a potential error from clock asymmetry, I counted only whole clock cycles. Each count, then, represents 2 nanoseconds. Knowing the duration of 20 cycles with an accuracy of 2 ns is the same as knowing the average duration of 1 cycle with an accuracy of 0.1 ns. The crystal reference was good only to 1E-7 after a brief warm up. The display read out in frequency, although period was an option. The division and conversion to decimal was done with logic circuits (counters and a BRM). Jerry -- Engineering is the art of making what you want from things you can get. &#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;
Jerry Avins <jya@ieee.org> writes:
> [...] > Each count, then, represents 2 nanoseconds. Knowing the > duration of 20 cycles with an accuracy of 2 ns is the same as knowing > the average duration of 1 cycle with an accuracy of 0.1 ns.
Sorry. My stupid switch must have been stuck on here for a few days. I see the light now that it's up to full power and my face is forced in its direction. -- Randy Yates Sony Ericsson Mobile Communications Research Triangle Park, NC, USA randy.yates@sonyericsson.com, 919-472-1124
Jerry Avins <jya@ieee.org> writes:

> Randy Yates wrote: > > > Jerry Avins <jya@ieee.org> writes: > > > > >>Randy Yates wrote: > >> > >> > >>>Jerry Avins <jya@ieee.org> writes: > >> > >> > >>>> ... For example, with a 500 MHz ECL > >>>>clock and a 20 cycles of the measured waveform, its period is measured > >>>>with a precision of 100 picoseconds > >>> > >>>Where did 100 picoseconds come from? I would think the precision is > >>>1/2 of > >>>1/500 MHz = 1 nanosecond. > >> > >>1/20 of 1/500 MHz = 0.1 nanosecond. > > True, but I don't see this as an answer to my question. The counter > > > input is a 500 MHz clock, isn't it? How can the counter measure anything > > finer than 1/2 of the clock period? For example, let's say I enable the > > counter for 11 nanoseconds. It's going to count 5 clocks and report > > the width of the enable period as 5 * 2 nanoseconds = 10 nanoseconds. How > > would it get within 0.1 nanosecond? The *precision* can never be more than > > +/- 1/2 of a clock period. > > To avoid a potential error from clock asymmetry, I counted only whole > clock cycles. Each count, then, represents 2 nanoseconds. Knowing the > duration of 20 cycles with an accuracy of 2 ns is the same as knowing > the average duration of 1 cycle with an accuracy of 0.1 ns. The crystal > reference was good only to 1E-7 after a brief warm up. The display read > out in frequency, although period was an option. The division and > conversion to decimal was done with logic circuits (counters and a BRM).
What's a BRM? Jerry, I would like to bring this piece of the thread to resolution. The frequency counter circuit can produce an accurate estimate in a very short amount of time, much less than 1/accuracy. Therefore, you have produced one and only one method to estimate frequency that requires such a long time, i.e., the DFT. Don't you think that your original statement, The straight-forward way to measure frequency to .01 Hz requires samples for 1/.01 = 100 seconds. was a little off? -- Randy Yates Sony Ericsson Mobile Communications Research Triangle Park, NC, USA randy.yates@sonyericsson.com, 919-472-1124
Randy Yates wrote:

   ...

> What's a BRM?
A "binary rate multiplier", a circuit of counter length N that accepts a master clock F and a digital input number n, and outputs a frequency F*n/N, Every transition of the output occurs on an edge of the input clock at such time that the jitter is the theoretical minimum. The details are simple, but out of place in this group. If there's interest, I'll start a separate thread.
> Jerry, I would like to bring this piece of the thread to > resolution. The frequency counter circuit can produce an accurate > estimate in a very short amount of time, much less than 1/accuracy. > > Therefore, you have produced one and only one method to estimate > frequency that requires such a long time, i.e., the DFT. Don't you > think that your original statement,
I didn't think I had produced any. The simplest way to understand (and therefore, in my view, the most straightforward) is simply counting the number of cycles in 100 seconds and then display the results as Hz, with a decimal point before the rightmost two digits.
> The straight-forward way to measure frequency to .01 Hz requires > samples for 1/.01 = 100 seconds. > > was a little off?
I agree that what is "straightforward" is a matter of interpretation. Many commercial frequency counters work exactly like the one that I called above "the most straightforward" way; other types are considered "sophisticated". The context in which I made my original assertion, the analysis of samples taken at times unrelated to the signal being measured, is already more complex. Getting a result faster than a DFT can provide it doesn't seem straightforward to me. That said, I don't expect my view to be universally shared. Jerry -- Engineering is the art of making what you want from things you can get. &#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;