STM32 Fast Fourier Transform (CMSIS DSP FFT) - Phil's Lab  

I was looking to find if any one noted that...but your pined comments break my research loop!!

I love DSP content! Thanks for sharing. There is a CMSIS function that will calculate the complex magnitude from the FFT output. I understand that a peak detector does not need that optimization but folks who are playing around with the CMSIS libraries might want to give it a try.

@@isaacclark9825 Yes we can either use arm_cmplx_mag_f32() for a square-root magnitude or arm_complx_mag_squared_f32() for a non-square root value

Curious to know why you didn't add CMSIS DSP using the CubeIDE MX Software Pack manager?

There is another reason why you don't need the square root. You are actually interested in the power of the signal, not the magnitude. This is how CD has 96 dB dynamic range. Every bit gives your 3 dB more amplitude. With CD's 16 bit your amplitude has 48 dB of dynamic range. log10(65536) = 4.8165. But with 48 dB of amplitude you can get 96 dB of signal power. Amplitude tells you the signal voltage but power tells you, well power. To get the audio power you square your amplitude. You never need to calculate the expensive square root. Just use the real^2 + complex^2 and you're good to go. This is not only cheaper to calculate but more accurate. If you took the FFT with let's say 4096 samples, your screen might not have that much resolution. You might want to combine each frequency together so that you have the same resolution of for example a piano keyboard. You need to sum the powers together to get an accurate picture. If you sum the amplitudes the image won't look right but if you sum the powers it does. In the use case of this video of finding the loudest frequency you might want to get the power in logarithmic units. Just take a log10 of the power. You're interested in how loud that frequency is in deciBels, not how high the signal amplitude is. Another reason not to not calculate the square root is that log10(sqrt(power)) = log10(power) / 2. Square root is just an unnecessary in that case too. Dividing by two is much cheaper. I worked on this a couple of years ago. At first I took 2048 square roots and that's expensive. It cost me like 2 milliseconds per frame and I didn't have two milliseconds. Because the accuracy of the square root is not that important I used the fast inverse square root algorithm that was 20 times faster with an error of only 0.07 %. But in the end it turned out that the square root was completely unneeded. I hope this helps or that someone found this at least interesting.

Thank you very much!

Thanks - will be working on that soon! :)

@@PhilsLab That would be sweet Implemented on FPGA?

Thank you, Ian!

Thank you!

Thanks, Ahmed!

Thank you so much, Sencer!

Hey, I am working on a similar project. Do you have an public repository with your project?

Thank you very much! :)

Thank you!

Thank you! Audio quality is not really achievable using the STM32's built-in ADCs/DACs. I had tried this a while back, but the ENOB is too low, even with oversampling. For other applications, where you only need 12bits or less, then the internal ADCs/DACs can achieve that. However, the actual FFT implementation as shown in the video can be done in pretty much the same way if you're if using the STM32's 'on-board' ADCs and DACs.

@@PhilsLab Thank you for your quick response. I am actually using it that way to minimize components on board (and the complexity of a codec but might go that way though) and being using FFT with a noise level cutoff to achieve a better signal. But i assume the better the signal in the input the better the output

Thanks, Marek! That's correct - although I left in the sqrt for sake of 'completeness'/'correctness'. Given the rather crude nature of the surrounding implementation and no need for 'speed increase', it doesn't make much of a difference for this example.

So how could i find the peak frequency without calculate the absolute value from fft output?

Thanks for watching. You need to include the imaginary & real part in the calculation of magnitude.

Thanks! I'd suggest working on a real-life project and figuring out what you need (Google, Stackoverflow, datasheets, etc..) when the time comes during that project. That approach works the best for me.

Hello, i am not Phil but every opinion counts i assume :D I think an envelope detector, if well configured, is better for your purpose than FFT because FFT provides delay depending on the accuracy you need.Also arduino is not as good mcu as stm32 in this case, so FFT would not be that good for this case.

Hello @@user-sp8xn6zb3w, thank you for the answer. That's true, STM32 is much better, I had to use atmega328p in a course I took in my study program, otherwise I would have go for something better. But FFT is actually very fast algorithm, it was invented by James Cooley and John Tukey to make fourier calculations as fast as possible. I once heard that FFT is used in ABS braking systems of cars because of its speed and accuracy, so I was just wondering. But it's speed is O(NlogN), which is very good speed.

Any chance of an example or guides on how to add the library as source? Just adding the headers files and include paths to the project?

Thanks for watching! Yeah, I wanna make some 'basic' FPGA DSP tutorials first (Spartan 7), before moving over to doing that on the Zynq (although the workflow is of course rather similar).

We had some introductory DSP classes at uni. The rest is pretty much self-taught. Check out: "The Scientist and Engineer's Guide to Digital Signal Processing" (SMITH) and - if you're into audio - "DAFX: Digital Audio Effects" (ZÖLZER).

​@@PhilsLabThank you Phil :)

Thanks, good idea! I haven't used it at all myself to be honest, but will give it a try for a future video.

The initial cost is quite high, yes - but depending on how many boards you have made, assembled, programmed etc. the cost justifies itself quite quickly. Don't know of any alternatives, other than making your own.

@@PhilsLab Okay thank you. Nice video btw :)

There are some pogo pin connector variations that clip onto the board edge. The main constraint with those is that you need to put the connector footprint near the board edge which may not be the most convenient place

Depends on your SWEEP rate + SAMPLING rate + FFT buffer size. This peak frequency detector doesn't detect what is the "highest" frequency but rather what frequency component makes up majority of the input signal. For a sweep, an ideal DFT of the full sweep will result in peaks of all the same magnitude (i.e. all frequency components contribute equally to the input signal) [imagine a column chart with all same heights, from 0 - max sweep frequency]. Assuming the sweep is linear and sampling windows line up. If the sweep doesn't fit within buffer, e.g. like in this video, since it seems to be calculating FFT many times a second, then for each FFT buffer period, it will result in a similar picture to situation above, except starting frequency will not be 0 and ending frequency will not be max sweep either. Basically it will show chunks of column charts based on which part of the sweep it is at/sampled. To implement a highest frequency detector, like what I think you are suggesting, you would need to first determine what threshold or magnitude is considered as being more than NOISE/significant enough. Then just evaluate the FFT buffer in reverse from highest frequency, until you find a bin that exceeds your threshold. To understand more, find some videos about Fourier Transforms, like the one suggested in video, it will clear the confusion about frequency vs magnitude / components

Depends on how fast the sweep is, how long your FFT is, and so on.