Accurate frequency measurement problem

On 2/11/2016 1:29 PM, Robert Scott wrote:
> On Thu, 11 Feb 2016 02:21:28 -0800 (PST), a.turowski@ymail.com wrote:
>
>> Hi all,
>>
>> Recently I've been faced with a problem of very accurate sine wave frequenc=
>> y measurement. Let me give you some details:
>> I've got a sensor which outputs measurement result as a frequency of a sine=
>> wave. The frequency of the signal is within 149.4kHz - 150.6kHz range and =
>> is very stable, as sensed parameter changes very slowly. Say the frequency =
>> can change no more than tens of ppb (parts per billion) per second. Also th=
>> e signal amplitude should be very stable - it may vary very slowly with tem=
>> perature. The goal is to measure the frequency to 10-100ppb accuracy at lea=
>> st every second - it may be just a frequency change or if possible, absolut=
>> e frequency value. Lets denote the frequency we want to measure as f.
>
> 100ppb at 150kHz is 0.015 Hz.  So you want to measure frequency to
> within 0.015 Hz over a period of one second.  That could be done by
> measuring the phase of the signal (with respect to some stable
> referece) to within 2.7 degrees every second.  Assuming this signal is
> very clean, with no noise, this could be done digitally, but it would
> be hard.  If one cycle is 6.67 usec, 2.7 degrees would be 50nsec.  So
> if you can measure a zero-crossing of the signal to within 50nsec at
> each one second interval, you would have it.  That would require a
> 20GHz clock to sample for a zero-crossing.
>
> Of course you can always tradeoff precision with responsiveness.
> Instead of making each one-second sample independent of the others,
> you could take a series of overlapping sample periods.  For example,
> if you sampled the phase at the beginning and at the end of a
> 10-second period, you could relax the precision of the phase
> measurement (using a 2GHz clock) and still get the same 100ppb
> frequency accuracy.  You could still produce a new measurement every
> second, but that measurement would be reflective of the frequency
> during the previous 10 seconds.  If the frequency is changing, the
> frequency reported by this method will lag the actual frequency by
> about 5 seconds.  But it will be accurate.  This is essentially what a
> PLL does.  You may be able to measure the frequency of the oscillator
> with great precision, but that frequency will not necessarily be
> tracking the frequency of your sensor signal very closely, and will
> only be accurate if the sensor frequency stops changing for a long
> time.
>
> Overall, I would say that the specs you have laid out will be quite
> difficult to meet, especially if you want the reported frequency to be
> accurate with no lag.  The only way I can see getting zero lag is with
> a 20GHz clock capturing the phase in one-second intervals.

An estimate of the phase does not require ultra high sample rates.  I 
can digitally determine the phase of a sine wave much more accurately 
than the sample rate.  He has indicated the input signal changes slowly, 
about 1/10 the amount of his desired resolution in one second.

I think this is doable with a digital PLL.  As others have pointed out 
he needs a tight band pass filter in front of the ADC to minimize the 
noise.  Sampling at 1 MHz should be very adequate.  I know there are 
lots of good ADCs available at that sample rate with high resolution. 
The other issue with under sampling is that it gives up the SNR gain 
that can be had by sampling at a high rate and applying filtering with 
sample rate conversion in the digital domain.  The real enemy will be 
clock stability though.  I think the rest of the system is not so hard.

-- 

Rick

On Thu, 11 Feb 2016 02:21:28 -0800, a.turowski wrote:

