Welcher Mikrocontroller? (Audio Spectrum Analyzer)

OP #2437959
Lesenswert?

Moin Moin!

Ich bin momentan langsam dabei mein neustes Projekt vorzubereiten. Ich 
möchte einen 20-Kanal Audio Spectrum Analyzer bauen (digital!). Ich habe 
die beiden Seite, auf denen ich mir bislang theoretische Gedanken 
gemacht habe, mal eingescannt und mit hochgeladen.
Die Kanäle sollen die folgenden Mittenfrequenzen haben [Hz]:

31
62
93
126
170
230
310
420
563
760
1024
1380
1862
2510
3386
4565
6155
8300
11200
15000

Da ich bei den unteren Kanälen eine Frequenzauflösung von 30 Hz 
benötige, müsste das N (der FFT) 4096 bei einer Abtastfrequenz von 80 
kHz betragen, was also einen erheblichen Rechenaufwand bedeuten würde. 
Die Idee ist, das Signal in zwei Pfade aufzuteilen und mit den 
Abtastfrequenzen 8 kHz und 80 kHz jeweils eine FFT der Länge 256 
durchzuführen.

Hinterher sind dann nur noch die Betragsspektren zu berechnen 
(entspricht den Leistungsdichtespektren) und für die verschiedenen 
Kanäle verschiedene diskrete Spektralwerte zu überlagern, um das 
gewünsche Ergebnis zu erhalten.

So steht's in etwa auch alles auf den beiden eingescannten Seiten.

Nun hoffe ich, dass das ganze nicht kompletter Quatsch ist und überlege, 
welcher Prozessor für diese Aufgabe geeignet ist. Für die 
Signalverarbeitung würde sich natürlich ein DSP gut eigenen, habe aber 
eher Erfahrungen mit AVR's. Würde zur not aber auch einen DSP nutzen. 
Bin bei der Menge an AVR's, DSP's, PIC's etc... aber etwas überfordert 
etwas geeignetes zu finden.

Wichtig ist vielleicht noch, dass ich ja insgesamt 20 x 10 = 200 LED's 
für die Balkenanzeige ansteuern möchte. 40 IO's also gut wären :) 
Notfalls ginge jedoch auch weniger, indem ich einen zweiten µC 
dahinterhänge, der nur die Ansteuerung der LED's übernimmt. Mal sehen. 
Wichtiger ist erstmal die Signalverabeitung. Der Prozessor muss 
natürlich 2 schnelle ADC's und genügend Speicher enthalten. Die 
Anti-Alias-Tiefpassfilter baue ich dann analog davor.

Ich würde mich freuen, wenn jemand Anregungen zur Auswahl eines 
geeigneten Prozessors für mich hat :)
Angehängte Dateien:
Gast #2437984
Lesenswert?

Eine Abtastfrequenz von 80 kHz braucht man nur, wenn man beim 
Antialiasing Filter sparen will, und mit Oversampling arbeiten will. Der 
FFT Software reichen auch rund 40 kHz. Für die Niedrigeren Frequenzen 
braucht man keinen 2. A/D, das kann man in Software erledigen. Für die 
Auflösung braucht man auch keine FFT mit 256 Punkten, da würde auch 32 
oder 64 schon reichen - wie schon geschrieben aufgeteilt auf 2 Bereiche.

Als µC wäre vermutlich so etwas wie ein kleiner ARM passend. Da reicht 
dann auch das RAM und der AD Wandler.
Gast #2438014
Lesenswert?

>Die Kanäle sollen die folgenden Mittenfrequenzen haben [Hz]:

Warum?

>Da ich bei den unteren Kanälen eine Frequenzauflösung von 30 Hz
>benötige,

Warum?

>Wichtig ist vielleicht noch, dass ich ja insgesamt 20 x 10 = 200 LED's
>für die Balkenanzeige ansteuern möchte. 40 IO's also gut wären :)

200 LEDs low Current a 2mA = 400mA. Kannste knicken direkt am uC.
200 LEDs billig a 10mA = 2A. Kannste knicken direkt am uC.

Brauchste also noch Treiber.

Dein ganzes Projekt ist doch von Arsch. 20 Kanäle
kann man doch noch analog mit einem LM3915 gemultiplext
auf 20 analoge Bandpässe machen;)
Gast #2438053
Lesenswert?

holger schrieb:
> 200 LEDs low Current a 2mA = 400mA. Kannste knicken direkt am uC.
> 200 LEDs billig a 10mA = 2A. Kannste knicken direkt am uC.

Er kann doch multiplexen. Willst du ja mit dem LM3915 auch!

> Dein ganzes Projekt ist doch von Arsch. 20 Kanäle
> kann man doch noch analog mit einem LM3915 gemultiplext
> auf 20 analoge Bandpässe machen;)

20 analoge Bandpässe brauchen auch Platinenfläche und Bauteile. Das wird 
nicht billiger. Ich würde einen von den neuen STM32F4 nehmen (als 
Proto-Board den STM32F4 Discovery, da gibts bei den App-Notes gleich was 
um Audio aufzunehmen), der Cortex-M4 kann sogar mit Gleitkomma 
(Hardware!) rechnen. Auch ist der uC flexibler, wenn er mal andere 
Frequenzen braucht, oder evtl. ein Farb-LCD noch zusätzlich anschließen 
will. Er könnte mit einem Stereo-Codec gleich noch einen graphischen EQ 
programmieren, oder einen parametrischen, oder Hall/Echo ...
ok, wenn er das alles nicht will und wenn er von uC keine große Ahnung 
hat, dafür von analoger Technik, dann kann man über die analgo Lösung 
nachdenken.
#2438357
Lesenswert?

Da das ganze ja ohnehin nur Eyecandy/Spielzeug ist und kein Messgerät, 
könntest Du die Berechnung der paar Frequenzkomponenten auch per 
Goertzel-Algorithmus implementieren. Dessen Güte soll in deinem Fall ja 
gar nicht so groß sein, da Du ja ganze Frequenzbereiche - und keine 
schmalbandigen Einzelfrequenzen - den einzelnen Baragraphen zuordnen 
willst; demnach sollte sich das Rechenaufwand stark in Grenzen halten 
und das Vorhaben (Gefühlsmäßig - ohne das auch nur überschlägig mal 
durchgerechnet zu haben, ergo: _ohne Gewähr!_) sich tatsächlich mit 
einem AVR bewältigen lassen (LED-Ansteuerung mal außen vor).
Gast #2438932
Lesenswert?

Der Rechenaufwand für die FFT ist gar nicht so groß - 20 mal den 
Görtzelalgorithmus laufen zu lassen könnte ähnlich viel Rechnzeit 
brauchen. Einen Unterschied gibt es aber im Aufwand für den 
Programm-code und Speicherbedarf.

Bei den LEDs kommt es darauf an wie viele LEDs gleichzeitig an sind. 
Wenn man da nur je Kanal 1-2 LED gleichzeitig aktiv hat geht das noch.

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren