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:
-
Vorbereitung_Seite1.jpg
530 KB -
Vorbereitung_Seite2.jpg
550 KB
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.
>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;)
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.
>Ich würde einen von den neuen STM32F4 nehmen
Wer einen Hammer hat sieht als Lösung nur Nägel;)
Oh man.
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).
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.
Schau Dir doch mal den MAX7221 an. Ist ein Multiplex Baustein für LED welcher über SPI Bus angesteuert wird. Kann 64 LED unabhängig schalten, dimmen ect. Denke wenn Du da ein paar nimmst, brauchst auch die 40 PortPins nicht mehr :o) Grüessli
Atmega8 + 2x 74HC595 reicht völlig aus. Ich denke ein ARM ist hier einfach nur ein Overkill. Mit elmchans fft Routinen kommt man auf knapp 4ms für 64pts (16Mhz). Der ADC schafft locker 8bit bei 40kHz.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.