Themen · Filter

FIR-Filter

Dimensionierung statt Formelsammlung — Tap-Zahl, Fensterwahl, Gruppenlaufzeit und Rechenlast eines FIR-Filters an einem durchgerechneten Beispiel.

Ein FIR-Filter (Finite Impulse Response) berechnet jedes Ausgangssample als gewichtete Summe einer endlichen Anzahl vergangener Eingangssamples. Die Gewichte heißen Taps oder Koeffizienten und sind gleichzeitig die diskrete Impulsantwort des Filters — kein Trick, keine Rückkopplung, nur eine endliche Summe.

$$y[n] = \sum_{k=0}^{N-1} h[k] \cdot x[n-k]$$

Warum FIR und nicht IIR: FIR-Filter mit symmetrischen Koeffizienten sind exakt linearphasig — alle Frequenzen erfahren dieselbe Verzögerung, das Signal wird nicht verzerrt, nur verzögert. Sie sind zudem per Konstruktion stabil (kein Pol kann außerhalb des Einheitskreises liegen). Der Preis: Für dieselbe Flankensteilheit braucht ein FIR-Filter deutlich mehr Koeffizienten als ein IIR-Filter gleicher Güte.

1. Von der Anforderung zur Tap-Zahl

Der Entwurf beginnt nie bei den Koeffizienten, sondern bei drei Anforderungen aus der Systemspezifikation:

Größe Bedeutung Legt fest
Grenzfrequenz $f_c$ Trennfrequenz zwischen Durchlass- und Sperrbereich Lage der Filterflanke
Transition Width $\Delta f$ Breite des Übergangsbereichs zwischen Durchlass- und Sperrbereich Filterlänge (invers proportional)
Sperrdämpfung $A_{sb}$ geforderte Dämpfung im Sperrbereich in dB Filterlänge (proportional)

Filterparameter

Die Tap-Zahl ist keine freie Wahl, sondern eine Konsequenz dieser drei Werte. Für die Fenster-Methode liefert die Faustformel nach fred harris eine belastbare Schätzung:

$$N \approx \frac{A_{sb},[\text{dB}]}{22 \cdot \Delta f / f_s}$$

Praxisrelevanz: Diese Formel ist der Grund, warum in realen Entwürfen (siehe DDK9-Dimensionierung, Abschnitt 3.2) die Transition Width nie „großzügig eng" gewählt wird. Eine Halbierung von $\Delta f$ verdoppelt $N$ — und damit die Rechenlast pro Sample und die Gruppenlaufzeit. Jeder Hz Transition Width kostet konkret messbare Rechenzeit.

2. Dimensionierungsbeispiel: Kanalfilter bei 48 kHz

Alle Werte an einem konkreten Fall — Kanalfilter vor einer Dezimation, Nutzsignal $\pm 6$ kHz, wie er typisch vor einem Demodulator steht:

Parameter Ist-Wert Warum so dimensioniert
Abtastrate $f_s$ 48 000 Hz durch die Quelle vorgegeben
Grenzfrequenz $f_c$ 6 000 Hz Nutzsignalbandbreite; definiert die Kante des Durchlassbereichs
Transition Width $\Delta f$ 2 000 Hz Kompromiss: schmaler spart Nachbarkanaldämpfung, kostet aber Taps — siehe Tabelle unten
Sperrdämpfung $A_{sb}$ 60 dB typischer Zielwert für Nachbarkanalunterdrückung vor einer Dezimation (Alias-Schutz)
Fensterfunktion Blackman-Harris Nebenkeulendämpfung $\ge$ 60 dB in einem Schritt erreichbar, ohne den Beta-Parameter separat einstellen zu müssen (siehe Abschnitt 3)
Tap-Zahl $N$ $\approx 60 / (22 \cdot 2000/48000) \approx$ 65, aufgerundet auf 65 (ungerade $\Rightarrow$ Type-I, symmetrisch) Faustformel aus Abschnitt 1; ungerade Länge erzwingt einen Mittensample $\Rightarrow$ ganzzahlige Gruppenlaufzeit
Gruppenlaufzeit $(N-1)/2 = 32$ Samples $= 32/48000 \approx$ 0,67 ms Bei linearer Phase exakt bestimmbar — kein Ausprobieren nötig
Verdoppelt man die Transition Width auf 4000 Hz, halbiert sich $N$ auf ~33 — bei gleicher Sperrdämpfung. Umgekehrt: Halbiert man sie auf 1000 Hz, wächst $N$ auf ~131. Die Tap-Zahl skaliert linear mit $1/\Delta f$, nicht mit $f_c$.

