Problem using arm_cfft_q15

[Noname1937]

Posted on February 27, 2018 at 01:32

Hello,

I am doing a project in which I am using the FFT to do some calculations for a determined signal. I get real data from the ADC and then process it with the FFT.

I noticed that the FFt give me an incorrect output, meaning that whenever I use the FFT to calculate magnitude, or RMS value, or anything I get incorrect values and the problem is not due to scaling since a DC signal give me an RMS value of 0.48 and a 60Hz sine wave that is 3.3V peak to peak gives me a result of 0.5. Because of that I decided to do the following:

- Take the raw data from the ADC and graph it (I got a pretty albeit noisy sign wave);

- Create a sine wave in real time and the perform the FFT

           var = 0.0625 * arm_sin_f32(2 * PI * i / 128 + PI/2) + 0.0625;

           arm_float_to_q15(&var, &buffer, 1);

    I performed the float, q31 and q15 FFT and got the expected result for RMS value of the sine wave.

- I compared  both the runtime sinusoidal wave and the acquired wave from the ADC, both were very similar only the ADC sine wave was noisier.

- I decided to convert the data from the ADC to float and then do the float CFFT and the results were correct. I injected varying amplitude signals and all the time I got the correct output (after doing some scaling).

Has anyone faced this problem as well? Is this a bug or am I doing something wrong? Of course I gave the function a complex array, where the even indices were the raw ADC data and the odd indices were 0 (zero). Please help, I'd rather use the q15 version of the CFFT because then I don't have to spend time converting the entire buffer before processing

PS: The ADC buffer is filled by DMA @10kHz

Also, If I use the arm_rms_q15 function on the output of arm_cfft_q15 the result is ALWAYS zero.

#fft-stm32f4 #cmsis-dsp #q15_fft

[AvaTar]

Posted on February 27, 2018 at 08:53

- I decided to convert the data from the ADC to float and then do the float CFFT and the results were correct. I injected varying amplitude signals and all the time I got the correct output (after doing some scaling).

Are you aware what q15 is ?

It seems you have a scaling/accuracy problem.

The q15 data type has no real advantage compared to q31, halfword access is not faster than word access.

[Noname1937]

Posted on February 27, 2018 at 12:04

But the result of the q31 is not that great either, I decided on using q15 CFFT because the ADC data is 12 bits. I have just tried using the arm_cfft_q31, but I can't just use the data as is formthe ADC, I have to do arm_q15_t_q31 or else it always gives zero as a result for the RMS value.

Are you aware what q15 is ?

Yes. I think I might have expressed myself incorrectly, when I said that I converted the raw ADC data to float and executed the CFFT, I meant to say that I converted the data and performed the arm_cfft_f32 and not the arm_cfft_q15.

As I said in my original post, I don't want to have to convert data before using it, that's why I wanted to use the q15 CFFT

[AvaTar]

Posted on February 27, 2018 at 13:14

The 12 bit ADC data are neither q15.

If you don't scale your input data to the format range, you are losing accuracy.

For proper magnitude (phase) values, your 0dB input value should be scaled to the data range (q15, q31).

I utilized M4F cores when using FFT, either F3, F4 or F7 MCUs. And I think the runtime requirements are not significantly higher, compared to integer.

With a STM32F407 at 168MHz core clock, I got about 2.5 ms for a 2048 CFFT using float, with maximal optimization.

Just the compiler builtin optimization, nothing else.

[Andrew Neil]

Posted on February 27, 2018 at 09:40

Cross post: 

http://www.keil.com/forum/63396/