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.
=== Signaltreue ===
verglichene Samples: 96000
RMS-Fehler: 0.00e+00
Maximaler Fehler: 0.00e+00
(Werte im Bereich der float32-Rechengenauigkeit = verlust- und lückenlos)

</div>
## 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.
<div class="info box">Das liegt nicht an <code>buffered_probe</code>, sondern an GNU Radios interner Standard-Puffergröße (8192 Items): <code>Throttle</code> 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: <code>0, 0, 8192, 0, 0, 8191, 0, 0, 8192, 0, 0, 8191, 0, 0, 8192, 0, 0, 0, 8191</code>. Das Muster deckt sich exakt mit 96000 Samples ÷ 8192 ≈ 11,7 Schüben. Für <code>buffered_probe</code> 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.</div>
## Vergleich mit den eingebauten Alternativen
<div class="table-scroll table-striped">
| | `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 |
</div>
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
<div class="good box"><strong>Download:</strong> Implementierung, alle Tests und der GRC-Demo-Flowgraph als ZIP —
<a href="/assets/downloads/buffered-probe-block-test.zip">buffered-probe-block-test.zip</a> herunterladen, entpacken, dann:
```bash
python3 test_buffered_probe.py # Pass/Fail-Tests
python3 test_buffered_probe_signal.py # Signaltreue-Analyse + PNG

</div>
## 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.
<div class="info box">Das liegt nicht an <code>buffered_probe</code>, sondern an GNU Radios interner Standard-Puffergröße (8192 Items): <code>Throttle</code> 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: <code>0, 0, 8192, 0, 0, 8191, 0, 0, 8192, 0, 0, 8191, 0, 0, 8192, 0, 0, 0, 8191</code>. Das Muster deckt sich exakt mit 96000 Samples ÷ 8192 ≈ 11,7 Schüben. Für <code>buffered_probe</code> 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.</div>
## Vergleich mit den eingebauten Alternativen
<div class="table-scroll table-striped">
| | `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 |
</div>
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
<div class="good box"><strong>Download:</strong> Implementierung, alle Tests und der GRC-Demo-Flowgraph als ZIP —
<a href="/assets/downloads/buffered-probe-block-test.zip">buffered-probe-block-test.zip</a> herunterladen, entpacken, dann:
```bash
python3 test_buffered_probe.py # Pass/Fail-Tests
python3 test_buffered_probe_signal.py # Signaltreue-Analyse + PNG