I have some questions about correct use of the CMSIS DSP library call arm_fir_32. First, I'll provide some background about what I am doing and what the setup is.
I have a STM32F4 Discovery board, using IAR EWARM for programming. Just for testing purposes, I'm generating a low frequency test signal at 40Hz and feeding it into one of the ADC inputs. The signal is biased to swing from 0 to about 2.5Vpp. The signal has a low to moderate amount of broadband noise - but at this point I am not purposely mixing or introducing any other signals with it. There is a timer interrupt set to sample frequency of 2KHz, with a sampling buffer of 2048 samples.
I have already tested and am using the FFT function arm_cfft_f32, and can accurately determine (track) the frequency of the incoming signal when I change it at the source. This seems to be working well.
Now, I would like to use the arm_fir_32 filter. To do this, I started out reading the documentation from CMSIS on the function. To implement a FIR low pass, to generate the tap coefficients, I am using this website's only tool to do so.
I generated a 4th order filter, and set the sampling rate the same as my software, with a cutoff of 60Hz. I forced generation to 24 taps to be even. So the BLOCK_SIZE is 32, and the number of blocks is 1024/32 = 32.
Following the example from CMSIS on this function, I believe I've set up correctly. So the chain looks like this:
ADC --> FIR --> FFT
However, I'm not getting the result I would expect. The values returned from the FFT's output buffer are exponentially large (not this way if I comment out /circumvent the FIR calls). This leads me to believe I am missing a step. Do I need to normalize the values? I thought that because I input the rate into the FIR function setup, this wouldn't be required - but maybe this is incorrect.
Can someone please provide some insight or assistance as to what I am missing or doing incorrectly to apply the FIR processing?
The CMSIS FIR function does not have any unusual scaling that you need to follow. Since you are generating a lowpass filter you can easily determine if the filter is scaled properly by determining its DC response. Simply sum up the coefficients in the filter and the result should be close to 1.0. One thing to keep in mind is that you have a relatively short FIR filter. At 24 points with a sample rate of 2 kHz, your frequency resolution is 83 Hz (2000/24) and you thus won't be able to make changes in the frequency domain at a finer resolution than this.
Could you share your code and we'll take a quick look?
Please, accept my apology for my previous post, it was uncalled for. Just a bit impatient, I am.
Paul, I determined the error and your response helped me to do that. Somehow the FIR coefficients were getting trashed the way I was declaring them and thus resulting in all the trash I was seeing. Now, getting
values that I would have expected. I've created another set of filter coefficients. o to 45Hz, G = 1, 50Hz to 1KHz, G = 0. 1.5dB ripple, -80dB attenuation, 978 taps.
Could you please elaborate a bit further on your comment about the resolution - if I were to use that calculation, it would now be 2000/978 = 2.05. Are you saying this is the lowest resolution of frequency I can accurately ascertain after processing it through the FFT?
Why does the number of taps affect the resolution of the FFT which is another function? If so, how can I attain higher frequency resolution without changing sampling frequency, which is at least 40x higher that the highest frequency I am processing (50Hz) ?
NB - I should have added that I am trying to obtain very high frequency resolution, sub-hertz if possible.
Again, my apologies and I thank you for taking the time to answer my questions.
As requested here is sample code that I am using, in the interrupt handler, which is set to run at SAMPLE_FREQ:
if( TIM_GetITStatus(TIM6, TIM_IT_Update) )
volatile uint16_t uhADCxConvertedValue;
float32_t smplRate = 0;
if( sampleCount == 0 )
arm_fill_f32(0.0, ADC_Values, INPUT_SAMPLES);
uhADCxConvertedValue = ADC_get();
/* subtract the DC offset that was added as this is not a bipolar ADC */
ADC_Values[sampleCount] = ( ((uhADCxConvertedValue * VREF) / ADC_COUNTS) - 1.6);
if(sampleCount++ == INPUT_SAMPLES)
inputBufPtr = &ADC_Values;
outputBufPtr = &outputBuffer;
arm_fir_init_f32(&S, FILTER_TAP_NUM, (float32_t *)&filter_taps, &firStateF32, BLOCK_SIZE);
for(uint16_t i = 0; i < NUM_BLOCKS; i++)
arm_fir_f32(&S, inputBufPtr + (i * BLOCK_SIZE), outputBufPtr + (i * BLOCK_SIZE), BLOCK_SIZE);
/* Process the data through the CFFT/CIFFT module */
arm_cfft_f32(&arm_cfft_sR_f32_len512, outputBuffer, ifftFlag, doBitReverse);
/* Calculate the magnitude at each bin */
arm_cmplx_mag_f32(outputBuffer, cfftBuffer, fftSize);
/* get the maximum energy at index */
arm_max_f32( cfftBuffer, BLOCK_SIZE, &maxValue, &index );
printf("Max Value = %.1f, at index = %i\n", maxValue, index);
smplRate = (INPUT_SAMPLES / 1.0);
printf("frequency = %.1f\n", (float32_t)((index * SAMPLE_FREQ) / smplRate) );
sampleCount = 0;
/* Clear TIM6 Capture compare interrupt pending bit */
This is a rough rule of thumb when it comes to FIR filters. When you compute sample rate divided by FIR length ( 2000/978 = 2.05) you get a rough metric for how accurately you can adjust the frequency response of the FIR filter. You can make changes in the frequency response at roughly 2 Hz spacing. This is broad rule of thumb I use to determine if the filter is long enough in length.
The FIR filter and FFT have separate lengths, but a similar rule of thumb. For the FFT, the frequency resolution is sample rate / FFT size.
Do you need high resolution across the entire frequency band or just at low frequencies?
I only require resolution at low frequencies: 10Hz to 50Hz
I'm confident the FIR has adequate taps for the filtering required. I'm still trying to understand what the impact of putting in a 2 Hz resolution filter ahead of the FFT, which has a (2000/2048) resolution, does to the samples. Does it mean that the distribution of error (of 2Hz) should fall around some Gaussian mean? i.e., 30 Hz could be 31, or 29, but likely 30.4 or 29.6 for approximately 70% of the samples?
After doing a bit more research, I've found that it might be an improvement to use a Windowing function. Do you agree? It appears that CMSIS-DSP has no Window functions that I can see. From what I understand, the Hann would be better to eliminate or reduce the buffer endpoints as they may cause noise that would create the jitter. Can I implement the Window by processing each sample as: y[x]=0.5-0.5cos(2pi n / N-1) ? If so, I've tried this, but it is making the results bad. Should the Window be after the cfft?
One further question: the CMSIS function arm_cfft_f32 returns a buffer which you can then search for a peak sample n (n > 0) and then calculate the frequency. What function is available that will give me the indices of the first N peaks? Or is this a function left for the user to write?
Again, I appreciate your generous time and assistance.
My comment regarding the "2 Hz resolution of the FIR filter" just refers to how accurately you can specify its frequency response. It can be just about any shape (e.g., low pass at 40 Hz, low pass at 80 Hz). However you can't have the filter have gain g0 at 10 Hz and then a widely different gain at 11 Hz. I think its safe for what you are doing.
Its a good idea to use a window (Hanning is a good choice) when computing FFTs. If you don't do this you'll find that the result depends heavily on what is happening at the edges of the signal. If you only care about low frequencies and you want very good resolution, I would recommend taking a long data set at the 2 kHz sample rate, filter by a low pass filter with cutoff frequency 100 Hz and then decimating by a factor of 10. This would reduce your signal length by a factor of 10 and reduce the sample rate to 200 Hz. If you computed an FFT then, say with 1024 points, then the frequency resolution would now be 200/1024 = 0.2 which is much better than what you had before.
Sorry, no function in CMSIS which finds the N largest peaks. But that shouldn't be too hard to write.
OK, thank you for that, no more questions. 8--)
I think it's working well enough now, where I can be happy with consistent 1Hz resolution.
View all questions in Arm Development Studio forum