v2.0 does not extract major peak, while v1.6.2 does

[Andrey-Se]

Many thanks for the great library! Tried to extract frequency via arduino nano and mic MAX9814, Arduino IDE 2.3.2. Got no result with v.2.0... Wasted few hours trying figure out a hardware fault. But then downgraded version to 1.6.2, and it started to work! Please double check.

[kosme]

That sounds very problematic. Can you give me more details regarding your code? Since you downgraded to 1.6.2, I assume you are using the pre-2.0 API. Based on the fact that you are using a microphone, I assume that you are sampling through the ADC and doing something similar to Example_03.

[hp2020]

Also thank you for the great library,
I also have the same problem (microphone via ADC).
MajorPeak no longer works from version 2.0.
Thanks

[kosme]

@hp2020 @Andrey-Se
I have some more questions that will help me figure out what the problem is.

• On 2.0, are you using the old API or the new one?
• What data type are you using?
• Are you using any of the #define optimizations?
• What is the output that MajorPeak returns?
• Is the output off target or is it zero?

I hope I can find the problem with that info. Otherwise, I may need a printout of the output of the previous steps, aka, windowing, compute, etc... to backtrack the issue.

[kosme]

Never mind the questions. I can confirm now that the bug is there. It is related to the signal only being composed of positive numbers. As a TEMPORARY WORKAROUND, make sure to use dcRemoval after filling the vReal buffer. That should do the trick while I fix the issue.

[hp2020]

With the workaround it works perfectly, thank you for the very competent and quick problem solving.

[kosme]

This should be fixed with the latest version of the code #95
Please check it thoroughly and let me know if the problem persists.

[softhack007]

arduinoFFT/src/arduinoFFT.cpp

Lines 146 to 148 in 0da8851

	// The DC offset on the signal produces a spike on position 0 that should be
	// eliminated to avoid issues.
	vReal[0] = 0;

@kosme I'm wondering if there is a better place to fix the problem 🤔 if you clear bin 0 directly after FFT, then a reverse FFT will have problems to reconstruct the signal - after all the DC is in the signal, and you just cleared the "real" part leaving vImag[0] intact. So complexToMagnitude() would still return the imaginary part.

Maybe people who don't want to see DC should use a low-cut filter before running FFT... .

It might be better to adjust majorPeak() and majorPeakParabola(), and make these functions ignore the content of vReal[0]?

[kosme]

@softhack007 You are right. Removing the spike generates a DC offset in the reconstructed signal after the IFFT. I will make the change to majorPeak() and majorPeakParabola()

[hp2020]

The problem still exists, in version 1.6.2 the values range from around 50 to 4000 depending on the tone. In version 2.0.2 around 8, in versions 2.0.0 and 2.0.1 around 1. In all 2.0. X versions with the workaround, the values are the same as in version 1.6.2.

[kosme]

@hp2020 I don't really understand your last comment. Could you elaborate? Which values range from 50 to 4000?

[kosme]

@hp2020 I guess your answer to the comment above is located here. I still don't understand what your point is. Could you please provide a printout of the spectrum after the complexToMagnitude function for 1.6.2 and 2.0.x? Obviously, without using the workaround.

FFT.complexToMagnitude(); /* Compute magnitudes */ Serial.println("Computed magnitudes:"); PrintVector(vReal, (samples >> 1), SCL_FREQUENCY);

That would really help me understand your point.

[hp2020]

Here are the results without a workaround.
Computed magnitudes_2.0X.txt
Computed magnitudes_162.txt
For my project (detection of harmful insects), the workaround is completely sufficient for me.