Moin, Es taucht ja immer wieder mal die Frage auf, wie man ein LED-Grab als lustigen Spektrumsanalysator mit einem moeglichst schwachbruestigen µC basteln kann. Oft folgt ein Hinweis auf das Projekt auf elm-chan.org Nun glaub' ich aber, dass eine Fouriertransformation fuer sowas nicht besonders geeignet ist, weil da die Analysefrequenzen linear ueber's Band verteilt sind und nicht wie's gehoermaessig schoen waere in z.B. Oktaven oder Terzen, also logarithmisch. Auch bei tiefen Frequenzen wirds problematisch, bzw. die Anzahl der Samples ueber die FF transformiert werden muss, steigt an, und damit auch die Rechenlast. Im uebrigen ist das mit der FFT ein alter Hut, vielleicht geht's auch anders: Meine Idee: Ich nehm' 2 Filter - einen Hochpass und einen Tiefpass und teile damit das zu analysierende Frequenzband in 2 Haelften auf. Bei einer Abtastfrequenz vom zb. 32kHz in einen Bereich 0..8kHz und einen Bereich 8..16kHz. Beide Signale kann ich dann 1:2 unterabtasten, weil sie ja nur noch die halbe Bandbreite gegenueber dem Originalsignal haben (Jaja, weil mein Filter natuerlich nicht ideal ist, verletze ich das Abtasttheorem ein wenig. Is mir aber wegen dem dadurch gesparten Rechenaufwand wurscht.) Vom Hochpasssignal integrier' ich die Leistung ein weilchen auf, logarithmiere das dann, etc.bla -> geb's irgendwan an den LED-Bar fuer die hoechste Frequenz aus. Das Tiefpasssignal schmeiss' ich erneut in eine identische Hoch/Tiefpass-Kombi. Teile es also auch wieder: 0..4kHz und 4..8kHz. Und mache eine 1:2 Unterabtastung. Das Hochpasssignal (4..8kHz) -> kommt an den LED-Bar fuer die zweithoechste Frequenz; das Tiefpasssignal - der aufmerksame Mitleser ahnt es evtl. - kommt wieder in eine Hoch/Tiefpasskombi..bla...Unterabtastung...blupp...usw. Bis ich irgendwann mal keinen Bock mehr habe und auch das letzte Signal aus dem Tiefpass aufsummiere und an den LED-Bar ganz links fuer die Baesse geb'. Fuer die ganze Filterei bedeutet das, dass ich nur am Anfang eine Hoch/Tiefpasskombi hab', die mit der Originalsamplefrequenz laeuft. Danach einen mit der halben, der viertel, achtel, usw. Jetzt gilt aber: 1 + 1/2 + 1/4 + 1/8 + ...= fast 2 D.h. mit dem doppelten Rechenaufwand wie fuer 1x Hoch/Tiefpassfiltern kann ich beliebig viele weiter Hoch/Tiefpasskombis laufen lassen. -> Der Rechenaufwand bleibt ueberschaubar. Weiterhin kann man fuer Hoch und Tiefpass viele Berechnungen gemeinsam anstellen. Und bei Halbbandfiltern kann man die Koeffizienten noch so waehlen, dass viele Null sind. Multiplikationen mit Null sind auch angenehm schnell :-D Leider hab' ich das alles natuerlich nicht auf einer richtigen Hardware getestet, sondern nur mal aufm PC zusammengekloppt. Ist also noch etwas unausgegoren, aber vielleicht hat ja jemand Bock, das mal auf echter HW ans Laufen zu bringen. Das C Programm liefert als Ausgabe lediglich 8 Zahlen, die die Anzahl erleuchteter LEDs bei entsprechendem Eingangssignal darstellen. Auf den Bildern sieht man die Frequenzgaenge des Prototypen-Hoch- und Tiefpass bei linearer Frequenzachse, sowie uebereinander geplottet die Frequenzgaenge der gesamten Filterei mit log. Frequenzachse. Wem das noch zu simpel ist: Dieses Verfahren muesste auch mit feineren Abstufungen als Oktaven gehen, dann werden aber die Hoch/Tiefpassfilter nicht mehr so schoen simpel und man braucht auch mehrere davon, weil dann die Unterabtastungen nicht mehr 1:2 sind, sondern eher krumme Faktoren, also z.b. 3:4 oder so.... Gruss WK
Angehängte Dateien:
-
filterproto_lp.png
2,9 KB -
filterproto_hp.png
2,8 KB -
filterbank.png
5,2 KB
derguteweka schrieb: > Nun glaub' ich aber, dass eine Fouriertransformation > fuer sowas nicht besonders geeignet ist, weil da die > Analysefrequenzen linear ueber's Band verteilt sind > und nicht wie's gehoermaessig schoen waere in z.B. > Oktaven oder Terzen, also logarithmisch. [...] > > Meine Idee: Ich nehm' 2 Filter - einen Hochpass und > einen Tiefpass und teile damit das zu analysierende > Frequenzband in 2 Haelften auf. Sehr hübsch. Das Prinzip erinnert mich irgendwie an die Wavelet- Transformation... Eine Anmerkung in Frageform: Wenn die Filter linearphasig sind (was sie ja wohl sind), könnte man dann nicht den Hochpass einsparen, weil HP = Original - TP gilt?
Moin, Possetitjel schrieb: > könnte man dann nicht den > Hochpass einsparen, weil HP = Original - TP gilt? Das mach' ich mehr oder weniger versteckt hier:
1 | lp=(s+f->buf[7]*128)/256; |
2 | hp=(s-f->buf[7]*128)/256; |
Das "Original" ist zu dem Zeitpunkt ja f->buf[7]. Gruss WK
Hi, derguteweka, ich schätze Personen wie Dich, die vor ungewöhnlichen Gedanken keine Angst haben wie einst der Vatikan vor Galilei. im ersten Moment klang Deine Idee interessant - bis zur Frage: Was zeigt die LED-Zeile wohl bei einem Doppeltonsignal an? Der Charme der 64-Kanal FFT ist ja, dass sie selbst 64 Töne, die in ihrem jeweiligen Segment gerade mittig kommen, getrennt voneinander nach ihrem Pegel bewertet. Wenn ich auf diese Parallelität verzichte, warum reicht dann nicht auch einfach ein Frequenzzähler und man kann auf die Filter verzichten? Ciao Wolfgang Horn
Moin, Die Filter arbeiten schon auch parallel. Ist nicht so wie bei einem Frequenzzaehler, der dann z.B. nur die Nulldurchgaenge des Signals analysieren wuerde. Wenn ich mal bei einer Samplingfrequenz von 32 kHz bleib', dann koennte ich z.B. ein Signal mit 2 Toenen (6kHz, 12kHz) sauber trennen. Das waeren dann die beiden obersten Filter. Oder ein Signal (3kHz, 10Khz) wuerde dann das erste und 3. Filter "triggern". Ein Signal (11kHz, 14kHz) kann ich nicht trennen, weil mein erster Hochpass alles ab 8kHz durchlaesst. Wenn ich mein olles .c File mal noch durch dieses 2Ton-Testsignal ergaenze:
1 | sample=(int)(16384.0*(sin(i/192.0*M_PI*2.0)+sin(i/64.0*M_PI*2.0))); |
Dann krieg ich diese Ausgabe: 0 0 0 0 2 2 4 0 Das wuerde dann bedeuten, dass vom LED-Bar fuer das zweittiefste Filter 4 LEDs leuchten und bei beiden naechsthoeheren LED-Bars je 2 LEDs. Der erste, tiefere Ton liegt genau in der Bandmitte eines Filters, der 2. Ton mit (Fsample/64) exakt an der Trennfrequenz einer Hoch/Tiefpass-Kombi, was dann bei beiden Filtern zu einem Ansprechen mit -6dB fuehrt. Jede LED mehr in einem Bar bedeutet 3dB - sollte also ungefaehr passen. Gruss WK
Hi, derguteweka,
> Die Filter arbeiten schon auch parallel.
Schon klar.
Eine mögliche Anwendung könnte die Analyse von Lager- und
Getriebegeräuschen sein. Da wäre ein Alarmsignal, wenn sich zum Summen
des Lüfters eine Subharmonische gesellt.
Ordentliche Wartumgstechniker laufen mindestens einmal täglich alle
19"-Schränke ab, ob in einem davon ein Lüfter kreischt. Dies Kreischen
lässt sich mit Deinem Dings wohl auch aus der Ferne überwachen.
Wenn Du zeigen kannst, dass Dein Dingens wirtschaftlicher ist als die
aktuelle "best solution", dann wäre das interessant.
Ciao
Wolfgang Horn
Frequenzanalysen lassen sich auf die Schnelle auch mit einer Fouriertransformation "für Arme" machen: Dabei werden statt SIN/COS einfach Rechtecksignale (das 2. um 90 Grad Phasenvers.) verwendet. Ein Rechtecksignal hat ja die FT (0,1,0,1/3,0,1/5,..), damit erhält man über die Frequenzen 0,1,2,3,... eine Dreiecksmatrix. Diese lässt sich sehr einfach invertieren bzw. es lässt sich sogar die Inverse geschlossen und einfach beschreiben. Damit kann man dann eine SpeudoFFT per Rechteckkurven in eine FFT und umgekehrt rechnen. Die "Rechteck-FT" ist im Prinzip nichts anderes als Addition und Subtracktion von Wertereihen, d.h. sehr einfach auf kleinsten uCs implementierbar. Für deine "logaritmische FT" kann man diesen Ansatz auch anpassen. Rechne einfach eine Speudo-FT mit Freq = 1,3,5 oder = 1.3.5.7 etc. und bestimme daraus die FT mit Freq = 1. Das wird für alle gewünschten Frequenzen wiederholt.
Kling für mich putzig, Siggi. Kannst du für deinen Gedankengang ein C-Programm entwerfen(posten?
Edit: Kling für mich putzig, Sigi. Kannst du für deinen Gedankengang ein C-Programm entwerfen/posten?
derguteweka schrieb: > Meine Idee Oktavfilter, Terzfilter, schon erfunden. Auch die genannte Wavelet wäre möglich: https://www.head-acoustics.de/downloads/de/application_notes/FFT_Wavelet_Terzpegel_d.pdf
Moin, Hm, ja, nee - da hab' ich mich nicht klar genug ausgedrueckt. Das Dingens von mir ist nicht fuer "ernsthafte" Anwendungen wie irgendwelche genaueren Geraeuschanalysen gedacht. Fuer sowas ist Fourier das Ding der Wahl. Fuer sowas wird man wohl hoffentlich auch mehr als eine so schwaechliche CPU nehmen, die FFT nur mit Tricks und Faxen kann. Ich hab' in erster Linie die Leute im Sinn, die eine lustige Anhaeufung von LEDs haben wollen, die abhaengig vom Krach von Musik vor sich blinkert. Also dieses Klientel (ohne Anspruch auf Vollstaendigkeit, in keiner besonderen Reihenfolge): Beitrag "10 Kanal Audioanalyzer - Bitte drüberschauen" Beitrag "Audio Analyzer" Beitrag "led equalizer" Beitrag "Musik-LED-Equalizer" So "richtig simpel" wird der ganze Filterquatsch bei mir eben prinzipbedingt nur, wenn die einzelnen Bandfilterausgaenge genau eine Oktave Abstand zueinander haben. Das von mir ist ein Spezialfall eines Polyphasenfilters, bei dem genau durch die 2:1 Dezimation in Tateinheit mit Halbbandfilterung sich viel vereinfacht. Ein weitere "schoener" Effekt ist auch der, dass bei meinem Verfahren im Gegensatz zur FFT eine Analyse bei sehr tiefen Frequenzen die Rechenzeit kaum mehr nach oben treibt, weil die Filter fuer tiefe Frequenzen nur noch ein stark unterabgetastetes Signal kriegen und daher "selten" rechnen muessen. Gruss WK
Hat das eigentlich mal jemand mit dem Görtzel Algorithmus versucht? https://de.m.wikipedia.org/wiki/Goertzel-Algorithmus Für wenige LEDs könnte sich das doch vielleicht lohnen. Ich hab davon aber ehrlich gesagt keine Ahnung...
Angehängte Dateien:
-
plot.svg
79 KB
Als neugieriger Mensch habe ich einen 10sekündigen exp. Sinus-Sweep von 200Hz bis 20kHz mit sample rate 22050Hz durch deinen Spectrum-Analyzer geschickt.
Moin, Sieht ja bilderbuchmessig aus - schoener haett ichs nicht zeichnen koennen :) nur warum im untersten Kanal eine LED mehr leuchtet, ist mir grad nicht klar - ich hoff' mal, dass es nur Rundungsfehler sind. Gruss WK
Arbeitet der Algorithmus auch in Echtzeit und wenn ja bei welcher Samplerate? Im Moment verwurstet der Algorithmus ja einen Datenblock, wenn man das ganze kontinuierlich machen wollte, müßte man ja die Audio-Samples in kleine Intervalle zerteilen. Welche Intervallgröße wäre da sinnvoll?
Moin, Julian B. schrieb: > Arbeitet der Algorithmus auch in Echtzeit und wenn ja bei welcher > Samplerate? Ganz entschieden: Ja, natuerlich. Bei jeder Samplerate. Und wenn nicht, ist deine Hardware halt zu langsam. Tut mir leid, genauer weiss ich's momentan selber nicht. Es kommt halt auf den Prozessor an, und was der sonst noch so zu tun hat... Die Samples werden einzeln an den Analysator "verfuettert". "Unschoen" ist an dem Ding, dass es unterschiedlich lange braucht, bis ein Sample verwurstet ist, weil eben jedes Filter jedes 2. Sample an's naechste Filter weitergibt; d.h. jedes 128. Sample durchlaeuft dann 7 Filter und braucht damit die 7fache Rechenzeit, wie das Sample vorher oder das Sample hinterher. Die durchschnittliche Rechenzeit fuer jedes Sample ist aber nur "2*Filter-Rechenzeit - einbisschenwas". OK, fuer's Quadrieren, logarithmieren, etc. kommt dann noch was dazu. Gruss WK
Moin, Angesichts dieses Beitrags und dessen hochdiskussionswuerdigen 1. Satzes: Beitrag "Re: ADSP-21498, was für ein Compiler am besten?" kam in mir doch die Idee auf, dass man das Verfahren der Filterbank, das ich hier beschrub, doch hoechstwahrscheinlich mit aehnlichem Rechenaufwand auch rueckwaerts verwenden kann, um verschiedene unterabgetastete Signale wieder zu einem hoeherabgetasteten Signal zusammenzusetzen. Dann koennte man doch eine wie von mir hier beschriebene Analysefilterbank nehmen, deren Ausgaenge jeweils mit einer von aussen einstellbaren Konstanten (z.b. von 1/8...8; entsprechend -18..+18dB) multiplizieren und das Ergebnis von einer umgekehrt aufgebauten "Synthesefilterbank" wieder zu einem Signal mit der Eingangsdatenrate "aufaddieren". Und schon haette man einen Equalizer, der mit deutlich weniger Rechenbumms auskommen wuerde, wie wenn man stumpf einen Haufen einstellbarer Bandpaesse/sperren oder lange FIR-Filter einsetzen wuerde... Denn Irrsinn koennte man noch weiter treiben und mit einer 2. Analysefilterbank mit nachgeschalteter "Leistungsmessung", also so wie fuer den "Spektrumsanalysator", die einstellbaren Konstanten fuer die Multiplikation der Samples aus der 1. Filterbank errechnen. Dann wieder synthetisieren, et voilà - der Vocoder ist fertig. Fuer Sprache werden dann die Oktavfilter nicht ausreichen, also wird man dann fuer die Analyse- und Synthesefilter nicht mit 1/2 Unterabtastung rechnen, sondern eher so irgendwas n/(n+1),also vielleicht 3/4 oder 7/8 oder so... Jetzt halt' ich mich aber nicht fuer so genial, dass ich da als Erster draufkomm' - hat irgendwer in den Weiten des www oder sonstwo dazu evtl. schonmal mal was gefunden? Gruss WK
derguteweka schrieb: > Und bei Halbbandfiltern kann man die Koeffizienten noch so wählen, dass > viele Null sind. Multiplikationen mit Null sind auch angenehm schnell Das ist richtig, allerdings ist ein so getuntes Filter weniger selektiv - trennt also die Fälle des Vorhandenseins von Frequenzen und Nichtvorhandensein nicht gut auf. Für den Fall des gewünschten Tötens der Frequenzen ist das ok. Will man eine spezifische Frequenz aus einem Spektrum isolieren, muss man umgekehrt vorgehen und die Abtastung so vornehmen, dass die Koeffizienten möglichst groß sind. Wenn man das richtig fett aufziehen möchte, kann man eine kaskadierte Filtergruppe aufbauen, die mit jeweils einem sampler von 185/196 arbeitet und so von Note zu Note übersetzt. Für einen einfache SA im Bereich Audio würde ich aber immer IIR-Filter nehmen. Sind schnell genug fürs Auge. derguteweka schrieb: > nur warum im untersten Kanal eine LED mehr leuchtet, ist mir grad nicht > klar - ich hoff' mal, dass es nur Rundungsfehler sind. Steckt womöglich noch der Gleichanteil mit drin. Ich baue die Filter immer so, dass es einen LOCUT gibt, der unterhalb von 10Hz abschneidet und das unterste Frequenzband damit ebenfalls geschlossen ist. Dasselbe oben bei den Höhen.
Angehängte Dateien:
-
led-analyzer.jpg
22 KB
Moin, Sieht garnicht mal so ganz hoffnungslos aus; hab aus rumliegenden Leichenteilen und Lochraster mal was zusammengenaeht... Auf nem atmega16 mit 16MHz laeuft der Analyzer locker; hab' nicht den Eindruck, dass die Rechenzeit knapp wird. Display sind 10 Bars mit je 9 LEDs - die sind etwas funzelig, da nicht mehr ganz taufrisch (die hab' ich noch bei Radio-RIM in der Bayerstr.25 gekauft) und ich die Ausgangstreiber des atmega nicht zu sehr quaelen will. Anzeige je LED sollten ungefaehr 3dB Schritte sein - also fuer jeden Balken 27dB Anzeigeumfang; Multiplexfrequenz ist 200Hz. Der ADC sampled (8 bit) Audio mit 32kHz; damit zeigt der LED-Bar ganz rechts alles zwischen 8..16kHz an; der 2.rechte Bar dann von 4..8kHz; usw. bis ganz links von ca. 16..32Hz. FIR Filter (14. Ordnung, das aus dem ersten Post) laeuft/laufen mit 8 bit signed Samples und 8bit Parametern; Akku ist 16 bit. Summe der Quadrate aus dem Hochpass ist 24bit. Ans naechste Filter gehen immer die 8MSBs aus dem Akku des Vorhergehenden. Software braucht momentan ca. 1kByte Flash, 256Byte Eeprom (fuer eine Tabelle zur LED Ansteuerung). Im RAM gibts einen 256 byte Fifo fuer die Samples aus dem ADC; jeder Filter braucht 15bytes; dazu jeweils 3Bytes fuer die Summe der Quadrate, 1 Byte fuer die Anzeige und 1 Byte Timer, um die Spitzenwertanzeige nach einer Weile abfallen zu lassen. Also insgesamt 10*(15+5)=200bytes fuer die "Signalverarbeitung". Dann halt noch bisschen Stack, 3 weitere Bytes fuer einen Zaehler, der zaehlt und eine weitere LED blinken laesst, wenn grad nix zu filtern ist, etc. ...more2come... Gruss WK
Moin, Noch 2 Bilder, alle moeglichen Sourcefiles und ein verwackeltes Filmchen vom Betrieb. Ich hab's mal gezippt, weiss nicht, ob mp4 hier hochladbar ist. Schaltbild muesst' ich erst noch malen. Ist mein erstes AVR-Programm, kann sein, dass das nicht alles immer schulbuchmaessig ist. Gruss WK
derguteweka schrieb: > Leider hab' ich das alles natuerlich nicht auf einer richtigen Hardware > getestet, sondern nur mal aufm PC zusammengekloppt. Ich bin auch gerade wieder mit dem Thema konfrontiert und habe mir das mal für einen FPGA angesehen. Wenn man eine eng abgestufte Terz-FFT haben möchte, ist der Vorteil der geringeren Zahl der Berechungsstufen nur sehr theoretisch gegeben. Die FFT lässt sich parallel sehr effektiv implementieren und einen fertigen kompakten Core zu nehmen und bei den höheren Frequenzen durch Zusammenfassen die Zahl der Frequenzen zu limitieren ist nur geringfügig aufwändiger, aber sehr viel genauer, als das fortgesetzte Halbbandfitern über die deizierten Frequenzen. Bei einem DSP ist das natürlich anders!
Moin, Jürgen S. schrieb: > derguteweka schrieb: >> Leider hab' ich das alles natuerlich nicht auf einer richtigen Hardware >> getestet, sondern nur mal aufm PC zusammengekloppt. > Was kuemmert mich mein dummes Geschwaetz von gestern? Derweilen gibts ja "richtige" Hardware :-) > Ich bin auch gerade wieder mit dem Thema konfrontiert und habe mir das > mal für einen FPGA angesehen. Wenn man eine eng abgestufte Terz-FFT > haben möchte, ist der Vorteil der geringeren Zahl der Berechungsstufen > nur sehr theoretisch gegeben. Die FFT lässt sich parallel sehr effektiv > implementieren und einen fertigen kompakten Core zu nehmen und bei den > höheren Frequenzen durch Zusammenfassen die Zahl der Frequenzen zu > limitieren ist nur geringfügig aufwändiger, aber sehr viel genauer, als > das fortgesetzte Halbbandfitern über die deizierten Frequenzen. > > Bei einem DSP ist das natürlich anders! Auf einem FPGA kann man natuerlich ganz anders 'rangehen als auf einem 8bit-Prozessor. Das war ja auch nie mein Ansatz. Mir gings drum, mal zu gucken, was eben so mit einem bastelfreundlichen 8bit µC so an DSP fuer Arme geht...Um eben so Geschichten, wie sie z.B. hier durchscheinen: Beitrag "Negative Spannung selbst erzeugen" mit etwas weniger Analoghardware aufbauen zu koennen. Achja - Schaltbild ist fertig. Jetzt koennte eigentlich das "software" aus dem Threadtitel entfernt werden... Gruss WK
Moin, Bisschen Obacht geben: Mir ist die Software mittlerweile ein paarmal nach einiger Zeit haengengeblieben. Querverseilung: Beitrag "AVR: Timergesteuerter ADC Interrupt klemmt manchmal" Sieht erstmal so aus, als ob der Interrupthandler dann nicht mehr angesprungen wird. Ist bisschen doof, weil dann der Multiplex des Displays nicht mehr laeuft und einzelne LEDs mehr Strom kriegen koennen als erwartet und vom atmega gerne hergegeben. Aber als Nebeneffekt beim Debuggen bin ich mir jetzt ziemlich sicher, dass die Software, wenn sie normal laeuft, die CPU zu ca. 40% auslastet. Gruss WK
Dergute W. schrieb: > Jetzt halt' ich mich aber nicht fuer so genial, dass ich da als Erster > draufkomm' - hat irgendwer in den Weiten des www oder sonstwo dazu evtl. > schonmal mal was gefunden? In der Bild-/Videoverarbeitung gib es sowas schon länger: https://en.m.wikipedia.org/wiki/Pyramid_(image_processing) Da findest du auch weiterführendes (multiresolution, scale-space)
Das ist auch unter dem Begriff Filterkaskade bekannt. In der Audiotechnik benutzt man das sehr oft, um Rechenzeit zu sparen. Leider zum Nachteil der Qualität, weil bei jder Filterung z.B. HBF Artefakte reinkommen.
In dem Zusammenhang ist evtl. auch das Haar-Wavelet interessant: https://de.wikipedia.org/wiki/Haar-Wavelet Im Prinzip handelt es sich um eine "FFT mit Rechteckesignal", wie oben auch erwähnt. Lässt sich mit rekursiven Filtern extrem effizient implementieren - keine Multiplikationen.
Moin, Merci fuer die Anregungen. Ich meine, mich jetzt auch schwach erinnern zu koennen, dass 1995 im IENT der RWTH Aachen Diplomarbeiten zu sowas wie von Horst Beschriebenen in Arbeit waren. AFAIR gings da darum, das Videobild erstmal in sehr niedriger Aufloesung zu uebertragen und danach erst weiter zu "verfeinern"... Hab' grad ein bisschen mit Filtern gespielt und mal ein paar Hochrechnungen zur CPU-Last angestellt. Momentan bin ich der Meinung, auf dem atmega16 mit 16MHz muesste eine Filterbank mit 3/4 Subsampling bei 32kSample/sec Eingangsdatenrate gerade noch so machbar sein. Das Spektrum wird dann in einer Stufe nicht halbiert, sondern in 3/4 und 1/4 der Originalabtastfrequenz zerlegt. Dann kriegt man nicht 1 Band pro Oktave (wie bei 1/2 Subsampling), sondern 1.678 Baender pro Oktave raus. Oder andersrum: 1 Band ist dann nicht mehr 12 Halbtoene breit, sondern nur noch ca. 7 Halbtoene. Als Filter dafuer erscheinen mir diese Kandidaten von Performance und Rechenaufriss her momentan als nicht voellig ungeeignet:
1 | x = 0.062; |
2 | f=(round(-768*firls(44,[0 1/4-x 1/4+x 1],[1 1 0 0],[1 2]))); |
3 | f0=downsample(f,3,0); |
4 | f1=downsample(f,3,1); |
5 | f2=downsample(f,3,2); |
6 | g0=f1; |
7 | g0(8)=f1(8)+256; |
(f0,1,2 sind die 3 Geschmacksrichtungen des Polyphasen-Tiefpasses fuer die 4->3 Dezimation; g0 der Hochpass) Da braucht man dann so ungefaehr 24 Filter von der Sorte, um den Audiobereich schoen abzudecken. Damit wirds dann auch schon im RAM langsam kuschelig eng. Gruss WK
Moin, Huch, schon wieder so lange her... Derweilen glaub' ich, dass das im Beitrag vom 02.08.2016 ein Holzweg ist. Die Dezimation um den Faktor 2 scheint mir doch die mit Abstand tollere Wurst zu sein. Wenn man feiner als eine Oktave aufloesen will, ist's wohl gescheiter, die jeweiligen Oktav-Hochpassausgaenge nochmal durch eine 1:2 HP/TP Kombi zu schicken. Das dann ggf. noch ein (paar) mal mehr, bis es schmalbandig genug ist. Also das Beispiel vom Anfang: Fabtast=32kHz, der Hochpassausgang des ersten Filters enthaelt also Anteile von 8..16kHz, die kann man dann nochmal durch so eine HP/TP Kombi schicken, dann hat man eine Unterteilung von 8..12kHz und 12..16kHz. Die 8..12kHz dann nochmal und man hat dann folgende Ausgaenge: 8..10kHz 10..12kHz 12..16kHz Das sind jetzt nicht 100% genau Terzabstaende, also 0|4|8|12 Halbtonschritte, sondern 0|3.86|7|12 Halbtonschritte. Aber damit muss man leben, wenn man rechenfaul ist ;-) Gegenueber der reinen Oktavfilterei, die ja vom Rechenaufwand fuer die Filter immer <2x Rechenaufwand eines einzelnen HP/TP Filter bleibt, brauchts fuer diese "Terz"filterei dann den <3.5 fachen Rechenaufwand eines einzelnen HP/TP Filters. Also nicht mal doppelt soviel, fuer 3x mehr LEDs. Und alles mit nur einer einzigen Sorte Filter (und wenn gleich anrufen und sofort bestellen, erhalten sie voellig umsonst und gratis einen 2. Satz....). OK, der Rechenaufwand fuers Quadrieren, Aufsummieren, Logarithmieren, um die Leistung in den Frequenzbaendern zu errechnen, wird natuerlich linear (also um 3x bei 3x so vielen LEDs) ansteigen. Gegenueber Dezimationen mit !=2 Dezimationsfaktor hat man aber auch noch den Vorteil, dass man zum Normieren der verschiedenen Frequenzbaender immer nur mit 2 multiplizieren/dividieren muss, was durch shiften deutlich leichter/schneller geht, als mit allen anderen Faktoren ausser 2. Gruss WK
Dergute W. schrieb: > Die Dezimation um den Faktor 2 scheint mir doch die mit Abstand tollere > Wurst zu sein. Würde ich auch so sehen. Hier gibt es übrigens viel Potential um Rechenzeit zu sparen (und gleichmäßiger in Anspruch zu nehmen). Die habe ich in meiner Lösung genutzt... > Wenn man feiner als eine Oktave aufloesen will, ist's wohl gescheiter, > die jeweiligen Oktav-Hochpassausgaenge nochmal durch eine 1:2 HP/TP > Kombi zu schicken. Oder halt für die "Feinfilterung" innerhalb der Oktaven Gortzels benutzen. Diese Möglichkeit habe ich nur in der höchsten Oktave benutzt, allerdings nur deshalb, weil der Goertzel effizienter war als der qualitativ hochwertige Halbbandfilter 3.Ordnung, den ich zur Oktavtrennung verwendet habe. Im übrigen kannst du mich nur von deiner Lösung überzeugen, wenn du ein lauffähiges Sample für einen TinyX5 liefern kannst, komplett mit Ansteuerung der LEDs. Komplett (und beweisbar) in Echtzeit ablaufend. Ja, das würde Eindruck machen... Mit einem Mega (und damit verfügbarer Hardware-Multiplikation) könnte ich meine Lösung jedenfalls problemlos auf die doppelte (-1) Kanalzahl meiner Tiny-Lösung ausweiten. Erst bei der dreifachen (-1) Kanalzahl würde es beginnen, leicht eng zu werden. All das kann ich spezifizieren, ohne auch nur eine Zeile neuen Code geschrieben zu haben... Mir scheint: Asm is better...
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.