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.
Naja 300Hz von Pass zu Stop sind halt schon eine Hausnummer das sind ja ca. 90db/dec wenn du da 30db ansetzt.
Eigentlich ist es einfach: Randbedingungen erfassen und in den Designprozess einfließen lassen. Randbedingungen: - Designzeit - Modularität - Erweiterbarkeit - Flexbilität - Rechenzeit - Rechengeschwindigkeit - Echtzeitfähigkeit - Echtzeitänderungungsfähigkeit - Resourcenverbrauch - Stromverbrauch Siehe auch Beitrag "Re: Vivado und MATLAB" Abschnitt "Praktisches Ausprobieren"
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.
:
Bearbeitet durch User
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.
Beitrag #6092067 wurde von einem Moderator gelöscht.
Beitrag #6092166 wurde von einem Moderator gelöscht.
Angehängte Dateien:
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.
Moin, Wenn ich nur FIRs mit symmetrischen Koeffizienten in Kette schalte, wieso sollte da die Phase irgendwelche Faxen machen? Gruss WK
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.
Moin, Ich hab' auch kein Matlab. Aber GNU Octave mit dem "signal" package von octaveforge. Gruss WK
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
Angehängte Dateien:
-
integer_16Bit_Kaiser_wobble.jpg
110 KB -
integer_18Bit_Kaiser_wobble.jpg
110 KB -
integer_20Bit_Kaiser_wobble.jpg
110 KB -
integer_24Bit_Kaiser_wobble.jpg
110 KB
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.
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.