3. Fensterwahl — der eigentliche Freiheitsgrad

Die ideale Tiefpass-Impulsantwort (eine Sinc-Funktion) ist unendlich lang. Sie wird auf $N$ Samples abgeschnitten und mit einer Fensterfunktion multipliziert, um die harte Abschneidekante — und damit das Gibbsche Phänomen im Frequenzgang — zu entschärfen. Die Fensterwahl entscheidet über den Zielkonflikt zwischen Flankensteilheit und Sperrdämpfung; ein Vergleich der gängigen Fenster (Rechteck, Hamming, Hann, Blackman, Kaiser) sowie die Kaiser-Beta-Formel stehen im Artikel Fensterfunktionen.

Kaiser als Standardwahl in der Praxis: Statt zwischen festen Fenstern zu wechseln, deckt das Kaiser-Fenster über den einen Parameter $\beta$ den gesamten Bereich ab. Für die im Dimensionierungsbeispiel geforderten $A_{sb}=60$ dB folgt $\beta \approx 5{,}65$ — GNU Radios firdes.low_pass() übernimmt diese Berechnung intern, wenn window.WIN_KAISER gewählt wird.

Interaktiver FIR-Tiefpass-Demonstrator

FIR-Tiefpassfilter live berechnen

Ein Testsignal (Nutzsignal + hochfrequente Störung + Rauschen) wird per Sinc-Fenster-Methode (Hamming) gefiltert. Verändern Sie Grenzfrequenz und Tap-Zahl, um den Effekt auf Zeitbereich, Impulsantwort und Gruppenlaufzeit direkt zu sehen.

Signal-Verlauf (Zeitbereich) ● Eingangssignal ● Gefiltert
Filter-Taps (Impulsantwort nach Fensterung)
Grenzfrequenz $f_c$: 300 Hz
Anzahl Taps: 32
Rauschen: gering
Gruppenlaufzeit:
15,5 Samples

4. Zwei Entwurfswege

Verfahren Prinzip Vor-/Nachteil
Fenster-Methode ideale Sinc-Antwort $\times$ Fensterfunktion einfach, schnell berechnet, aber Equiripple nicht optimal — Dämpfung nimmt zu den Bandrändern hin leicht ab
Parks-McClellan (Remez) iterative Optimierung auf minimale Tap-Zahl bei gleichmäßiger Welligkeit in Durchlass- und Sperrbereich für gegebene Anforderung meist 20–30 % weniger Taps als Fenster-Methode, dafür rechenintensiverer Entwurf (nur einmalig, offline)
Faustregel für die Praxis: Die Fenster-Methode reicht für die meisten SDR-Anwendungen (Kanalfilter, Post-Detection-Filter) völlig aus — der Rechenaufwand fürs Filterdesign fällt einmalig beim Bau des Flowgraphs an, nicht im Signalpfad. Parks-McClellan lohnt sich erst, wenn die Tap-Zahl selbst ein hartes Rechenlast- oder Latenzbudget sprengt.

5. Rechenlast

Ein direkt implementiertes FIR-Filter benötigt pro Ausgangssample $N$ Multiplikationen und $N-1$ Additionen — die Rechenlast wächst linear mit der Tap-Zahl und der Ausgangsrate:

$$\text{Last} \approx N \cdot f_{out} \quad [\text{MAC/s}]$$

Läuft vor dem Filter noch eine Dezimation (Filter + Downsampling in einem Block, Freq-Xlating-FIR bzw. polyphase Realisierung), zählt für die Lastabschätzung die Ausgangsrate, nicht die Eingangsrate — der Polyphasen-Trick spart genau den Rechenaufwand, der sonst für die später verworfenen Samples anfiele. Praxisbeispiel mit konkreten Zahlen: DDK9-Dimensionierung, Abschnitt 5 (0,35 statt 3,5 MMAC/s durch frühe Dezimation).

Für das Beispiel aus Abschnitt 2 ($N=65$, keine Dezimation, $f_{out}=48,000$ Hz): $65 \cdot 48,000 \approx 3{,}1$ MMAC/s — ein einzelner Kanalfilter dieser Größenordnung ist auf jeder gängigen CPU unkritisch; erst bei mehreren parallelen Kanälen oder deutlich höheren Abtastraten wird die Tap-Zahl kostenrelevant.