Hi,
I'm starting to test/study the CMSIS lib in the Stellaris/Tiva. Using the paper "Using the CMSIS DSP Library in Code Composer Studio™ for TM4C MCUs", I got build the library and it works fine. The examples return the expected state.
Now I'm trying to use the cFFT in a signal. To the test I created a pure sine wave with amplitude of 1000 and 10 cycles in an array of 1024 samples, as in the image.
After the processing the indexer return the correct harmonic (10th), but I don't understand the result of the magnitude. The magnitude of the 10th hamonic is 727.98. How it relates to the amplitude of the harmonic? The RMS value, if yes, why the error?
This is the principal part of code:
#define N_points 1024 ... uint32_t ifftFlag = 1; uint32_t doBitReverse = 1; /* Process the data through the CFFT/CIFFT module */ arm_cfft_f32(&arm_cfft_sR_f32_len512, wave_float, ifftFlag, doBitReverse); /* Process the data through the Complex Magnitude Module for calculating the magnitude at each bin */ arm_cmplx_mag_f32(wave_float, wave_out, N_points/2); /* Calculates maxValue and returns corresponding BIN value */ arm_max_f32(wave_out, N_points/2, &maxValue, &testIndex);
I tried to scale the sine wave between 1 and -1, but the result was the same. Instead of 727 the magnitude of the harmonic was 0.727.
It's strange because for different numbers of cycles the result of respective "bin" change.
Maintaining the same buffer size (1024) I changed to just one cycle and the result was around 708, very close to the RMS value. See this little list:
1024 samples
01 cycle -> 708.8323
02 cycles -> 710.9644
04 cycles -> 715.2491
08 cycles -> 723.74
16 cycles -> 740.4352
I tried to change the buffer size to 64 samples to test. In this case the result of one cycle was around 740.
I'm reading about how to obtain the amplitude, but in this moment I'm lost!
Hi agaelema,
dwhite85's reply is about the leaking of the amplitude of your signal to the adjacent bins of the FFT output. From the information you supplied, the affliction is throughout the spectrum not just the bins adjacent to the frequency of the input signal. This happens when the frequency of the signal cannot be exactly represented in the discrete spectrum. Methods for minimizing the detriments of this kind of problem exist. Before we plunge into that idea however, there could be other source(s) of error that complicates the situation and it's preferable to sift through it first.
I presume that the tool you used to generate the waveform didn't need an absolute frequency for what you were doing. You can give an absolute frequency for your signal (if you want or if you have used any in your "test") as additional detail but we can use relative or normalized quantities.
You have computed the amplitude, not the power, spectrum since you forwarded the FFT output to the Complex Magnitude function only. For power spectrum estimation the magnitude should be squared (or you could have used the Complex Magnitude Squared instead of just the Complex Magnitude function) and scale it with an appropriate factor.
The "bin change" every time you adjust the number of cycles and samples should be normal if the change is proportionate. Somewhat puzzling however, is the "little list" that you provided. When you changed to just one cycle you should have obtained a clean spectrum both at 1024 and 64 samples. There should be a large magnitude at 1 cycle (index=1) and practically zero for all others (ignoring the large magnitude at index=N-1). From your list, the magnitude increases with frequency and 01 cycle has the smallest. This spectrum is quite anomalous for a rather simple input signal.
A likely cause of the anomaly is the way you set the arguments for the function arm_cfft_f32. You used &arm_cfft_sR_f32_len512 when the FFT length is 1024 (N_points in your code, array of 1024 samples in your description of the input signal), ifftFlag = 1 when you are supposed to perform a forward, not inverse, FFT. Moreover, check the data types of the relevant structures, fields, variables, and arguments such as ifftFlag, doBitReverse, etc. Verify that they match the data types of the corresponding parameters. You should have also modified the argument to the parameter arm_cfft_instance_f32 when you altered the number of samples. If you fix these irregularities, you may eradicate the bulk, if not all, of the problem.
I recommend you repeat your "test" at the different settings you have stated and post the ff:
numerical data, not just the waveform, for the input
numerical data and the FFT plot for the output
I also suggest that you use an amplitude between 1 and 100 (perhaps 10 could be convenient to you). To reiterate, you will have to repeat the test and provide data for the following:
10 cycles at 1024 samples
1 cycle at 1024 samples
1 cycle at 64 samples
For the plot you can simply insert the images in your message but for the numerical data you may send it as attachment (maybe text files) since those are too large to display.
Regards,
Goodwin