> Hi all,
> 
> Recently I've been faced with a problem of very accurate sine wave
> frequency measurement. Let me give you some details:
> I've got a sensor which outputs measurement result as a frequency of a
> sine wave. The frequency of the signal is within 149.4kHz - 150.6kHz
> range and is very stable, as sensed parameter changes very slowly. Say
> the frequency can change no more than tens of ppb (parts per billion)
> per second. Also the signal amplitude should be very stable - it may
> vary very slowly with temperature. The goal is to measure the frequency
> to 10-100ppb accuracy at least every second - it may be just a frequency
> change or if possible, absolute frequency value. Lets denote the
> frequency we want to measure as f.
> 
> I spent some time thinking about a solution and here is the idea I came
> up with. Lets assume that I undersample the signal using 5kHz sampling
> frequency. Then I use FFT to estimate roughly what the signal frequency
> is. Lets denote it as f_approx. Using automatic gain control I make sure
> that incoming signal has known and stable amplitude. Lets denote this
> signal as sig_in_agc. In digital domain I generate a sine wave of
> frequency f_approx and the same amplitude as sig_in_agc. Lets denote
> this signal as sig_approx. Next step is to multiply sig_in_agc by
> sig_approx. This is a standard mixing, which gives me a signal which is
> the sum of two cosines: one having frequency equal to f_approx+f, the
> other f_approx-f. Then I filter out the high frequency component with
> low pass filter and as a result I get only a signal which frequency is
> the difference between f_approx-f. Lets denote it f_diff. Actually this
> signal represents the instantaneous phase difference between sig_in_agc
> and sig_approx. I sample this phase difference periodically and then can
> calculate the f_diff as a derivative over time of the phase difference.
> 
> Do you think that above makes any sense? Are there other (better)
> methods that you can recommend to measure the frequency accurately?

Been thinking about this.

If the signal is perfectly clean then you have a good chance of making 
this work easily.  Sampling faster makes it easier.  Noise and unexpected 
harmonic distortion of the signal make it harder, but not necessarily 
impossible.  A perfectly square wave signal makes it harder (because -- 
lots of harmonic distortion) but you can make that better with bandpass 
filtering.

5kHz sampling doesn't rule it out, but it does make it harder to prove 
ahead of time that it'll work (5kHz is actually a bad choice, because it 
aliases 150kHz down to zero.  You want something that aliases 150kHz down 
to 1/4 your sampling rate, with margin between 0 and 1/2 your sampling 
rate for the extremes of frequency).

Sampling at some high rate (> 300kHz), quadrature mixing with 150kHz, and 
averaging down to a 5kHz (or even 2kHz) rate would work.  It would reduce 
the rate at which you need to do hard math, at least.  It'll certainly 
improve the system performance in the face of any broad-band noise 
sources (like front-end ADC noise, unless you're using just the right 
sort of sigma-delta converter).

Basically I think it's very doable, but proving that it has a chance of 
being doable, and knowing what additional data you need to do the proof, 
isn't trivial.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

On Thu, 11 Feb 2016 02:21:28 -0800 (PST), a.turowski@ymail.com wrote:

>Hi all,
>
>Recently I've been faced with a problem of very accurate sine wave frequenc=
>y measurement. Let me give you some details:
>I've got a sensor which outputs measurement result as a frequency of a sine=
> wave. The frequency of the signal is within 149.4kHz - 150.6kHz range and =
>is very stable, as sensed parameter changes very slowly. Say the frequency =
>can change no more than tens of ppb (parts per billion) per second. Also th=
>e signal amplitude should be very stable - it may vary very slowly with tem=
>perature. The goal is to measure the frequency to 10-100ppb accuracy at lea=
>st every second - it may be just a frequency change or if possible, absolut=
>e frequency value. Lets denote the frequency we want to measure as f.
>
>I spent some time thinking about a solution and here is the idea I came up =
>with. Lets assume that I undersample the signal using 5kHz sampling frequen=
>cy. Then I use FFT to estimate roughly what the signal frequency is. Lets d=
>enote it as f_approx. Using automatic gain control I make sure that incomin=
>g signal has known and stable amplitude. Lets denote this signal as sig_in_=
>agc. In digital domain I generate a sine wave of frequency f_approx and the=
> same amplitude as sig_in_agc. Lets denote this signal as sig_approx. Next =
>step is to multiply sig_in_agc by sig_approx. This is a standard mixing, wh=
>ich gives me a signal which is the sum of two cosines: one having frequency=
> equal to f_approx+f, the other f_approx-f. Then I filter out the high freq=
>uency component with low pass filter and as a result I get only a signal wh=
>ich frequency is the difference between f_approx-f. Lets denote it f_diff. =
>Actually this signal represents the instantaneous phase difference between =
>sig_in_agc and sig_approx. I sample this phase difference periodically and =
>then can calculate the f_diff as a derivative over time of the phase differ=
>ence.
>
>Do you think that above makes any sense? Are there other (better) methods t=
>hat you can recommend to measure the frequency accurately?
>
>Best regards,
>Adam Turowski


