buffered_probe (eigener Block)
Chirp-Testsignal durch einen selbst geschriebenen, puffernden Probe-Block geschickt und aus vielen Poll-Häppchen wieder verlustfrei zusammengesetzt.
buffered_probe ist kein eingebauter GNU-Radio-Block, sondern ein eigener, in Block-Tests entwickelter gr.sync_block — er sammelt Samples threadsicher in einem Ringpuffer, statt wie Probe Signal Vector nur den letzten Block zu behalten oder wie Vector Sink unbegrenzt zu wachsen. Vollständiger Quellcode im Download unten.
Testaufbau
Ein Chirp-Testsignal (300 Hz → 3000 Hz, 2 Sekunden bei 48 kHz) läuft durch Throttle + buffered_probe. Statt kontinuierlich abzufragen, wird — wie in der echten Kivy-Anwendung — nur alle 50 ms gepollt (Clock.schedule_interval-Rate aus dem Kivy-Frontpanel-Projekt). Alle abgeholten Häppchen werden zu einem Gesamtsignal zusammengesetzt und mit dem Original verglichen.
=== Block-Parameter (buffered_probe) ===
max_len (Puffergrenze): 480000
Poll-Rate (wie main.py: Clock.schedule_interval): 20.0 Hz
Anzahl Polls mit Daten: 12
total_in_count(): 96000
rekonstruierte Laenge: 96000
Original-Laenge: 96000
=== Signaltreue ===
verglichene Samples: 96000
RMS-Fehler: 0.00e+00
Maximaler Fehler: 0.00e+00
(Werte im Bereich der float32-Rechengenauigkeit = verlust- und lückenlos)
=== Block-Parameter (buffered_probe) ===
max_len (Puffergrenze): 480000
Poll-Rate (wie main.py: Clock.schedule_interval): 20.0 Hz
Anzahl Polls mit Daten: 12
total_in_count(): 96000
rekonstruierte Laenge: 96000
Original-Laenge: 96000
=== Signaltreue ===
verglichene Samples: 96000
RMS-Fehler: 0.00e+00
Maximaler Fehler: 0.00e+00
(Werte im Bereich der float32-Rechengenauigkeit = verlust- und lückenlos)
Einordnung: warum die Poll-Größen überraschen
Erwartet wurden bei 48 kHz und 20 Hz-Polling im Schnitt ca. 2400 Samples pro Abfrage. Tatsächlich liefern die meisten Polls 0 Samples, dafür alle paar Zyklen ein Schub von genau 8191–8192 Samples.
buffered_probe, sondern an GNU Radios interner Standard-Puffergröße (8192 Items): Throttle gibt Daten nicht gleichmäßig Sample für Sample weiter, sondern in Schüben, sobald ein interner Block-Puffer voll ist. Separat mit einer einfachen Poll-Schleife nachgemessen — 20 Abfragen im 50-ms-Takt: 0, 0, 8192, 0, 0, 8191, 0, 0, 8192, 0, 0, 8191, 0, 0, 8192, 0, 0, 0, 8191. Das Muster deckt sich exakt mit 96000 Samples ÷ 8192 ≈ 11,7 Schüben. Für buffered_probe ist das unerheblich — es puffert ja gerade für diesen Fall —, aber wichtig für die Erwartungshaltung, wie granular GNU-Radio-Daten tatsächlich beim Poller ankommen: nicht als gleichmäßiger Strom, sondern in Schüben fester interner Puffergröße.Vergleich mit den eingebauten Alternativen
Probe Signal Vector |
Vector Sink |
buffered_probe (eigen) |
|
|---|---|---|---|
| Verhalten | behält nur den letzten Block | akkumuliert alles, unbegrenzt | akkumuliert alles, bis max_len |
| Thread-Sicherheit | offiziell dokumentiert | nicht dokumentiert | selbst gebaut, per Stresstest verifiziert |
| Speicherwachstum | konstant (fester vlen) |
unbegrenzt ohne manuelles reset() |
begrenzt, älteste Samples fallen bei Überlauf weg |
| Geeignet für | Live-Anzeige (aktueller Schnappschuss) | kurze, kontrollierte Aufzeichnungen | Auswertung über mehrere Blöcke hinweg, ohne Daten zu verlieren |
Ein zusätzlicher, nicht abgebildeter Nebenläufigkeits-Stresstest (separater Poll-Thread ohne Pause, während GNU Radio parallel schreibt) bestätigt über ~197.000 Samples: keine Exception, keine verlorenen oder duplizierten Samples, keine Lücken — genau die Garantie, die bei Vector Sink nicht offiziell dokumentiert ist.
Download
python3 test_buffered_probe.py # Pass/Fail-Tests
python3 test_buffered_probe_signal.py # Signaltreue-Analyse + PNG
python3 test_buffered_probe.py # Pass/Fail-Tests
python3 test_buffered_probe_signal.py # Signaltreue-Analyse + PNG