Hallo zusammen, Erstmal großes Lob an die Community, ich lese jetzt seit einer Weile immer mal was und bin immer auf interessante Sachen gestoßen. Jetzt zu meiner Projektidee: Ich will einen Spektrum Analyser mit dem LPC2124 realisieren. Eingabe soll per Mikrofon erfolgen. Ausgabe in einer 3D LED Matrix, die 3. Dimension wird die Zeit, damit will ich also eine laufende Spektrumsanzeige erreichen was hoffentlich cool aussieht :) Der LPC sollte meiner Meinung nach genug Speicher bieten und auch genug Rechenleistung, und ich will etwas mit ARM machen. Als Anfänger stell ich da folgende Fragen: ist die FFT geeignet wenn ich aufgrund der vielen benötigten LEDs nur 8 Berechnungspunkte nehmen will? (Insgesamt dachte ich an eine 8x6x6 (FrequenzxBetragxZeitpunkt) Matrix) Ist der Bausatz von Conrad (http://www1.conrad.de/fas6/fh.php?fh_params=fh_search%3Dmikrofonvorverst%25c3%25a4rker%26fh_secondid%3Db2c197688%26fh_lister_pos%3D6%26fh_location%3D%252f%252fb2cconrad_de_b2c%252fde_DE%252f%2524s%253dmikrofonvorverst%255cu00e4rker%26fh_eds%3D%25c3%259f%26fh_refview%3Dsearch&fh_host=http://www1.conrad.de&fh_session=/scripts/wgate/zcop_b2c/~flN0YXRlPTQwMDQ4NzU3NTE=?&fh_pic_url=//images.conrad.de&layout=b2c&fsm_host=&fsm_insertkz=) zur Ansteuerung des ADC geeignet? Würdet ihr mir als Einsteiger das Developer Board von Olimex empfehlen oder gibts es bessere? Viele Grüße Johann
Na ich wollte einfach die einmal berechneten Spektren in den Speicher legen. Diese werden dann per Schieberegister oder so weitergereicht in die 3. Dimension. Also wenn ich beispielsweise von vorne auf den LED Würfel schaue, sehe ich Spektrum(t_jetzt) in der 1. Reihe, Spektrum(t_jetzt-1) in der 2. Reihe usw.
Ich habe jetzt hier ein Mikrofon mit einem Frequenzspektrum von 20Hz bis 20KHz (-10dB bei 20kHz). Wenn ich da also mit 50KHz abtaste, sollte ich ohne Anti-Aliasing-Filter auskommen. Aber ich werd aktuell aus dem ADC-Teil im Datenblatt des STM32 nicht schlau, da ist die Rede von einer f_ADC, welches für weitere Angaben mit 14MHz angenommen wird und dann gibt es noch f_S, die Samplingfrequenz. Die müsste ich mir ja auf die 50KHz einstellen, aber was ist mit der f_ADC? Viele Grüße Johann
Hallo Johann, das Stichwort für dich ist Spektrogramm. Für gewöhlich analysiert man das Signal überlappend: 1.) ++++++++-------- 2.) --++++++++------ 3.) ----++++++++---- 4.) ------++++++++-- . . Damit geht man Blockeffekten weitgehend aus dem Weg. Problematisch ist deine geringe Blocklänge, die Granularität ist da eher mäßig - aber für deine Zwecke vllt ausreichend. Je größer die Überlappung desto mehr und schneller muss gerechnet werden - 50% der Blocklänge sollten genügen. Ich habe sowas mal in Verbindung mit MATLAB/Blackfin auf dem Rechner als Wasserfalldiagram darstellen lassen und habe dabei 256 Punkte benutzt.
Sehe ich das richtig, dass du mit der LED-Matrix folgende Achsen sind: Betrag, Frequenz und Zeit? Dann kommt für dich ja nicht die Wasserfalldarstellung in frage, da du pro Punkt (also je Spektrallinie) ja nicht den Betrag in form einer Helligkeit bzw. Farbe ausgibst. Welches Datenblatt verwendest du? Ich sehe immer nur f_ADC und t_s, wobei t_s jedoch mit 1/f_ADC angegeben ist,
Timmo H. wrote: > Dann kommt für dich ja nicht die Wasserfalldarstellung in frage, > da du pro Punkt (also je Spektrallinie) ja nicht den Betrag in form > einer Helligkeit bzw. Farbe ausgibst. Ob diese Dimension nun einen Farbwert oder die Höhe eines Balkens repräsentiert ist sekundär.
>Ob diese Dimension nun einen Farbwert oder die Höhe eines Balkens >repräsentiert ist sekundär. Richtig, aber dann bezeichnet man es eigentlich nicht mehr als Spektrogramm.
Zum Thema Spektrogramm: Da habe ich bei Wikipedia eine mittelmäßige Erläuterung gefunden (http://de.wikipedia.org/wiki/Spektrogramm) aber das ist das was ich mir vorstelle. Nur verstehe ich noch nicht, was du mit Blockeffekten meinst weshalb man überlagernd analysieren sollte? Wenn ich mit einer Frequenz von sagen wir 5Hz mein Audiosignal per FFT analysiere und das entsprechend mit 5Hz durch den LED-Würfel schiebe sollte das doch auch gehen? Zum Thema f_ADC: Ich habe nochmal das gesamte Datenblatt angehängt. Wie gesagt ist mir nicht ganz klar, welche Frequenz was bewirkt. Meine Vermutung ist das t_s und damit f_s die Abtastfrequenz darstellen aber was ist f_ADC? Viele Grüße Johann
Hi, f_ADC ist offensichtlich eine Frequenz, welche der ADC intern benötigt. Der ADC arbeitet laut Refernce Manual der STM32-Serie mit sukzessiver Approximation (siehe z.B. Wikipedia) und benötigt zur "Berechnung" eines Datenwortes einige Takte - f_ADC wird wohl die Clock sein, die diesen internen "Wandlertakt" vorgibt. Die FFT halte ich für Dein Vorhaben nicht für optimal -- sie hat per Defintion eine lineare Frequenzachse, und das ist nichts, was man bei einem Spektrum-Analyzer im Audio-Bereich haben will. Aus dem Bauch heraus (d.h. ohne groß überlegt zu haben, ob es effizientere Methoden gibt) würde ich folgendes machen: - Das digitalisierte Audio-Signal parallel durch 8 Bandpässe schicken, welche jeweils nur den zu messenden Frequenzbereich durchlassen. - Die Leistung jedes der 8 Ausgangssignale berechnen - Die Leistung logarithmieren - Das Ergebnis evtl. entsprechend skalieren, um bei der begrenzten Anzahl von LEDs auch ein "interessantes" Blinken hinzubekommen. Gruss FL
Ahja und richtig, die Achsen sind Frequenz, Betrag und Zeit.... Viele Grüße Johann
Ah besten Dank für den Hinweis bzgl. sukzessiver Approximation, damit ist mir das jetzt klar. Also bei der Signalauswertung lasse ich mich gerne belehren, davon habe ich keine praktischen Kenntnisse. Mir ist halt aus div. Grundlagenvorlesungen nur die FFT bekannt... Dein Ansatz mit den digitalen Bandpassfiltern klingt auch gut, hat noch jemand andere/bessere Ideen? Viele Grüße Johann
Also ich denke der ARM sollte massig genug Leistung haben für eine FFT. Da mit sicherheit entsprechende Implementierungen zu finden sind sollte das schneller gehen als noch extra Bandpassfilter zu machen, vorallem ist es flexibler. Der Typ hats auch mit nem ATmega geschafft (sie Videos). http://elm-chan.org/works/akilcd/report_e.html
Hm, ich vermute, er will ein logarithmisches Frequenzband für seine 8 LEDs haben, z.B. folgende Frequenzbereiche: LED 1 2 3 4 5 6 7 8 ob.Freq. 150 300 600 1200 2400 4800 9600 20000 (ob.Freq.: obere Grenzfrequenz des Bandes für die LED). Also braucht er eine Frequenzauflösung von 150 Hz. Bei einer Abtastrate von 50 kHz gibt das 50000/150 eine "333 Punkte Fourier-Transformation" => 512 Pkte. FFT ist Minimum. Die 512 Punkte müssten dann noch irgendwie interpoliert werden, um in die Frequenz-Bänder "zu passen". Dann muss er aufpassen, dass die FFT genügend signifikante Bits liefert, denn das Ergebnis muss ja noch logarithmiert werden (bei zu wenig signifkanten Bits hat er sonst bei leisen Signalen nur noch "Rauschen" auf den LEDs). Ich will nicht behaupten, dass der ARM das nicht schafft -- für mich persönlich wären die Bandpässe aber die einfachere und intuitivere Lösung. Wenn's ein Projekt zum Ausprobieren und Lernen ist, würde ich einfach mal mit der Herangehensweise starten, die man selbst für intuitiv richtig hält -- man lernt einfach durch nichts mehr, als wenn man die Probleme selber lösen muss ;-)
Hmm, haben will ich nicht unbedingt ein logarithmisches Frequenzband, aber wenn man es so machen sollte dann schon :) Ich habe eben mal nach paar typischen Spektren von Musik gesucht, aber keine mit logarithmischer Frequenzdarstellung gefunden. Gibt es denn so typische Frequenzbereiche für Musik dass das sinnvoll wäre? Aber der Punkt mit den Bändern ist natürlich richtig. Es wird ja schlecht reichen, wenn ich mir 8 Frequenzpunkte suche um die direkt per FFT-Ergebniss auf die LEDs zu bringen. Da würde ich dann eher eben mit beispielsweise 150Hz Auflösung abtasten und dann mir Bänderbereiche definieren, in welche ich dann die gemittelte Leistung von vielen Abtastpunkten aus dem Frequenzbereich hineinbringe. Da kann ich ja dann immer noch experimentieren mit linearer oder logarithmischer Bandaufteilung. Ja es ist ein Projekt zum Ausprobieren, daher würde ich eben intuitiv die FFT nutzen wollen. Inzwischen habe auch entgegen dem ersten Posting einen Cortex M3 zum implementieren hier, der sollte auch noch etwas effektiver sein als der LPC. Viele Grüße Johann
Also Musik liegt üblicher weise von 100-16000 Hz, kannst ja auch bei Winamp sehen oder mit AudaCity dir mal das Spektrogramm ausgeben lassen. Logarithmische Frequenzskalierung ist bei Musik nicht unbedingt so sinnvoll. Bei der Analyse von Filtern oder so hingegen schon.
Ich sehe gerade dass AudaCity das gar nicht kann. Aber Spektrum geht. Nimm nicht unbedingt ein mp3 File mit 128 kbit/s, da wird meist radikal bei > 16kHz angeschnitten. Da sich die meisten Töne jedoch bei < 16kHz befinden würde ich auch nur diese darstellen. Mp3 schneidet ja die höheren Frequenzen bei niedriger Bitrate eben ab, weil Menschen ab 30-35 eh nichts mehr über 16-17 kHz hören. Auch für junge Menschen ist es in einem Lied kaum wahrnehmbar wenn die hohen Töne fehlen. UKW Radio geht übrigens nur bis 15 kHz.
Ist schon richtig was FL sagt, für gewöhnlich spielt sich bei Musik das meisste in den unteren Bändern ab. Über Bandpässe würde ich da mal nachdenken. Ferner gibt es Korrekturfunktionen die dem menschlichen Hörempfinden gerecht werden, Stichwort dBA etc. Das ändert natürlich nichts an der Frequenzauflösung. Was ich mit Blockartefakten meine: Analysiert man überlappend, dann bekommt man die zeitliche Veränderung besser aufgelöst, die Übergänge sind 'weicher'. Wird bei deiner Anwendung wahrscheinlich nicht so von Bedeutung sein, aber wenn du MATLAB hast probier es einfach mal aus.
Ahja ok dann werde ich mich also auf 0-16KHz beschränken... Das mit der Frequenzbewertung klingt ganz interessant. Da kann ich ja einfach etwas experimentieren damit, die Bewertungskurven kann ich ja super nach der logarithmierten Leistungsberechnung der FFT-Ergebnisse einrechnen. Erstmal muss ich mir die Code-Basis schaffen (Ansteuerung ADC, Ausgabe von Messwerten vorerst per UART) und dann schauen wir weiter. Besten Danke erstmal, Viele Grüße Johann
Hallo nochmal, zur Veranschaulichung der Sinnhaftigkeit einer logarithmischen Frequenzauflösung: Tonhöhen von Musikinstrumenten / Gesang etc. werden logarithmisch wahrgenommen -- die fundamentale Größe zur Bezeichnung von Tonhöhen sind die Oktaven (und dann feiner unterteilt als Sekunde, Terz, ...). Eine Oktave ist aber nichts anderes als eine Frequenzverdopplung. Also: Der Kammerton a' hat 440 Hz, eine Oktave höher sind 880 Hz, dann folgen 1760, 3520, 7400, 14800 (, 29600, ...) Hz. Wenn Du nun linear skalierst, hast Du die Hälfte Deiner FFT-Punkte und/oder die Hälfte Deiner LEDs für das Frequenzband 10000-20000 Hz verschenkt -- einem Frequenzbereich, welcher gerade einmal eine Oktave umfasst und in dem sich nicht allzuviel interessantes abspielt. Bist Du dagegen logarithmisch unterwegs, wird dieser Bereich nur von einer LED abgedeckt, und Du hast genügend LEDs für die anderen Oktaven übrig. Dass die wenigsten Programme logarithmische Frequenzskalen verwenden dürfte genau den Grund haben, den man auch in diesem Thread sieht: Es gibt fertige FFTs, und wenn ich genügend Rechenleistung habe, lasse ich halt eine FFT mit genügend Punkten auf das Signal los, so dass ich zwar im oberen Frequenzbereich eine unnütz feine Auflösung habe, aber im unteren Frequenzbereich trotzdem noch genügend Punkte habe. Wenn Du aber "ernsthafte" grafische Equalizer siehst, so sind hier die Frequenzbänder immer logarithmisch -- alles andere wäre für Audio-Anwendungen absolut sinnlos. Gruß Frank
Aha ok, bei solchen Sachen wie Oktaven habe ich nicht aufgepasst in der Schule ;) Gut da werde ich es so angehen, dass ich den Cortex erstmal mit ner 512er oder 1024er FFT quäle. Mal schauen was da machbar ist. Danach erstell ich mir 8 logarithmische Bänder in welchen ich die Amplitudenwerte mittle. Dann logarithmiere und skaliere ich die Amplituden... Du hast Recht, Bandpässe erscheinen da intuitiver aber andererseits will ich mal diese FFT probieren... Viele Grüße Johann
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.