N'abend!
Aktuell versuche ich mich gerade etwas mit FIR-Filtern.
Dabei nutze ich den FilterDesigner der bei der MATLAB DSP Toolbox
beiliegt.
Ich habe gelesen, dass -60dB als Stopband-Unterdrückung schon sehr gut
ist und sich in Hardware nur mit großem Aufwand erreichen lässt.
Bei einem Tiefpass mit den Durchlass- und Sperrfrequenzen von 2,7k und
3k und einer Abtastrate von 48k errechnet mir Matlab einen Filter mit
mehr als 300 Taps. Dabei hatte mein Professor vor ein paar Wochen noch
erwähnt, dass oft der Fehler gemacht wird mit zu optimistischen Angaben
zu arbeiten und so auf paar hundert oder gar tausend Taps kommt. Diese
sehen zwar schön aus, lassen sich dann aber auf Mikrocontrollern eher
weniger realisieren (wenn es um die Verarbeitungsgeschwindigkeit geht).
Selbst bei einer Unterdrückung von -30dB komme ich aber noch auf knapp
200 Taps. Ich frage mich, ob ich etwas grundsätzlich falsch mache?
Als Design Method habe ich Equiripple ausgewählt bzw. es war schon
vorausgewählt. Die anderen machen es aber auch nicht besser.
Moin,
So'n Filterdesign mit ner Toolbox ist halt eine Holzhammermethode. Die
geht schon immer irgendwie, ist aber nicht immer "schoen". Ich wuerd's
so aus'm Handgelenk raus mit 2 Teilfiltern loesen. Einem Filter F1, das
durch Einfuegen von diversen Nullen einen periodischen Frequenzgang,
aber dadurch auch steile Flanken hat, und einem zweiten Filter, was dann
enspannter ist, und nur Sperrdaempfung "weiter hinten" machen muss. Die
20 als Filterordnung ist einfach nur mal ein Anfangswert.
Also so z.B.:
1
f1=(firls(20,[0 0.1125*4 0.125*4 1],[1 1 0 0]));
2
uf1=upsample(f1,4,0);
3
4
f2=(firls(20,[0 0.1125 0.5-0.1125 1],[1 1 0 0]));
5
6
freqz(conv(uf1,f2));
Das ganze wird dann ein Filter, was 40MACs/cycle braucht, und da wird
man dann wahrscheinlich auch noch was mauscheln koennen.
Vielleicht geht's mit 3 Teilfiltern noch schoener, aber das ist dann
halt etwas experimentieren...Also das Gegenteil von Toolbox.
Gruss
WK
Wenn du den Übergang weniger steil machst (2700Hz,3300Hz), dann
benötigst du nur die Hälfte der Koeffizienten.
Wenn man statt 48000Hz mit 24000Hz arbeitet, dann halbiert sich auch die
Zahl der Koeffizienten. Das ginge mit einem Multiratefilteransatz.
https://de.mathworks.com/help/dsp/ug/multirate-filters.html
Beachte auch den Ripple im Durchlassbereich. Da möchte man nicht gerade
1dB haben. 1dB = 10^(1/20) entspricht 12% ripple im Durchlassbereich.
Bei Audio ist das vermutlich egal, bei einem Messgerät eher nicht.
Helmut S. schrieb:> Beachte auch den Ripple im Durchlassbereich. Da möchte man nicht gerade> 1dB haben. 1dB = 10^(1/20) entspricht 12% ripple im Durchlassbereich.> Bei Audio ist das vermutlich egal, bei einem Messgerät eher nicht.
Das ist auch beim Audio nicht wirklich egal :-) Es ist nur oft nicht
anders zu machen. Mikrofon- und Lautsprecherkennlinien müssen
beispielsweise sehr aufwändig hingebogen werden, um 1dB Abweichung zu
unterschreiten.
Dergute W. schrieb im Beitrag #6092166:
> I believe my pig whistles.
Equal goes it loose. Lübke lebt, jawoll!
Aber sag mal, wie du dir das mit deinen Fltervorschlägen weiter oben
gedacht hast. Ich schätze, daß bei derartigen Konstruktionen die Phase
im Durchlaßbereich munter Purzelbäume schlägt. Mag sein, daß sowas für
Audio egal ist, aber aus meiner Sicht (I/Q-Radio-Empfang) wäre sowas
tödlich. Da bleibt eben nur der volle Aufwand für ein lückenloses FIR
Filter. Siehe angehängtes Bild.
W.S.
> daß bei derartigen Konstruktionen die Phase> im Durchlaßbereich munter Purzelbäume schlägt.> Mag sein, daß sowas für Audio egal ist
Ein durchgeruehrter Phasengang wird schon bei einigen
hintereinandergeschalteten analogen Sallen-Key-Filtern
unangenehm hoerbar.
Dergute W. schrieb:> Wenn ich nur FIRs mit symmetrischen Koeffizienten in Kette schalte,> wieso sollte da die Phase irgendwelche Faxen machen?Dergute W. schrieb:> Also so z.B.:f1=(firls(20,[0 0.1125*4 0.125*4 1],[1 1 0 0]));> uf1=upsample(f1,4,0);>> f2=(firls(20,[0 0.1125 0.5-0.1125 1],[1 1 0 0]));>> freqz(conv(uf1,f2));
Also, das was du da an Programm hast, hab ich nicht (wohl Matlab) und
kenne ich auch nicht inwendig. Ebenso kenne ich keine der tausend dort
eingebauten Funktionen. Allerdings sieht es mir beim Draufschauen auf
deine Quellzeilen tatsächlich unsymmetrisch aus - du scheinst ja nur
positive N, positive Taps und Nullstellen zu haben. Also ein extrem
unsymmetrisches FIR (falls es eines sein sollte...).
Das ist im übrigen ein Ärgernis: Bis auf einige Leute, die Matlab
entweder in der Firma haben oder sonstwie dran gekommen sind (...) kann
keiner mit dem Zeugs was anfangen. Entweder sollte man da besser seine
Algorithmen mathematisch formulieren oder in Pascal ausdrücken (weil das
einfach zu lesen ist und deshalb jeder von selbst versteht). Alternativ
als Struktogramm.
W.S.
W.S. schrieb:> Sieht aber genauso unverständlich aus.
Tja, das Leben ist eben kein Ponyhof.
W.S. schrieb:> Das ist im übrigen ein Ärgernis: Bis auf einige Leute, die Matlab> entweder in der Firma haben oder sonstwie dran gekommen sind (...) kann> keiner mit dem Zeugs was anfangen.
Was Du nicht sagst. Ich würde sagen: Bullsh*t!
> Entweder sollte man da besser seine> Algorithmen mathematisch formulieren oder in Pascal ausdrücken (weil das> einfach zu lesen ist und deshalb jeder von selbst versteht). Alternativ> als Struktogramm.
Pascal ist tot, Mathematik und Struktogramm findest Du in entsprechenden
Lehrbüchern.
Ich kann Python mit SciPy und Matplotlib für solche Dinge empfehlen:
https://docs.scipy.org/doc/scipy/reference/tutorial/signal.html#filter-design
Für Matlab hat es bei mir nämlich auch nicht gereicht...
W.S. schrieb:> Das ist im übrigen ein Ärgernis: Bis auf einige Leute, die Matlab> entweder in der Firma haben oder sonstwie dran gekommen sind (...)
Matlab kostet für Privat 120€ + 35€ pro Toolbox. Es ist allerdings nicht
upgradefähig, d.h. wer dann nächstes Jahr die neue Version will, der
muss dann alles neu kaufen.
Ich sehe allerdings bei der Arbeit, dass die Kollegen, die frisch von
der Uni kommen, eher Python machen (ganz allgemein, nicht auf
Filterdesign bezogen).
>Matlab kostet für Privat 120€ + 35€ pro Toolbox. Es ist allerdings nicht>upgradefähig, d.h. wer dann nächstes Jahr die neue Version will, der>muss dann alles neu kaufen.
Deshalb nutze ich schon seit Jahren Gnu-Octave. Das ist zu Matlab
ziemlich kompatibel und mit der Signal-Processing Toolbox lässt sich
auch viel Signalverarbeitung machen.
>Ich sehe allerdings bei der Arbeit, dass die Kollegen, die frisch von>der Uni kommen, eher Python machen (ganz allgemein, nicht auf>Filterdesign bezogen).
So ist es. Allerdings finde ich die Umsetzung von Matlab ( NumPy,
Matplotlib ) doch eher noch etwas umständlicher zu benutzen als
Matlab/Octave selbst.
Moin,
Hab' derweilen mal geguckt - also, das was ich hier mal urspruenglich
meinte, heisst voellig programmiersprachenunabhaengig: IFIR oder
"interpolated FIR".
Wird z.B. im Kap. 7.2 von "Understanding Digital Signal Processing" von
Rick Lyons beschrieben.
Gruss
WK
Dergute W. schrieb:> IFIR
Hmm.. du meinst so etwa diesen Artikel - oder?
Das sieht zwar alles recht interessant aus, enthält aber mMn zu viele
interne Entscheidungen, um sowas real in einem µC für einen Empfänger
implementieren zu können - derart, daß man als Operator an einem Knopf
drehen und damit zur Laufzeit die zwei Eckfrequenzen des ZF-Bandpasses
nach Gusto einstellen kann.
Was da bleibt, wären Verwendungen, wo man das alles zuvor zur
Entwurfszeit oder zumindest im PC zur Laufzeit ausrechnen kann. Immerhin
sieht das ja so aus, daß die Ersparnis im Wesentlichen darauf beruht,
daß man gezielt Taps auf Null setzt und folglich die zugehörige MAC
ausläßt.
Aber das bedeutet im Grunde jedesmal eine Firmware-Modifikation oder
zusätzlichen Verwaltungsaufwand, der die eingesparten MAC's wohl wieder
auffrißt. Es ist bei sowas eben nicht mit einer simplen Neuberechnung
des Filterkernels getan.
Nun ja, für Rick auf seinem recht hohen theoretischen Level sind das
eher unbedeutende Details.
Ich habe weiter oben nicht ohne Grund "Pascal" geschrieben. Auch wenn
hier jemand wegen Pascal herum motzen muß, ist es dennoch eine Notation,
die ein Jeder sofort versteht - im Gegensatz zu den Aufrufen von
Mathcad/Octave/etc. - und genau das war und ist die Intention.
Ein Ähnliches gilt für die mathematische Notation, wie sie z.B. Rick im
obigen Artikel benutzt. Wer genau diesen Zweig der Mathematik nicht
studiert hat, oder dessen Mathe-Studium zu lange her ist, der tut sich
schwer mit dem schieren verstehenden Lesen. Das sollten die, welche
grad frisch von der Uni kommen oder gar aktiv im Lehrbetrieb stehen,
auch mal berücksichtigen.
Nochwas: so rund 90 dB Sperrdämpfung, wie man sie mit einem simpel
gestrickten FIR im obigen Beispiel erreicht, habe ich bei Rick's
Ausführungen nicht gesehen. Es ist das Thema wohl doch ein einziger
Morast aus Kompromissen in allen Richtungen, durch den man waten muß, um
zu seinem eigenen Ziel zu kommen.
W.S.
Moin,
Ja - hm. Was soll ich da jetzt sagen...
Urspruenglich hat hier einer einen Tiefpass mit fixen Werten vorgegeben,
berechnet und sich dann ueber den hohen Aufwand gewundert. Dann hab' ich
was dazu geschrieben, wie man evtl. diesen Aufwand verringern koennte.
Jetzt kommst du an, quengelst 'rum, weils dir zu kompliziert ist und
nicht in Pascal und ueberhaupt und Sperrdaempfung und bla. Und
eigentlich willst du scheint's was voellig anderes als der TO - naemlich
keinen Tiefpass mit festen Eckfrequenzen, sondern einen frei
durchstimmbaren Bandpass.
Wenn du dich wenigstens auf eine fixe Bandbreite festlegen kannst, dann
geht so ein durchstimmbarer Bandpass z.B. mit einem komplexen Mischer,
danach in I und Q Zweig jeweils eines von den IFIRs oder sonst
irgendeine Geschmacksrichtung schmalbandiger (=deine gewuenschte
Bandbreite/2) Tiefpaesse und danach - wenn du's wieder in der
Originallage haben willst, halt wieder per komplexem Mischer
hochgemischt. Wenn du da unbedingt >90 dB Sperrdaempfung haben willst,
musste auch mal gucken, mit wieviel Bit Genauigkeit die ganze
Verarbeitung stattfinden muss. 16 koennt' da knapp werden.
Ist aber halt so, dass die Rechnerei hinter dem Ganzen nicht so
supersimpel ist, wie du's gerne haettest. Hat schon einen Grund, warum
man Filterentwurf, Abtastung, etc. nicht im Kindergarten als Abzaehlreim
lernt. Auch wenn du mit'm Fuss aufstampfst und "WILL ABER!" bruellst.
;-)
Gruss
WK
Dergute W. schrieb:> Auch wenn du mit'm Fuss aufstampfst
Ach nee. Laß mal diese Seite. Ich sehe aber durchaus, daß es da ne
gewaltige Lücke gibt - zwischen Leuten wie Lyon auf der einen Seite und
Leuten wie Funkamateuren und dem TO, der "sich grad mal" mit dem
Filterdesigner von Matlab oder so "versuchen" will. Theoretiker auf der
einen, Bauklötzchen auf der anderen Seite.
Mir wäre durchaus daran gelegen, wenn Leute die von beiden Seiten
genug verstehen, was schreiben und damit diese Lücke überbrücken. Fühlst
du dich dazu in der Lage?
Eigentlich täte es not, diese Dinge mal aus ihrem Elfenbeinturm
herauszuholen - gestandene HF-Praktiker winken nämlich ab und sagen,
'bin zu alt dafür, werde mich damit einfach nicht mehr befassen' und
junge Leute üben sich im Dünnbrettbohren bzw. fertigen Bauklötzchen. Das
ist alles nicht wirklich gut für uns alle - auch wenn es mich persönlich
nicht wirklich betrifft.
Ich hab die Sache selbst mal ein wenig von der Querseite her aufgerollt,
aber das Thema dümpelt seit Jahren dahin. Aber da du fragtest, häng ich
dir mal das Ganze was oben in double gerechnet war in diversen
Integer-Ausführungen dran. Ist nicht uninteressant, wenngleich auch zu
erwarten gewesen.
W.S.
1) Ich sehe diese Diskrepanz zwischen den Theoretikern und Praktikern
nicht. Sie ist auch nicht jung und alt zuzuordnen. Ferner ist modernes
Bauen nicht unbedingt Bauklötzen und klassisches Bauen nicht immer
solide oder "analog", wie man heute fälschlich gerne sagt.
2) Ich würde gerne mal wissen, wie die Baukasteneffekte in deinem
Filterprogramm aussehen:
a) Welcher Kaiser ist das? / Welcher Blackmann? - Bei beiden gibt es
etliche Versionen
b) Warum nimmst du ausgerechnet 201 TAPs? Das ist super grob im
Vergleich zu dem, was die Fenster an Unterschied ausmachen können
c) Warum kommt hier Pedersen zum Einsatz? Hoffentlich nicht als
Testsignal für den Filter????
Analoger schrieb:> Ich würde gerne mal wissen, wie die Baukasteneffekte in deinem> Filterprogramm aussehen
Das Programm kann sowohl aus sich heraus Filter generieren als auch
fertige Filterkernel laden und deren Response anzeigen. Für den
klassischen Kaiser erscheint mir ein Beta von 9.5 am geeignetsten. Und
der Blackman ist ebenfalls der klassische Blackman.
Das alles spielt hier aber keine Rolle, sondern hier sieht man lediglich
den Einfluß der verschieden stark begrenzten Rechengenauigkeit bei
ansonsten gleichbleibenden Randbedingungen.
Die 201 Taps sind mMn ein guter Kompromiß zwischen der Beurteilbarkeit
der prinzipiellen Filtercharakteristika und der Machbarkeit in einem µC.
Ich halte das überhaupt nicht für "supergrob". Rechne doch mal nach: bei
"nur" 96 ksps I+Q hat man grob, ohne Waitstates bei 100 MHz Takt nur
etwa 1000 Takte pro Sample. Da muß man zweimal je 201 Taps rechnen,
anschließend noch demodulieren (AM+FM per Cordic) und ein Rest muß auch
noch für alles Übrige bleiben. Mit Waitstates sieht das übler aus,
gleiches gilt für höhere CPU-Takte wenn dort mehr Waitstates
erforderlich sind, je nach AHB und/oder TCM-Verwendbarkeit - falls solch
eng an die CPU gekoppelter RAM verfügbar ist UND sowohl für Daten als
auch Code gleichzeitig benutzbar sein sollte.
Und der Pedersen dient dem gleichen generellen Zweck: Machbarkeit im µC
unter den dortigen Restriktionen austesten. Damit wurde in allen 4
Integer-Fällen der Filterkernel gemacht - ist ja sin(x)/x. Ich finde,
dabei macht sich der Pedersen erstaunlich gut im Vergleich zum komplett
in double gemachten und gerechneten Filter weiter oben.
Bedenke mal, daß man bei einem Cortex-M4F entweder mit 24 bittiger
Mantisse in single oder mit 2 Taps pro Operation und nur 16 Bit integer
rechnen kann. Da muß man schon abwägen, was einem welche Randbedingung
wert ist.
Kurzum, nette Algorithmen sind das eine - die tatsächliche Realisierung
ist etwas anderes. Und beide haben so ihre Probleme.
Ich hacke nicht ohne Grund auf der Lücke zwischen hochtrabenden Papers
und den Niederungen der technischen Realisierung herum. Von mir aus in C
wenn das etwa so hinkommen sollte wie Assembler - aber hier zum
Darstellen der Algorithmen besser in pascalartige Notation, da das zum
Verständnis dienen soll und nicht unbedingt zum tatsächlichen
Realisieren.
W.S.
Analoger schrieb:> Ich sehe diese Diskrepanz zwischen den Theoretikern und Praktikern> nicht.
Daß du das nicht siehst, dafür für kann ich nicht.
> Sie ist auch nicht jung und alt zuzuordnen.
Oh doch. Die Alten haben erhebliches Wissen und Können in analoger
Technik und die Jungen haben das nicht. Industrieller Fakt ist dabei,
daß die rein analoge Verarbeitung nicht mehr Stand der Technik ist,
sondern eben deren digitale Ersetzung.
Immerhin hat Hogenauer seinen CIC bereits 1981 entwickelt - zu einer
Zeit, wo das Gros der Ingenieure gerade eben Bekanntschaft mit dem PC in
Form des Z80 mit CP/M gemacht hatte. Da waren und sind Welten dazwischen
- zwischen den Leuten, die mit schier unbegrenzten Mitteln für NSA und
Konsorten Digitaltechnik entwickeln konnten/können und dem Rest der
Ingenieurs-Welt. Eben die besagte Lücke.
Und was meinst du, wieviele Ingenieure, die am PC einen DVB-USB-Stick
einstecken und dann ein SDR-Programm benutzen, tatsächlich über digitale
Signalverarbeitung so gut Bescheid wissen, daß sie sowas prinzipiell
selbst schreiben könnten?
Nein, das Wissen und Können in digitaler Signalverarbeitung ist derzeit
noch längst nicht Allgemeingut in den Kreisen der
Ingenieure/Informatiker/Programmierer geworden.
W.S.
W.S. schrieb:> Nein, das Wissen und Können in digitaler Signalverarbeitung ist derzeit> noch längst nicht Allgemeingut in den Kreisen der> Ingenieure/Informatiker/Programmierer geworden.
Und das wird es auch nicht werden.
Tatsache ist doch, wenn es etwas Fertiges gibt, was mein Problem löst
und in die restlichen Randbedingungen passt, gibt es nur noch wenige
Gründe etwas selbst zu entwickeln.
Daher werden Displays oder Sensoren eingesetzt, die mit fertigen
Arduino-Bibliotheken kommen. Oder ein Raspi oder ein Zynq, wo nicht mehr
der Netzwerkstack entwickelt werden muß, sondern die eigene Applikation
direkt auf Linux aufsetzen kann. Oder diverse Frameworks auf
PC-Systemen. Die Beispiele sind zahlreich.
Es gibt keinen unmittelbaren Zwang sich tief mit jeder Materie
auseinandersetzen zu müssen. Ja, das führt natürlich zu nicht optimalen
Lösungen im Hinblick auf Hardwareressourcen. Das spielt aber beim Hobby
keine Rolle und in Firmen nur dann, wenn es die Konkurrenz in Summe
besser hinbekommt.
Bernd schrieb:> Tatsache ist doch, wenn es etwas Fertiges gibt...
.. dann braucht man sich nicht darum zu bemühen, in seiner Sparte
führend zu werden, zu sein, zu bleiben, innovativ zu sein, Vorsprung vor
anderen zu haben, sich eben nicht auf den Lorbeeren vergangener
Jahrzehnte auszuruhen.
Weißt du eigentlich, womit wir hier in Europa unseren derzeitigen
Wohlstand in Zukunft aufrecht erhalten wollen?
Ich halte diese Denkweise für die einer im Untergang befindlichen
Gesellschaft.
W.S.
W.S. schrieb:> Immerhin hat Hogenauer seinen CIC bereits 1981 entwickelt
Das war jetzt aber auch eine Leistung einen Mittelwertfilter zu
kaskadieren. Wow!
Mathematiker vom Dienst schrieb:> Das war jetzt aber auch eine Leistung...
Sei nicht albern. Das zeigt uns, daß es in den betreffenden Kreisen
bereits damals die zugehörige Hardware gab, von der unsereiner damals
noch nicht mal hätte träumen können. Also lies das verstehend und
nicht bloß, um dich drüber zu mockieren.
W.S.
