0
$\begingroup$

I'm new in embedded programming. Trying to choose a dsp, they seem very feature rich for my planned usage.

I want to analyze 18 signals (simultaneously or near simultaneously) real time. I want to do FFT analysis to determine every signal's fundamental frequency, phase and amplitude. Send that data for processing to another micro controller to trigger other stuff etc.

So the core functionality i need is, enough i/o and adc's, just enough precision to deal with this task and FFT analysis.

Or all this can be done with a micro controller which is not dedicated to signal processing?

Maybe you can point me to the right direction?

Thank you.

|improve this question
$\endgroup$
  • 1
    $\begingroup$ 18 simultaneous FFTs goin' on seems like a task that i wouldn't sneeze at. what kind of signals are they? what would be the necessary sample rate? $\endgroup$ – robert bristow-johnson Apr 1 '18 at 19:29
  • $\begingroup$ They are around audio rate (20-20000), mostly simple signals, common wave shapes which you obtain from an oscillator. I just want to get info about them so, maybe the sample rate should be as low as possible to get the enough desired info. $\endgroup$ – Ali Somay Apr 1 '18 at 19:52
  • $\begingroup$ So, how long would your FFTs need to be? this basically means "what's the frequency precision you're aiming for?". Personally, if your maximum sampling rate is 20 kHz, well 18 channels for standard hardware without significant latency restrictions isn't hard (that's a mere cumulative 360 kS/s – a single stereo pair of studio-grade streams at 192 kS/s would be a heavier data load). 18 FFTs in parallel – yeah, that should be OK, too, at these rates, as long as these FFTs don't get overly long; however, FFT complexity increases superlinearly with length, so without that we can't comment. $\endgroup$ – Marcus Müller Apr 1 '18 at 20:03
  • $\begingroup$ Problem really is that the FFT requires a solid amount of memory – usually, at least one transform size. With 18 parallel transforms, this can get into the multiple megabytes rather quickly, and then you're really leaving the amounts of memory you usually see in microcontrollers. I really don't think I'd do this in microcontroller firmware – just too much hassle and hand-picking algorithms. You're not indicating any latency constraint - so, really, just get an application processor (I've heard the raspberry pi compute modules are all the rage), and do it on there – totally relaxed. $\endgroup$ – Marcus Müller Apr 1 '18 at 20:05
  • $\begingroup$ But: None of what you describe actually requires an FFT – I'd argue that you want parametric frequency estimators, which might work with less memory at higher CPU cost, and that might work on beefier microcontrollers. However, again, much more complex than just writing software for a fully-blown application CPU! $\endgroup$ – Marcus Müller Apr 1 '18 at 20:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.