Some questions on SingleToneInfo()

[vix]

Using CVI 2010 SP1 I found some problems with SingleToneInfo() and I hope that someone from NI could clarify my doubts.

• in the CVI Help for parameter searchType of SingleToneInfo() I read

If you pass NULL for search or search->centerFrequency is invalid, this function searches the tone in the full frequency range of (0, Fs/2).

What is "search"? If I pass NULL as searchType I get a FATAL RUN-TIME ERROR "Null pointer argument to library function"

• in the same Help I also read

A real tone signal can be expressed as shown in the following equation:

x(n) = A * cos (2*pi*f / f_s + ph)

where A, f, and ph are the amplitude, frequency, and phase of the tone signal

But the function doesn't return a phase coherent with this equation: if you use a waveform with the equation x(n) = 10 * cos (2*pi*f/f_s + 0), the function returns ph = 90° (see attached).

• when the signal is not a perfect sine wave, the results are quite "strange", especially for the phase. How does this function works? Does it perfom some kind of interpolation in the frequency domain?

thanks for the help

[vix]

I slightly modifed the example, so that it shows the "strange" results on phase and frequency.

Could you explain this behavior, please?

[enpe]

Dear Vix,

There is a BUG that it will be fixed into CVI 2012 SP1 version about NULL character as searchType parameter. You can pass an invalid input instead of NULL to scan the full range between 0 to Fs/2. Regarding the "phase" problem you have passed to SinePattern function a phase of 90* and you will obtain a Phase of 90* with SingleToneInfo function. 

Regards,

Enpe

[vix]

I saw this behavior, so I think there is an error in the documentation for SinglToneInfo, because it returns the phase of a sine pattern and not a cosine pattern.

I think that x(n) = A * cos(2pi*fn/fs + ph) should be replaced with x(n) = A * sen(2pi*fn/fs + ph).

Do you agree?

[vix]

Hi enpe,

have you had a look at the example I attached to my second message?

This example shows the strange results for phase and frequency.

Could you give me some explanation, please?

[enpe]

The algorithm behind that function is explained through the following screenshot:

So you have to be careful when you are using this kind of function because of the FFT is discrete. Have a good time!

Enpe

[vix]

I perfectly know that FFT is discrete, and I know the concepts of windowing, leakage and picket-fence effect.

But my question is: if I pass to SingleToneInfo() a defined centerFrequency and a frequencuWidth = 0., the function shouldn't return a frequency different from the supplied centerFrequency. No matter which algorithm is used. Why does it return a different frequency? And it is a wrong value!

[vix]

I've just received a notification from a customer, regarding wrong values returned by my software (developed with CVI 2010 SP1).

After debugging, the problem is in SingleToneInfo() .

Even if I use a searchType.frequencyWidth greater than zero, for some signals the function returns a frequency that doesn't met the searchType requirements (centerFrequency and frequencyWidth).

And this happens without returning any error or warning.

Could NI fix the buggy behavior of this function, please?

I could consider to migrate my project to CVI 2012 SP1, but I don't see any information on the fix of this bugs.

[D-Cubed]

Hi Vix,

Thanks for bringing this issue to our attention.  I have contacted the Advanced Analysis Library team and they can confirm that this is a bug (ID 440964). To clarify the documentation a bit, the SingleToneInfo prototype should be:

SingleToneInfo (double Waveform[], ssize_t Waveform_Size, double Sample_Period_in_Seconds, SearchType *search, double *Frequency, double *Amplitude, double *Phase);.  

The real tone signal representation shown in the help should also be a sine function as you mentioned previously.

In regard to passing a value of 0 for the frequencyWidth parameter, this is not a supported input. However, this unsupported behavior was not enforced in the code which is why you saw erroneous results. The Advanced Analysis Library team is going make the SingleToneInfo function handle 0 as an invalid input for frequencyWidth, and the function will search the tone in the full frequency range.

I hope this clears things up,

[vix]

Hi Daniel,

thanks for your help.

Could you clarify which (of the ones I mention) is the bug with ID 440964?

Could you write the CAR number, please?

I want to be sure that the behavior described into my last message is clear:

• i use frequencyWidth greater than zero (so the parameter is OK)
• with some signals (maybe it depends on three finger algorithm), the frequency returned is outside of the frequencyWidth I set. No error, no warning.
• in this situation (wrong frequency returned), with some signals, the value returned as Amplitude is much bigger that the maximum value of the signal itself

I think this is a bug. Do you agree with me?