"LED-Spectrumanalyzer"software ohne Fouriertransformation

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,

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.

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

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