Hi All;
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?
Thank you,
Gary
It's good to see another Cortex-M developer, welcome to the community. I believe you've come to the right place.
I would like to answer this question, if I could. Unfortunately I'm absolutely no expert in the DSP-area.
Many of us are not online frequently, and might miss out the question, plus I believe that very few people are experienced with the use of the DSP library's FFT functions.
That sums up to that it'll sometimes take a while for deep-technical questions to be answered.
As you've already seen by now, pbeckmann is an expert in this area.
-If you know any ARM developers, please let them know about this community; the more developers, the quicker we'll get replies to advanced questions.
Hi jensbauer,
Thank you.
I've been on the ARM Cortex platform for just over 2 years now. My first was the M3 (LPC1768) which is a nice little processor. I say "little" carefully as it is down a few notches from the STM32F4 that I'm now using. There's been a few hiccups with some of the software under CMSIS, but I couldn't be happier with the ARM Cortex performance. I run the processors hard to get all I can, using FreeRTOS, Visual State and lots of HW interrupts for my projects. The NVIC feature in ARM Cortex has made a world of difference in deterministic operation with respect to timing.
To improve what I'm now working on requires the evolution to DSP processing. So far, so good. However, iIt is difficult to find someone who can provide some insight on the CMSIS DSP library, and I am very grateful that Dr.Beckmann has been kind enough to answer my questions. Hopefully others that will read these posts can benefit from his answers.
Regards,Gary
I'm working a lot with the LPC series Cortex-M processors myself.
Though I have the LPC43xx, my favorite is still the LPC1768.
This is because it's packed with so much goodies that it can handle almost any kind of job.
But most of the time, I select the smallest possible MCU that will fit my needs.
I tend to lean towards writing assembly code, if I can get away with it.
Though it may be in different ways, we share the desire to push a device to its limits - that's the fun part anyway.
(I too have a STM32F4; the Discovery Board, but I'm still working on getting my IDE compatible).