GNU Radio Companion · Block
Bandpass-Filter-Blöcke (Filter & Taps)
Band Pass Filter und Band-pass Filter Taps in GRC 3.10 — Unterschied, Parameter mit Dimensionierungsanweisungen und wann welcher Block die richtige Wahl ist.
GRC 3.10 bietet zwei eng verwandte Bandpass-Blöcke, die auf denselben firdes-Funktionen basieren, sich aber in ihrer Rolle im Flowgraph grundlegend unterscheiden: Band Pass Filter ist ein fertiger Verarbeitungsblock (Filterentwurf + Anwendung in einem Schritt), Band-pass Filter Taps ist ein reiner Variablen-Block, der nur die Filterkoeffizienten berechnet, ohne selbst ein Signal zu verarbeiten.
1. Beschreibung der Blöcke
Band Pass Filter (filter.fir_filter_*, intern per firdes.band_pass()/firdes.complex_band_pass() entworfen) ist ein kombinierter Filterentwurfs- und FIR-Filter-Block: Er berechnet beim Bauen des Flowgraphs die Tap-Koeffizienten aus den angegebenen Parametern (Grenzfrequenzen, Übergangsbreite, Fenster) und wendet sie direkt auf den durchlaufenden Datenstrom an. Für die allgemeinen Grundlagen von Cutoff, Transition Width, Gain und Fensterwahl siehe Bandpass- und Bandsperrfilter und FIR-Filter.
Band-pass Filter Taps (firdes.band_pass()/firdes.complex_band_pass() direkt als GRC-Variable) berechnet exakt dieselben Koeffizienten, verarbeitet aber selbst keine Daten — er hat keine Ein- oder Ausgänge im Signalpfad. Das Ergebnis ist ein Array (float_vector bei reellen, complex_vector bei komplexen Taps), das man manuell in den Taps-Parameter eines anderen Blocks einträgt.
firdes.low_pass(1, 12000, 400, 100), dort als Tiefpass) — ein „Band-pass Filter Taps"-Block wäre die GRC-Entsprechung, wenn statt eines Tiefpasses ein Bandpass in den Freq-Xlating-Filter eingespeist werden soll.2. Technischer Einsatz
Wann „Band Pass Filter" (fertiger Block): im Regelfall — überall dort, wo im Flowgraph an genau einer Stelle ein Bandpass auf einen Datenstrom angewendet werden soll (Kanalselektion, Störerunterdrückung, siehe Bandpassfilter).
Wann „Band-pass Filter Taps" (Variable): wenn dieselben Koeffizienten an anderer Stelle gebraucht werden, an der kein fertiger Filterblock zum Einsatz kommt — typischerweise als Taps-Parameter eines Frequency Xlating FIR Filter (der keinen eigenen Cutoff/High-Cutoff-Parameter hat, sondern ein fertiges Taps-Array erwartet), oder wenn dieselbe Berechnung mehrfach im Flowgraph referenziert werden soll, ohne sie doppelt zu konfigurieren.
Reelle vs. komplexe Taps — die wichtigste Entscheidung: Beide Blöcke bieten eine Wahl zwischen reellen Taps (firdes.band_pass) und komplexen Taps (firdes.complex_band_pass). Das ist keine Geschmacksfrage:
firdes.band_pass() (reelle Taps) verlangt zwingend 0 < low_cutoff_freq ≤ high_cutoff_freq ≤ samp_rate/2 — ein Aufruf mit negativer Grenzfrequenz wirft tatsächlich einen Fehler (firdes check failed: 0 < fa ≤ sampling_freq / 2, getestet mit GNU Radio 3.10.12.0). firdes.complex_band_pass() (komplexe Taps) akzeptiert dagegen auch negative oder asymmetrisch zu 0 Hz liegende Bereiche (getestet mit −6000 bis −2000 Hz, lief fehlerfrei) — nur damit lässt sich ein einzelnes, nicht bei 0 Hz zentriertes Band direkt selektieren, ohne dass sich automatisch ein gespiegeltes Passband bei der positiven Gegenfrequenz öffnet.Faustregel: reelle Taps genügen, wenn das gewünschte Band symmetrisch zur Mittenfrequenz liegt und auf ein reelles oder komplexes Signal angewendet wird (Standardfall, z. B. ein Kanalfilter um eine bekannte Mittenfrequenz). Komplexe Taps sind nötig, sobald das Band asymmetrisch liegt oder ein reelles Signal direkt in ein einseitiges (nicht gespiegeltes) komplexes Band übersetzt werden soll — der einzige Fall, in dem auch „Float→Complex" als Ein-/Ausgabekombination zur Verfügung steht (siehe Tabelle in Abschnitt 4).
3. Parameter und Dimensionierung
Beide Blöcke teilen sich (bis auf die block-spezifischen Zusatzparameter in Abschnitt 4) dieselben Kernparameter:
| Parameter | Typ/Einheit | Bedeutung | Dimensionierungshinweis |
|---|---|---|---|
samp_rate |
Hz | Abtastrate des Eingangssignals | durch die Quelle vorgegeben, nicht frei wählbar |
low_cutoff_freq |
Hz | untere Grenzfrequenz des Durchlassbereichs | muss > 0 und ≤ high_cutoff_freq sein (bei reellen Taps zusätzlich ≤ samp_rate/2) |
high_cutoff_freq |
Hz | obere Grenzfrequenz des Durchlassbereichs | Bandbreite high − low an die tatsächliche Nutzsignalbandbreite anpassen, nicht großzügig überdimensionieren (siehe FIR-Filter) |
width (Transition Width) |
Hz | Breite des Übergangsbereichs zwischen Durchlass- und Sperrbereich | kleiner = steilere Flanke, aber mehr Taps und mehr Rechenlast — Faustformel: $N \approx A_{sb}/(22 \cdot \Delta f/f_s)$ |
gain |
linear (nicht dB) | Verstärkungsfaktor des Filters | i. d. R. 1.0, außer eine gezielte Pegelanpassung soll direkt im Filter erfolgen |
win (Window) |
Enum | Fensterfunktion: Hamming, Hann, Blackman, Rectangular, Kaiser | bestimmt die erreichbare Sperrdämpfung — Details und Vergleich in Fensterfunktionen |
beta |
— | Kaiser-Beta-Parameter | nur bei win = Kaiser sichtbar/relevant; aus der Ziel-Sperrdämpfung berechenbar über den Rechner |
decim / interp |
Integer | Dezimations- bzw. Interpolationsfaktor | abhängig von der gewählten type-Option (siehe Abschnitt 4) — nur eines von beiden ist je Variante aktiv |
samp_rate=48000, low_cutoff=4000, high_cutoff=10000, width=2000, Hamming-Fenster ergibt firdes.band_pass() exakt 57 Taps — deckungsgleich mit der Faustformel aus dem FIR-Filter-Artikel: $N \approx 53\,\text{dB}/(22 \cdot 2000/48000) \approx 57{,}8$, aufgerundet auf eine ungerade Zahl. firdes.complex_band_pass() liefert mit denselben Parametern ebenfalls 57 Taps, jedoch als komplexe statt reelle Werte.4. Ein- und Ausgänge
Nur der Band Pass Filter-Block hat Signal-Ports — die Taps-Variante hat keine. Welche Ein-/Ausgabekombination zur Verfügung steht, hängt von der gewählten FIR Type-Option ab:
| FIR Type (Auswahl im Block) | Eingang | Ausgang | Taps-Art | Rate |
|---|---|---|---|---|
| Complex→Complex (Real Taps) | complex | complex | reell (band_pass) |
Decim oder Interp |
| Float→Float (Real Taps) | float | float | reell (band_pass) |
Decim oder Interp |
| Complex→Complex (Complex Taps) | complex | complex | komplex (complex_band_pass) |
Decim oder Interp |
| Float→Complex (Complex Taps) | float | complex | komplex (complex_band_pass) |
Decim oder Interp |
„Real Taps" und „Complex Taps" in der Optionsbezeichnung beziehen sich auf die Tap-Koeffizienten (siehe Abschnitt 2), nicht auf den Datentyp von Ein- oder Ausgang — ein Complex→Complex-Filter kann wahlweise mit reellen oder komplexen Taps arbeiten, je nachdem, ob das Band symmetrisch liegen darf. Float→Complex existiert ausschließlich mit komplexen Taps: reelle Taps können aus einem reellen Eingang keinen komplexen Ausgang erzeugen, ohne den fehlenden Imaginärteil erst zu rekonstruieren (siehe Testen mit Konserven zur Hilbert-Transformation als Alternative).
5. Weitere wichtige Aspekte
Live-Parameteränderung ohne Neustart: Beide Blöcke unterstützen set_taps(...) bzw. set_<variablenname>(...) als Callback — wird z. B. low_cutoff_freq über einen QT-GUI-Regler zur Laufzeit verändert, berechnet GNU Radio die Taps automatisch neu und ersetzt sie im laufenden Flowgraph, ohne dass top_block.stop()/start() nötig wäre. Das ist die technische Grundlage jedes im laufenden Betrieb nachstimmbaren Kanalfilters.
Asserts im Block selbst: GRC prüft low_cutoff_freq ≤ high_cutoff_freq und width > 0 bereits beim Bauen des Flowgraphs (nicht erst zur Laufzeit) — ein vertauschter Low/High-Wert führt zu einem sofortigen Compile-Fehler, nicht zu einem stillschweigend falschen Filter.
Verwandter Block: Die Bandsperre (Band Reject Filter) ist das inverse Gegenstück mit identischen Parametern — siehe Bandpass- und Bandsperrfilter.
Bandpass- und Bandsperrfilter
Grundlagen, Kanalselektion und Störerunterdrückung als Praxisanwendungen.
FIR-Filter
Tap-Zahl-Herleitung, Fensterwahl und Rechenlast — inklusive interaktivem Demonstrator.
Rechner
Tap-Zahl und Kaiser-Beta direkt aus den eigenen Grenzfrequenzen berechnen.
DDK9-Dimensionierung
Ein Freq-Xlating-FIR-Filter, dessen Taps-Parameter genau nach diesem Prinzip befüllt wird.