You've gotten a decent amount of good advice so far, but I'll pile on
as a +1 for a DPLL solution, which can actually provide a continuous
frequency estimate once it's locked, rather than just once per second.

For 10-100ppb the loop will need a narrow bandwidth, which implies a
long lock time, but once locked the frequency estimate can be
determined from the reference frequency, the DDS rate, and the loop
integrator.   If the loop integrator "leaks" into the DDS to track
drift (or just to de-stress the integrator), then the DDS and the DDS
reference clock alone provide the information needed once the loop is
de-stressed..

As Tim described, it's not that hard, but it does require that the
reference clock that drives the PLL be more stable than the desired
estimate.

Algorithmic methods may work as well.   If the input signal is clean,
then even something easy like Kay's method of frequency estimation
(just accumulating sample-to-sample phase differences) can be very
accurate, if the observation window is long enough.   As Robert Scott
suggested, this can be done with overlapping windows to get the
desired accuracy vs reporting frequency.   There's really not much way
around the time-frequency uncertainty principle;  the more estimation
accuracy you need, the longer you need to observe the signal.   10ppb
is pretty tight.  The DPLL does this by "observing" the signal from
the time you turn it on, so it is continually converging up to the
limits of the system (i.e., stability of the reference, numerical
precision, etc.).  An algorithmic method, like Kay's or other methods,
gets better as the observation interval increases.   Usually a DPLL is
a good choice because the effective observation interval is much
longer than what is often practical for an algorithmic method.




Eric Jacobsen
Anchor Hill Communications
http://www.anchorhill.com

Tim Wescott  <seemywebsite@myfooter.really> wrote:

>Basically I think it's very doable, but proving that it has a chance of 
>being doable, and knowing what additional data you need to do the proof, 
>isn't trivial.

A bit of handwaving (definitely not a proof) suggests that given
a one-second sample of a sinusoid, one can measure its frequency
to a resolution of (1 / SNR) Hz, where SNR is expressed as a power
ratio.

Steve

On Thu, 11 Feb 2016 20:40:23 +0000, Steve Pope wrote:

> Tim Wescott  <seemywebsite@myfooter.really> wrote:
> 
>>Basically I think it's very doable, but proving that it has a chance of
>>being doable, and knowing what additional data you need to do the proof,
>>isn't trivial.
> 
> A bit of handwaving (definitely not a proof) suggests that given a
> one-second sample of a sinusoid, one can measure its frequency to a
> resolution of (1 / SNR) Hz, where SNR is expressed as a power ratio.
> 
> Steve

That sounds reasonable.  SNR could be pretty small, too, since -- if you 
did things right -- it'd be over a 1Hz bandwidth.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

On 11.02.2016 23:40, Steve Pope wrote:
> Tim Wescott  <seemywebsite@myfooter.really> wrote:
>
>> Basically I think it's very doable, but proving that it has a chance of
>> being doable, and knowing what additional data you need to do the proof,
>> isn't trivial.
>
> A bit of handwaving (definitely not a proof) suggests that given
> a one-second sample of a sinusoid, one can measure its frequency
> to a resolution of (1 / SNR) Hz, where SNR is expressed as a power
> ratio.
>
> Steve
>

