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

[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

[hp2020]

I used the same program and the same (quiet) noise source for both versions.
Sample 512; Sample frequency 1000Hz, the microphone PIN goes to A0 with 12 bits.

[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.

[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.

[kosme]

@hp2020 I have been checking the data you provided and I noticed that on 1.6.2 you have lots of negative values. Since they are the result of a square root, magnitudes are always positive. This tells me that you are working with really big positive numbers and most likely have an overflow.

[kosme]

Still looks quite weird. Please post, besides the spectrum, a printout of vReal after you finish capturing the data. I'll use that data to try to replicate, and hopefully solve, the problem.

[hp2020]

Sorry, in the first printout I unfortunately had the following code in the program * FFT.Compute(vReal, vImag, SAMPLES, FFT_FORWARD); *
This resulted in the negative values.
This has been cleaned up in the current printouts. The MajorPeak is 1.92 in the 2.02 version and 457.67 in the 1.62 version.

• peak = FFT.MajorPeak(vReal, SAMPLES, SAMPLING_FREQUENCY); *

Magnitudes_vReal_162.txt
Magnitudes_vReal_202.txt

[kosme]

Your computation results are very strange and different for something with a similar data input. As I said in my previous message, I would like to see the original data after capture and before windowing and compute and the spectrum aftercomplexToMagnitude for comparison.

[hp2020]

Ok, I hope this is the data you need.

Computed magnitudes_Data_Input_162.txt
Computed magnitudes_Data_Input_202.txt

[kosme]

So, based on the last files, you are saying that using those 66 samples for 1.6.2 and 64 samples for 2.0.2, you were able to produce the provided spectrums, each with 64 bins?? There is no way that is possible, it requires exactly 128 samples.

[hp2020]

I didn't copy all of them but I can still add the missing ones, but they are all similar.

[kosme]

I need a full set to try to reproduce the problem.

[hp2020]

Here is the data you want. But as I said, the workaround with * FFT.dcRemoval(vReal, SAMPLES); * is completely sufficient for my application.

Computed magnitudes_Data_Input_162.txt
Computed magnitudes_Data_Input_202.txt

[kosme]

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.

I cannot reproduce the problem with the data that you provided. Versions 2.0.2 and 1.6.2 identical outputs both for frequency and magnitude. The spectrum is not even remotely similar to the one you sent. Without further information, I cannot proceed with diagnostics.

[hp2020]

Here is the original example FFT_03, only the values of majorPeak, in both versions. In version 2.02 the values are an order of magnitude lower and are largely unchangeable. In version 1.62 the values are changeable and are a power of ten higher.
The recording conditions from the microphone are very similar. (finger tapping on the tabletop)

FFT_03 only majorPeak every 5sec_202.txt
FFT_03 only majorPeak every 5sec_162.txt