Audio Source Test: Spektrum direkt, über Log Power FFT und über den rohen FFT-Block
Derselbe Audio-Source-Output wird direkt in einem QT GUI Frequency Sink, über den Log Power FFT Block und über den rohen FFT-Block angezeigt — der Vergleich zeigt, was Log Power FFT tatsächlich bündelt und wo sein Mehrwert gegenüber dem manuellen Nachbau liegt.
Dieser Test verbindet den Audio Source Block mit drei unterschiedlichen Anzeigepfaden und vergleicht die Ergebnisse, um die Funktion des Log Power FFT Blocks nachzuvollziehen.
Aufbau des Flowgraphs
Der Audio Source Block (Sample Rate 32 kHz) speist drei parallele Zweige:
- Direkt in einen
QT GUI Frequency Sink(FFT Size 1024, Center Frequency 0 Hz, Bandwidth 32 kHz). - Über einen
Log Power FFTBlock (Sample Rate 32 kHz, FFT Size 1.024k, Reference Scale 2, Frame Rate 30, Average Off, FFT Shift On) in einenQT GUI Vector Sink(Vector Size 1.024k, X-Axis Start Value −16k, X-Axis Step Value 31.25, Ref Level 0). - Über den rohen FFT-Block, manuell nachgebaut aus den Einzelschritten, die Log Power FFT intern bündelt:
Stream to Vector(vlen 1.024k) →FFT(FFT Size 1.024k, Blackman-Harris-Fenster, Shift On) →Complex to Mag²(Vector Length 1.024k) →Log10(n=10, k=0, Vector Length 1.024k) → einen weiterenQT GUI Vector Sinkmit denselben Achsenparametern wie Zweig 2.
Vergleich der Spektren
Links das Spektrum des direkt angeschlossenen Frequency Sink, rechts das Spektrum über den expliziten Log Power FFT-Block mit anschließendem Vector Sink. Beide zeigen denselben Signalinhalt — zwei Spitzen um ±5 kHz sowie einen schmalen Ausschlag bei 0 Hz — und die identische dB-Skalierung von −140 bis −40 dB. Diese Übereinstimmung ist kein Zufall, sondern der eigentliche Beweis: Der Frequency Sink berechnet sein Spektrum intern über exakt dieselbe Kette (FFT → Betragsquadrat → Log-Skalierung), die im Log Power FFT-Block explizit als eigener Block nachgebaut ist (siehe Log Power FFT).
Die sichtbaren Unterschiede erklären sich dadurch, wer die Anzeige übernimmt, nicht durch unterschiedliche Signalverarbeitung:
| Merkmal | Links: Frequency Sink (direkt) | Rechts: Log Power FFT + Vector Sink |
|---|---|---|
| Max-Hold-Kurve (Olive) | vorhanden — der Sink führt intern eine eigene Max-Hold-Statistik über mehrere Frames | fehlt — der Vector Sink zeigt nur die aktuell eintreffenden Werte (Data 0), ohne eigene Trace-Logik |
| Mittelung/Glättung | über Regler „Avg" direkt in der GUI einstellbar | müsste im Log Power FFT Block selbst über Average/Avg Alpha konfiguriert werden (hier bewusst „Off") |
| Fensterfunktion, FFT-Größe, Trigger | live in der GUI wählbar (Blackman-Harris, 1024, Trigger „Free") | einmalig als Blockparameter festgelegt, keine Laufzeit-Umschaltung über eine Anzeige |
| Frequenzachse | automatisch in kHz beschriftet, berechnet aus Sample Rate/Center Frequency des Sinks |
rein numerisch — die Achse muss manuell über X-Axis Start Value (−16k) und X-Axis Step Value (samp_rate/fft_size = 32000/1024 ≈ 31.25) kalibriert werden |
| Pegelwerte (dB) | identisch zum rechten Spektrum | identisch zum linken Spektrum |
Was das über den Log Power FFT Block zeigt
Der Frequency Sink ist eine „Black Box": Er zeigt ein fertiges Spektrum, verrät aber nicht, wie es zustande kommt. Der Vergleich mit dem separat aufgebauten Log Power FFT → Vector Sink-Pfad macht sichtbar, dass hinter dem Sink kein Geheimnis steckt, sondern derselbe Signalverarbeitungsschritt, den man auch selbst mit einem einzelnen Block nachbauen kann.
Der Preis dafür: Alles, was der Frequency Sink „kostenlos" mitliefert — Max/Min-Hold, Mittelungsregler, automatische Frequenzbeschriftung — übernimmt bei der expliziten Variante entweder der Log Power FFT-Block selbst (über seine Parameter) oder muss von Hand am Vector Sink eingestellt werden. Dafür liefert der explizite Pfad reine, headless auswertbare dB-Werte in einem Vektor — genau das, was für automatisierte Tests statt Sichtkontrolle gebraucht wird (siehe Testen mit GRC).
Der dritte Zweig: der rohe FFT-Pfad
Der dritte Zweig zerlegt Log Power FFT in seine vier Einzelschritte — Stream to Vector → FFT → Complex to Mag² → Log10 — und macht dieselbe Vektor-Sink-Anzeige daraus. Werden Fenster (Blackman-Harris), vlen/fft_size (1024) und die Log-Formel exakt nachgebaut, ist die Kurvenform mit den beiden anderen Spektren identisch: gleiche Peaks bei ±5 kHz, gleiche Form. Signalverarbeitungstechnisch unterscheiden sich die drei Zweige also gar nicht — Log Power FFT ist kein eigener Algorithmus, sondern nur eine fertige Verdrahtung derselben Schritte.
Ein Unterschied bleibt trotzdem messbar: Ohne die ref_scale-Korrektur, die Log Power FFT automatisch vornimmt, liegt der Nullpunkt der dB-Skala im rohen Pfad (Log10 mit k=0) einige dB neben dem von Log Power FFT — die im Artikel Log Power FFT (Abschnitt 5) gemessene Verschiebung durch die Fensterleistungs-Normierung fehlt hier, muss also bei Bedarf selbst kalibriert werden.
Wo liegt dann der Anwendungsfall für Log Power FFT?
Wenn die Mathematik identisch ist, liegt der Nutzen von Log Power FFT nicht in der Signalverarbeitung, sondern darin, was der Block abnimmt:
| Aufwand beim manuellen Nachbau (Zweig 3) | Was Log Power FFT stattdessen liefert |
|---|---|
Vier Blöcke mit konsistentem vlen/fft_size verdrahten — eine häufige Fehlerquelle |
ein einziger Block, ein Parameter fft_size |
Ausgaberate ist fix an samp_rate/fft_size gekoppelt |
frame_rate-Parameter dezimiert automatisch auf eine Ziel-Bildrate, unabhängig von fft_size |
Mittelung erfordert einen zusätzlichen single_pole_iir_filter-Block |
eingebaute Mittelung über average/avg_alpha |
| dB-Nullpunkt muss selbst kalibriert werden | automatische ref_scale-Korrektur für Fenster- und FFT-Größen-Effekte |
Über die reine GUI-Anzeige hinaus ist der resultierende float-Vektorstrom auch die Grundlage für automatisierte, nicht-visuelle Auswertungen: Energiedetektion/Spectrum Sensing (Schwellwert auf bestimmten Bins), Träger- bzw. Peak-Suche (argmax über den Vektor), Störer-/Interferenzerkennung, Feature-Extraktion für eine nachgelagerte Klassifikation, sowie headless-Verifikation von Filterdämpfungen per assert statt Sichtkontrolle (siehe Testen mit GRC). Die QT-GUI-Anzeige ist damit nur ein möglicher Abnehmer dieses Datenstroms, nicht der einzige Zweck des Blocks.