... which is effectively the MCRB for variance of frequency estimation 
(e.g., Mengali and D'Andrea "Synchronization Techniques..." pp. 60-61), 
accurate to a factor of 3/pi.

Regards,
Evgeny.

Evgeny Filatov  <filatov.ev@mipt.ru> wrote:

>On 11.02.2016 23:40, Steve Pope wrote:

>> Tim Wescott  <seemywebsite@myfooter.really> wrote:

>>> Basically I think it's very doable, but proving that it has a chance of
>>> being doable, and knowing what additional data you need to do the proof,
>>> isn't trivial.

>> A bit of handwaving (definitely not a proof) suggests that given
>> a one-second sample of a sinusoid, one can measure its frequency
>> to a resolution of (1 / SNR) Hz, where SNR is expressed as a power
>> ratio.

>... which is effectively the MCRB for variance of frequency estimation 
>(e.g., Mengali and D'Andrea "Synchronization Techniques..." pp. 60-61), 
>accurate to a factor of 3/pi.

Thanks.  (When handwaving is accurate to a factor of 3/pi, that's 
really pretty successful handwaving...)

S.

<a.turowski@ymail.com> wrote:

>Mako,
>I fail to see how PLL would help me in solving the problem. 

That's right, a PLL does not help solve this problem.  You do
not need to track this sinusoid; you do not need to generate
a clock with a defined relationships to the sinusoid.  You do
not need/want a PLL.

Steve

On Thu, 11 Feb 2016 22:31:21 +0000 (UTC), spope33@speedymail.org
(Steve Pope) wrote:

><a.turowski@ymail.com> wrote:
>
>>Mako,
>>I fail to see how PLL would help me in solving the problem. 
>
>That's right, a PLL does not help solve this problem.  You do
>not need to track this sinusoid; you do not need to generate
>a clock with a defined relationships to the sinusoid.  You do
>not need/want a PLL.
>
>Steve

Actually, a properly designed PLL provides everything he needs and
more, so I don't see how it does not help solve the problem.
Depending on details it might not be the most efficient solution (I
don't think we know enough to know whether it is or isn't), but from
what's been given I think your statement is incorrect.


Eric Jacobsen
Anchor Hill Communications
http://www.anchorhill.com

W dniu czwartek, 11 lutego 2016 23:13:03 UTC użytkownik Eric Jacobsen napisał:
> On Thu, 11 Feb 2016 22:31:21 +0000 (UTC), spope33@speedymail.org
> (Steve Pope) wrote:
> 
> ><a.turowski@ymail.com> wrote:
> >
> >>Mako,
> >>I fail to see how PLL would help me in solving the problem. 
> >
> >That's right, a PLL does not help solve this problem.  You do
> >not need to track this sinusoid; you do not need to generate
> >a clock with a defined relationships to the sinusoid.  You do
> >not need/want a PLL.
> >
> >Steve
> 
> Actually, a properly designed PLL provides everything he needs and
> more, so I don't see how it does not help solve the problem.
> Depending on details it might not be the most efficient solution (I
> don't think we know enough to know whether it is or isn't), but from
> what's been given I think your statement is incorrect.
> 
> 
> Eric Jacobsen
> Anchor Hill Communications
> http://www.anchorhill.com

Hi all,

Thank you for all the suggestions. As I stated in OP, the measured signal is a pure sine wave (by pure I mean the harmonics are below -30dB of the base frequency). So I think the idea to sample with high frequency (say 1MHz), then low pass filter and decimate to improve SNR (and suppress harmonics even further) it the way to go. Lets  designate this signal sig_in_dec_1. I was originally proposing the idea of mixing with a reference frequency, low pass filtering and decimating again to reduce CPU load. On the other hand DPLL idea seems more appealing now but DPLL calculation would need to be performed for every sig_in_dec_1 sample increasing CPU load compared to original proposal. Also as you mention I will have to implement a method to pre-set DPLL so its lock quicker, but after that I would get the frequency measurement every sig_in_dec_1 sample.

Once again thank you for all the suggestions. I will have to digest them and play a little bit with some simulations. Of course please don't hesitate to speak up if you have another approach to solve the problem - I am always open to consider other solutions.

Best regards,
Adam