# FunkBrücke FB2-Übertragungsschicht

Stand: 2026-06-25
Dokumentversion: 0.9.332

## Ziel

`FB2` ist die neue Standard-Übertragungsschicht für FunkBrücke. Neue Funktionen werden in FB2/FB2L umgesetzt. `FB1` ist nur noch Altbestand im Projekt und bekommt keine neuen Protokollfunktionen mehr.

`FB2` definiert:

- gemeinsame Moduskennung für alle Paketarten,
- kompakte Link-Kurzpakete zwischen direkten Mesh-Nachbarn,
- automatische Wahl von bestem Hop und Ersatz-Hop,
- adaptive Rückschaltung auf robustere Modi bei Fehlern,
- Modusleiter bis OFDM.

Ab `v0.9.329` wird diese Grenze neu gezogen: FB2/FB2L ist der Zielstandard. Alte FB1-Pfade dürfen noch vorhanden sein, werden aber nicht mehr erweitert.

Ab `v0.9.183` steht in der Hauptansicht zuerst der neue Tab `Einfach`. Er ändert keine FB2-Protokollgrenze, sondern macht den normalen Nachrichten- und Empfangsfluss sichtbarer, während die FB2-MVP-Prüf- und Abnahmepfade weiter im Mesh-/FB2-Bereich bleiben.

Ab `v0.9.323` besitzt FB2 zusätzlich einen einheitlichen Nutzdaten-Umschlag für Direkt-, Mesh- und Steuerpakete:

```text
FB2|TYP|SEQ|ABSENDER>HOP1,HOP2,ZIEL|DATEN
```

`TYP` ist kurz gehalten: `D` Daten, `M` Modus, `H` Hop-Bestätigung, `A` Ende-zu-Ende-Bestätigung, `N` NACK, `F` Datei und `E` Fehler. Der erste unmarkierte Eintrag nach `>` ist der nächste Hop, der letzte Eintrag ist das Endziel. Beim Weiterleiten bleibt der ursprüngliche Absender erhalten; der durchlaufene Hop wird mit `*` markiert. Für die Modus-Aushandlung sind kompakte Inhalte vorgesehen, zum Beispiel `?2a` für Modus 2 testen, `+2a` für bestätigt, `-2a` für abgelehnt und `!2a` für festlegen.

Ab `v0.9.324` ist `BAKE` ein technischer Empfänger und ausdrücklich nicht identisch mit `ALLE`. `ALLE` bleibt Nutzerrundruf und kann im Chat erscheinen. `BAKE` wird nicht im Chat angezeigt und nicht weitergeleitet. Eine technische Bake nutzt den Umschlag `FB2|M|SEQ|ABSENDER>BAKE|B;...` und trägt eigene Stationsdaten sowie direkte Nachbarn:

```text
FB2|M|17|DO1FFE/P>BAKE|B;V=09324;L=JO31MK;M=2;R=DB0NFB:2:96;Q=Kamen;N=Erik;T=FT-991A;A=Endfed;G=96
```

Pflichtfelder sind `B`, `V`, `L`, `M` und `R`. Optional sind `Q` für QTH, `N` für Name, `T` für TRX, `A` für Antenne und `G` für eigene Qualitätsangabe. Wer eine gültige Bake empfängt, aktualisiert Mesh/Monitor/FB2L und kann anschließend direkt mit dem Bake-Absender eine Modus-Aushandlung starten, zum Beispiel `FB2|M|18|DB0NFB>DO1FFE/P|?2a`.

Ab `v0.9.325` stellt der Paketmonitor diese technischen Inhalte als kompakte Karten dar. Normale Nachrichten, technische Baken, Modus-Kurzbefehle, Hop-Bestätigungen, Ende-zu-Ende-Bestätigungen, NACKs, Datei- und Fehlerumschläge bekommen verständliche Statuszeilen. Lange Base64- oder Binärdaten werden dabei nicht ausgeschrieben, sondern nur als `DATA=... Byte/kByte` angezeigt. Der Chat bleibt weiterhin auf echte Nachrichten an die eigene Station oder `ALLE` beschränkt.

Ab `v0.9.328` behält ein weitergeleiteter FB2-Mesh-Umschlag immer den ursprünglichen Absender. Ein Hop, der das Paket bereits verarbeitet hat, wird im Pfad mit `*` markiert. Aus `DO1FFE/P>DB0NFB,DL1ABC,DK5XYZ|Text` wird bei DB0NFB also `DO1FFE/P>DB0NFB*,DL1ABC,DK5XYZ|Text`. Der nächste Hop ist der erste unmarkierte Pfadeintrag; das Endziel bleibt der letzte Pfadeintrag ohne Markierung.

Kurze FB2-BAKEN können ab `v0.9.328` zusätzlich ein kompaktes `X=`-Feld enthalten. Darin stehen wenige ausgewählte Topologie-Deltas wie `DL1ABC>DK5XYZ:2:91:220:3:2`: von Station, zu Station, Modusnummer, Qualität, Latenz, Verlust und Hop-Tiefe. Routinemäßig werden nur zwei solche Linkmeldungen pro Bake übertragen. Dadurch können Nachbarn-von-Nachbarn bis zur Sechs-Hop-Grenze in die Routenberechnung einfließen, ohne die Frequenz dauerhaft mit vollständigen Topologietabellen zu belasten.

Für spätere Laufzeitmessungen gibt es außerdem einen versteckten technischen Mesh-PING. Eine Anfrage wird als `Ping`, die Antwort als `Pong` in der Mesh-Nutzlastart geführt. Die Nutzlast selbst nutzt ein kurzes `P1|...`-Format mit Ping-ID und Millisekunden-Zeitstempeln. Sobald eine Antwort zurückkommt, kann daraus eine RTT-Anzeige berechnet werden; normale Chatnachrichten bleiben davon getrennt.

Ab `v0.9.329` ist dieser PING/PONG-Baustein im FB2-Core produktiv gekoppelt. Ein empfangener PING wird am Ziel automatisch mit PONG beantwortet. PONG ist Steuerverkehr und erzeugt keine weitere ACK-Kette. Hohe ACK-/RTT-Zeiten fließen als Abwertung in die adaptive Moduswahl ein, damit träge Links nicht unnötig aggressiv hochgeschaltet werden. Gültige FB2-BAKEN übernehmen ihre `X=`-Topologie-Deltas in die lokale Mesh-Tabelle, und FB2L meldet Links zusätzlich mit `rttMs`, `alterSekunden` und `topologieDelta` an die Webkarte.

Ab `v0.9.330` gilt FB2/FB2L auch im zentralen Protokollstand als Zielstandard. FB1 ist Altbestand und wird nicht mehr erweitert. Öffentliche Download-Artefakte verweisen deshalb auf FB2-Übertragung, FB2-Frequenzprofile und den FB1-Abbauplan. Überalterte Topologie-Deltas werden beim Karten- und Routingimport verworfen, damit abgelaufene Nachbarinformationen keine scheinbar gültigen Routen erzeugen. Die Mesh-Karte zeigt Linkalter und Latenz/RTT gemeinsam in den Verbindungsdetails.

Ab `v0.9.331` begrenzt auch der FB2L-Web-Heartbeat frische Funklinks hart auf die zentrale FB2-Link-TTL von 300 Sekunden. Ein älterer Aufrufer kann dadurch nicht versehentlich Links mit 30 Minuten Alter als aktiv an die Webkarte melden. Stationen dürfen serverseitig weiterhin grau nachlaufen; Links laufen jedoch nach TTL aus.

Ab `v0.9.332` trennt die FB2-Nachbarmodus-Aushandlung den getesteten Nutzmodus vom Antwortmodus. Eine Probe wird direkt in dem Modus gesendet, der geprüft werden soll, zum Beispiel 8-FSK oder 16-MFSK. Die erste Bestätigung kommt robust in 2-FSK zurück, solange für die Gegenrichtung noch kein Rückweg bestätigt ist. Dadurch gilt nach der Antwort nur der Hinweg als schneller Nutzpfad; der Rückweg wird separat gelernt und später eigenständig hochgeschaltet. Die Steuerdaten enthalten dafür zusätzlich `A=` als Antwortmodus. Antwort-Timeouts bleiben kurz: 15 Sekunden bei direktem Nachbarn, mit kleinem Hop-Zuschlag bis höchstens 60 Sekunden.

Ab `v0.9.327` ist der FB2-Umschlagpfad stärker an den produktiven Mesh-Betrieb gekoppelt. Mehrfach-RX unterscheidet sichere getrennte Rahmen von Diagnosefällen, FSK-Zufallsversätze sind zentral geregelt, Hop-ACKs werden vor Nutzdaten priorisiert, und Ende-zu-Ende-ACKs schließen Aufträge nur bei passender Paket-ID, Ursprung und Ziel ab. Mesh-Moduspläne zeigen SNR und Frequenzabweichung direkt in der Hop-Meldung. Der Monitor kann FB2-Rahmen zusätzlich als kompakte Karten mit Route, Inhalt und Transport darstellen; große Binärdaten erscheinen nur als `DATA=...`.

Ab `v0.9.326` nutzt der normale FB2-Nachrichtenpfad den Datenumschlag `FB2|D|SEQ|ABSENDER>ZIEL|TEXT` als Standard. Empfänger zeigen daraus nur den eigentlichen Text im Chat an; technische Umschläge wie BAKE, Modusprobe, Hop-ACK oder NACK bleiben im Monitor. Gültige BAKE-Umschläge können direkt eine kurze Modusprobe `?nK` zum Bake-Absender einreihen. Eine empfangene Kurzprobe erzeugt eine kurze Antwort `+nK`, und eine empfangene Bestätigung aktualisiert den gespeicherten Hinweg. Der Umschlagpfad ist auf maximal sechs Hop-Einträge begrenzt; längere Pfade werden abgewiesen.

Ab `v0.9.184` führt dieser Einfachbetrieb Zielrufzeichen, Route und FB2-Modus zusammen. Das Ziel ist weiterhin das bestehende Mesh-Ziel und wird auch für normale FB1-Chat-Nachrichten aus dem Sendefeld verwendet. Damit nähern sich normaler Nachrichtenfluss, Mesh-Planung und spätere FB2-Moduswahl einer gemeinsamen Bedienkette, ohne die produktive FB2-TX-Sperre zu ändern.

Ab `v0.9.185` zeigt der Einfachbetrieb zusätzlich eine `Sendefreigabe` als Bedienhilfe. Sie bewertet Kanal-frei-Prüfung, FB1-Horchfenster, Audio-RX, Ziel, Route, Modus, PTT/Sendemotor, Audioausgang, Warteschlange und Sendesicherheit. Die verbindliche Kanalprüfung bleibt weiterhin direkt vor TX im Sendemotor; produktive FB2-Automatik wird dadurch nicht geöffnet.

Ab `v0.9.186` führt der Einfachbetrieb diese Bedienhilfe als Schritt-für-Schritt-Pfad weiter. Seit `v0.9.234` wird daraus im normalen Direktbetrieb `Automatik prüfen`: Kanal-frei-Prüfung und FB1-Horchfenster aktivieren, Audio-RX starten, Ziel/Route/Modus/Audio prüfen und fällige Warteschlangenaufträge automatisch nach Vor-TX-Prüfung abarbeiten.

Ab `v0.9.187` zeigt der Einfachbetrieb zusätzlich eine `QSO-Lage`. Sie fasst Empfangserwartung, ACK/NACK-Stand und Wiederholhinweis aus Warteschlange und ARQ-Sendefenster zusammen. Damit ist nach dem Senden ohne Detailtab sichtbar, ob ein ACK/NACK erwartet wird, ob eine Wiederholung vorbereitet ist oder ob das Versuchslimit erreicht wurde. Seit `v0.9.234` ist diese Lage an die Warteschlangen-Sendeautomatik angebunden.

Ab `v0.9.194` führt der Einfachbetrieb das erste Zwei-Stationen-QSO enger zusammen. Eine Antwortkarte bereitet ACK/NACK ohne Detailtab vor, `RX-Lage` unterscheidet erkannte FB1-/FB2-Rahmen, `QSO-Ablauf` zeigt Station-A-/Station-B-Status, der Modusplan wählt nach Paketgröße und Profil einen MVP-Modus bis 32-MFSK, und die Karte `Vor TX` zeigt die harte Sendesperre vor dem verbindlichen Horchfenster. Ab `v0.9.234` nutzt der normale Direktbetrieb diese Prüfkette als beaufsichtigte Sendeautomatik.

Ab `v0.9.201` ist der Einfachbetrieb stärker an den beaufsichtigten FB2-MVP-Zwei-Stationen-Pfad angebunden. Empfangene Pakete können als `QSO-Fall` geöffnet werden, ACK/NACK bekommt einen sichtbaren Rückweg, Station A/B ist direkt wählbar, normale ACK-pflichtige Nachrichten können als FB2-MVP-Testauftrag gekoppelt werden, gültige FB2-Paketrahmen erscheinen als Nutzdaten in der Nachrichtenliste und `FB2-QSO-Pfad` zeigt Auftrag, Kopplung, harte Freigabe, Einzelschuss, Gegenstations-RX und ACK/NACK-Zuordnung als Prüfkette. Seit `v0.9.234` gilt für den normalen Direktpfad: Warteschlange statt Sendeklick, Sendeautomatik statt manueller TX.

Ab `v0.9.208` ist der normale Nachrichtenpfad im Einfachbetrieb erstmals ein echter `FB2`-Nutzdatenpfad. Der Warteschlangenauftrag trägt den Typ `FB2`, enthält einen gültigen `FB2|...`-Rahmen mit Paketkopf, Modus, Sequenz, Absender, Empfänger, Nutzdaten und CRCs und wird vom Sendemotor als beaufsichtigter FB2-Audiozweig behandelt. Eingehende FB2-Paketrahmen werden einer Gegenstation und Sequenz zugeordnet; eingehende `FB2-MVP-ACK`-/`FB2-MVP-NACK`-Steuerrahmen schließen passende offene Direktaufträge sichtbar ab. Seit `v0.9.234` reiht FunkBrücke bei direktem Ziel an die eigene Station automatisch OK ein; Broadcasts, eigene Echos und fremde Ziele werden nicht automatisch beantwortet.

Ab `v0.9.215` besitzt dieser Direktpfad eine lokale Zwei-Stationen-Prüfung und eine einfachere Bedienoberfläche. Die Prüfung erzeugt ein FB2-Paket von Station A nach B, demoduliert es lokal, erzeugt ein FB2-ACK von B nach A und prüft diese Rückmeldung gegen Sequenz, Richtung und CRC, ohne PTT oder Audioausgabe. Die Moduswahl ist als `robust`, `normal` und `schnell` dargestellt, bleibt aber an Betriebsprofil und unterstützte Modi gebunden. Nach FB2-NACK oder erkanntem Timeout kann derselbe Rahmen erneut vorbereitet werden; ab `v0.9.234` übernimmt die Sendeautomatik diese eindeutige Wiederholung. RX-Zuordnung und Feldtestprotokoll nennen direkte Pakete, Broadcasts, eigene Echo-Rahmen, fremde Ziele, Steuerrahmen und defekte FB2-Rahmen getrennt.

Ab `v0.9.222` ist der Direktpfad für zwei laufende Programminstanzen vorbereitet. Das eigene Rufzeichen wird aus dem Profil übernommen. FunkBrücke kann Station-A- und Station-B-Profile erzeugen, einen gemeinsamen lokalen Austauschordner anlegen und FB2-Rahmen als `.fb2.txt` exportieren oder importieren. Ein importierter Rahmen läuft durch dieselbe RX-Zuordnung wie ein empfangener FB2-Rahmen. Dadurch kann der Ablauf Paket, Nutzdatenprüfung, ACK/NACK-Vorbereitung und Rückmeldungszuordnung ohne HF und ohne PTT getestet werden. Hardwarecheckliste, geführter Funkversuch und Fehlerhilfe sind Bedienhilfen; die ab `v0.9.234` verfügbare Automatik bleibt an Warteschlange, Kanalprüfung, Horchfenster und Sicherheitsregeln gebunden.

Ab `v0.9.249` ist diese eigene Stationskennung im Profil vollständiger beschrieben. Das Rufzeichen bleibt die technische Adresse im Direkt- und Mesh-Betrieb; Operatorname, mindestens sechsstelliger Locator, Standort/QTH, TRX, Antenne und Zusatzangaben sind ergänzende Stationsdaten für Bedienung, Feldtest und spätere Nachbarbewertung. Der Locator wird auf eine sechsstellige Maidenhead-Grundform geprüft.

Ab `v0.9.250` übertragen Mesh-Statuspakete zusätzlich ein kompaktes Stationsprofil. Die Oberfläche kann daraus eine Mesh-Karte erzeugen: bekannte Stationen erscheinen anhand 6-, 8- oder 10-stelliger Locator, Links zeigen den zuletzt gemeldeten Modus und die beste Route wird aus frischen Links berechnet. Ab `v0.9.251` ist diese Karte in der Bedienungsanleitung dokumentiert und besitzt eine lesbare Stationsliste mit Suche. Ab `v0.9.252` läuft die Umwandlung empfangener Statuspakete in Karten- und Routinglinks über eine gemeinsame Core-Kopplung, damit Profil, Nachbarmodus, Erreichbarkeit und Karte denselben Pfad nutzen.

Ab `v0.9.223` ist die lauffähige Moduswahl für den Direktpfad als Core-Entscheidung testbar. `robust`, `normal` und `schnell` wählen nur Modi, die sowohl im Betriebsprofil erlaubt als auch technisch im MVP-Modem unterstützt sind. Dadurch bleiben SSB-Profile schmal, FM normal nutzt bis 16-MFSK und das breite Laborprofil kann bis 32-MFSK gehen. Zusätzlich ist der Austausch über `.fb2.txt`-Dateien mit Paket und Antwort als Testfall abgesichert. Die Oberfläche zeigt diesen Ablauf stärker als Senden, Empfangen und Antwort; die technischen CRC- und Steuerrahmendetails bleiben im Hintergrund und in Diagnose/Protokoll erhalten.

Ab `v0.9.224` ist dieser Zwei-Instanzen-Pfad stärker gegen Bedienfehler geschützt. Exportierte `.fb2.txt`-Dateien enthalten lesbare Metadaten zu Softwarestand, Richtung, Art, Sequenz, Modus und CRCs, bleiben aber weiter als FB2-Rahmen dekodierbar. Beim Import werden eigene Exporte, bereits gelesene Dateien, Rahmen mit eigenem Absender und Dateien mit falschem Zielrufzeichen übersprungen. Die Oberfläche zeigt zusätzlich eine sechsstellige Schrittfolge und die nächste Aktion. Für echte Funkversuche nennt die Checkliste Frequenz, Betriebsart, Leistung, Rolle und Abbruchregel; die Moduswahl weist sichtbar auf die 32-MFSK-Grenze hin.

Ab `v0.9.225` wird der Direktpfad näher an ein bedienbares QSO gebracht. `FB2-Direkt` zeigt den Fahrplan Text, Paket, Kanalprüfung, TX, RX und Antwort mit dem nächsten Bediengriff. Die Moduswahl nennt neben der Strategie auch Bitrate, geschätzte Signalbreite und Profilfreigabe bis 32-MFSK. Die RX-Seite meldet für gültige und verworfene FB2-Rahmen explizit Marker, Paketgrenze, Kopf-CRC, Nutzdaten-CRC, Ziel und OK/Wiederholen-Zuordnung. Der lokale Paket-/Antwort-Prüflauf läuft außerhalb des UI-Klicks, damit die Bedienoberfläche nicht durch Modulation und Demodulation blockiert.

Ab `v0.9.226` werden die operativen Anzeigen enger an den echten Direktbetrieb gebunden. Der QSO-Abschluss ist ein eigener Zustand und wird erst bei einer passenden OK-Rückmeldung geschlossen; Wiederholen bleibt offen und manuell. Der Dauer-RX meldet im Einfachbetrieb, ob er Audio sammelt, horcht, Treffer übernimmt oder Duplikate überspringt. Der Sendemotor meldet für FB2 getrennt Vor-TX, Horchfenster, Audioerzeugung, PTT-Lauf und Abschluss. Für den Zwei-Instanzen-Test steht eine kurze A/B-Bedienfolge bereit, damit der Datei-Austausch nicht mit Funkbetrieb verwechselt wird.

Ab `v0.9.227` ist dieser Direktpfad intern als eigener QSO-Zustand modelliert. Gespeichert werden Sequenz, eigene Station, Gegenstation, Modus, Nutzdaten-CRC, erwartete Antwort, letzter RX und Abschlussstatus. Jeder eingehende FB2-Rahmen wird vor der Bedienlogik klassifiziert: Nutzdaten, OK, Wiederholen, eigenes Echo, falsches Ziel, Duplikat, alte Sequenz, fremdes QSO oder beschädigt. Dadurch wird der Zwei-Instanzen-Rundlauf A schreibt, B liest, B antwortet und A schließt ab als Core-Test abgesichert und in der Oberfläche als eigener Rundlaufstatus sichtbar.

Ab `v0.9.228` wird der laufende Audioeingang vor der automatischen FB2-Dauer-RX-Suche bewertet. Stumme oder zu schwache Puffer werden nicht mehr durch alle MFSK-Modi demoduliert. Dadurch bleibt der FB2-Auto-RX weiterhin empfangend und profilbewusst bis 32-MFSK, vermeidet aber unnötige CPU-Last, solange kein auswertbares Signal anliegt. Der Zwei-Fenster-Rundlauf ist zusätzlich als zentrale Vier-Schritt-Struktur dokumentiert und getestet: A schreibt, B liest, B antwortet, A liest zurück.

Ab `v0.9.229` bekommt dieser Direktpfad eine klarere Abnahmebasis. Der Zwei-Fenster-Rundlauf meldet nun laufend, bestanden oder fehlgeschlagen. Die lokale FB2-Kette ohne HF ist für 4-FSK, 8-FSK, 16-MFSK und 32-MFSK mit Paket, OK, Wiederholen und beschädigten Audiopuffern testseitig abgesichert. Der FT-991A-Praxistest führt bis FB1-/FB2-Horchfenster, FB2-Trockenauftrag, Protokoll und Abbruchregel. Der erste echte Zwei-Stationen-Versuch wird als sieben geführte Prüfschritte vorbereitet, bleibt aber weiterhin beaufsichtigt und ohne automatische PTT, Wiederholung oder Mesh-Weiterleitung.

Ab `v0.9.230` ist diese Abnahmebasis auch in der Bedienung klarer sichtbar. Der Zwei-Fenster-Test zeigt vier Schrittzeilen mit Status und nächster Aktion. Die FB2-Audioprüfung läuft praxisnäher mit Vorlauf/Nachlauf für Paket und OK-Antwort durch die automatische Modussuche bis 32-MFSK. Der FT-991A-Praxistest zeigt den ersten Blocker oder nächsten offenen Schritt als Fokuspunkt; der Zwei-Stationen-Funkversuch führt seine sieben Pflichtnachweise sichtbar mit. Alle Punkte bleiben ohne automatische PTT, ohne automatische Wiederholung und ohne Mesh-Weiterleitung.

Ab `v0.9.231` ist der Live-RX-Pfad als eigene Praxiskette sichtbar. FunkBrücke bewertet Audioquelle, TX-Sperre, Suchmodi, Suchfenster, Decoder, RX-Übernahme und Mesh-Andockpunkt getrennt. Der Decoder läuft weiterhin gedrosselt im Hintergrund und überspringt stumme Fenster. Gültige FB2- und FB2L-Treffer werden in den bestehenden RX-Pfad übernommen und zusätzlich für Mesh-Beobachtung/Nachbartabelle angedockt. Daraus entsteht noch keine produktive Mesh-Weiterleitung; Mesh-TX und Mesh-Antworten bleiben separate Freigabeschritte.

Ab `v0.9.232` wird dieser Empfangspfad mit dem beaufsichtigten Zwei-Stationen-Rundlauf verbunden. Die neue Livepraxis bewertet Sicherheit, RX-Kette, Test-TX, Gegenstations-RX, ACK/Wiederholen-RX, Auftragsbindung und Mesh-Beobachtung als sieben getrennte Nachweise. Ein Gegenstations-RX muss zu Sequenz, Richtung, Modus und Nutzdaten-CRC des Test-TX passen. Ein ACK/NACK-Steuerrahmen zählt erst nach Dekodierung und bestätigter Auftragsbindung. Mesh-Beobachtung bleibt sichtbar, erzeugt aber weiterhin keinen Weiterleitauftrag.

Ab `v0.9.233` wird derselbe Pfad im Einfachbetrieb als normaler Gesprächsfluss bedienbar. Der Block `FB2 senden/empfangen` zeigt nicht zuerst die Protokolldiagnose, sondern Status, nächsten Bediengriff und zwei kontextabhängige Aktionen. Seit `v0.9.234` sind diese Aktionen an den Automatikfluss gekoppelt: RX starten, Nachricht in die Warteschlange legen, Sendeautomatik prüfen, OK automatisch einreihen, Wiederholung vormerken, erneut prüfen oder bei laufender Sendung Not-Aus anbieten. Die technischen Detailanzeigen bleiben unter `Technik und Diagnose` erhalten.

Ab `v0.9.234` wird dieser Gesprächsfluss als Automatikpfad geführt. Die Nutzerhandlung endet im Normalfall beim Einreihen in die Warteschlange. Danach prüft FunkBrücke Audio-RX, Kanalprüfung, FB1-Horchfenster, Sendesicherheit und Audioausgang, startet den Sendemotor automatisch, kehrt zu RX zurück, reiht ein gültiges direktes FB2-OK selbst ein und bereitet eindeutige Wiederholungen über dieselbe Warteschlange vor. Broadcasts, eigene Echos und fremde Ziele erzeugen keine automatische Direktantwort.

Ab `v0.9.235` ist dieser Automatikpfad zusätzlich abgesichert. Ein Core-Modell bewertet die Sendeautomatiklage und liefert Status, nächste Aktion und Wartezeit für PTT, CAT, laufenden Sendemotor, Startnachladung, fehlenden Auftrag, Audio, FB1-Horchfenster und Sendesicherheit. Der Auto-OK-Rückweg erzeugt einen geprüften FB2-Steuerrahmen mit korrekter Richtung, Sequenz, Kopf-CRC, Nutzdaten-CRC und `AUTOMATIK=WARTESCHLANGE`. Wiederholungen werden über eine eigene Regel pro Sequenz auf drei automatische Vormerkungen begrenzt; ein bereits bereiter Wiederholauftrag erhöht den Zähler nicht.

Ab `v0.9.236` ist der direkte FB2-QSO-Nachweis nicht mehr nur ein Rahmenrundlauf. Eine neue Audiotransport-Abnahme erzeugt aus dem Warteschlangenauftrag echte Samples, empfängt sie bei der Gegenstation, erzeugt das automatische OK als FB2-Steuerrahmen, sendet auch dieses OK durch die Audiokette zurück und schließt den Auftrag bei Station A. Der geprüfte praktische Bereich umfasst 2-FSK robust, 4-FSK, 8-FSK, 16-MFSK und 32-MFSK. Eine zusätzliche Core-Regel sperrt vor TX nicht fällige Aufträge, unbekannte Rahmen, ungültige FB2-Rahmen und FB2-Modi, die für automatische Audio-TX nicht implementiert sind.

Ab `v0.9.237` ist der direkte FB2-Automatikpfad als eigener Ablaufzustand abgesichert. Die Core-Regel unterscheidet RX vorbereiten, aktiv empfangen, Warteschlangenauftrag prüfen, Antwort senden, laufende Sendung, offene Antwort, fällige Wiederholung und Sperrlage. Der App-Sendemotor wird bei Warteschlangenänderungen entprellt gestartet, offene Direkt-QSOs werden im Automatik-Takt auf Timeout geprüft, und fremde FB2-Ziele werden als Mesh-Kandidaten mit Route, nächstem Hop, Hop-Limit, Duplikatschutz und produktiver Freigabe bewertet. Die automatische FB2-Mesh-Nutzdatenweiterleitung bleibt ohne Freigabe gesperrt.

Ab `v0.9.238` ist diese Mesh-Freigabe als eigene Prüfkette modelliert. Nach der Vorentscheidung muss ein späterer produktiver Ausgangskorb zusätzlich Feldnachweis, bewusste Bedienfreigabe, Kanal-frei-Prüfung, FB1-Horchfenster, Sendesicherheit sowie freie PTT- und Sendemotorlage erfüllen. Die Oberfläche nutzt diese Bewertung bereits als Sperrdiagnose für fremde FB2-Ziele; sie erzeugt weiterhin keinen automatischen produktiven Mesh-Auftrag.

Ab `v0.9.239` wird der Feldnachweis als eigenes lokales FB2-Objekt behandelt. Mesh-tauglich ist er nur bei vollständigem QSO, echter Funkstrecke und bestätigter Testleitung. Die Mesh-Freigabe vergleicht diesen Nachweis mit eigener Station und nächstem Hop; fehlt er, bleibt der spätere Ausgangskorb gesperrt.

Ab `v0.9.240` ist dieser Feldnachweis im normalen FB2-Gesprächsbereich bedienbar. Ein technisch eindeutiges Paket-/OK-Paar erzeugt einen Vorschlag; Speichern bleibt bewusst und verlangt die Bestätigung, dass der Versuch tatsächlich über Funk und beaufsichtigt lief. Der Mesh-Bereich zeigt die Feldnachweis-Lage zusätzlich direkt bei der Weiterleitungsbewertung.

Ab `v0.9.241` kann diese Freigabekette erstmals produktiv einen FB2-Mesh-Auftrag in die Warteschlange legen. Dafür müssen Bedienfreigabe, Feldnachweis zum nächsten Hop, Route, Kanalprüfung, FB1-/FB2-Horchfenster, Sendesicherheit und freie TX-Lage passen. Der automatische Mesh-Pfad ist auf 2-FSK robust, 4-FSK, 8-FSK und 16-MFSK begrenzt. Empfangene FB2-Mesh-Pakete werden vor der Direkt-QSO-Logik erkannt, aber nur von der als nächster Hop adressierten Station aktiv verarbeitet.

Ab `v0.9.242` läuft die Zustellbestätigung im FB2-Mesh als eigene Mesh-Nutzlast zurück zum ursprünglichen Absender. Die Zielstation erzeugt eine `Zustellbestaetigung`, der Rückweg wird mit derselben Route-/Feldnachweis-/Freigabekette eingereiht, und der Ursprung markiert den offenen Mesh-Auftrag erst beim eintreffenden Rückweg-ACK als zugestellt. Steuer-Nutzlasten erzeugen keine ACK-auf-ACK-Kette. Bereits besuchte Stationen werden bei der Routenwahl vermieden; erkennt eine Station sich selbst im Pfad, wird das Paket als Schleife gesperrt.

Ab `v0.9.243` ist der Rückweg nicht mehr nur als Core-Entscheidung vorhanden, sondern als kompletter Praxisrundlauf abgesichert. Der Testpfad führt `DO1FFE/P -> DB0NFB -> DK5XYZ` und danach die Zustellbestätigung `DK5XYZ -> DB0NFB -> DO1FFE/P` als echte FB2-Mesh-Rahmen aus. Eine zweite Abnahme führt dieselbe Kette durch den Audio-Modempfad und deckt 2-FSK robust, 4-FSK, 8-FSK und 16-MFSK ab. Zusätzlich sind `FB2-MESH-ACK` und `FB2-MESH-FEHLER` als Steuerverkehr priorisiert; ACK-Timeout, Hin-/Rückweg-Feldnachweis und Ersatzroute sind als eigene Regeln modelliert.

Ab `v0.9.244` nutzt der App-Ausgangskorb diese Regeln im laufenden Betrieb. Eigene FB2-Mesh-Nutzdaten werden als offene Live-Zustellung geführt, ACKs und Fehlerantworten schließen den Auftrag ab, und fällige Timeouts erzeugen je nach Bewertung einen `FB2-MESH-RETRY` über Primär- oder Ersatz-Hop. Vor dem Einreihen prüft FunkBrücke dieselbe Freigabekette wie bei normaler Mesh-Weiterleitung: Feldnachweis, bewusste Bedienfreigabe, Kanalprüfung, FB1-/FB2-Horchfenster, Sendesicherheit und freie TX-Lage.

Ab `v0.9.245` erzeugt die FB2-Mesh-Automatik bei harten Weiterleitungsfehlern eine echte Fehlerantwort als Mesh-Nutzlast `Fehler`. Hop-Limit/TTL, Schleifen und fehlende Zielroute werden als `FB2-MESH-FEHLER` zurück zum Ursprung eingereiht, sofern der Rückweg freigegeben ist. Steuer-Nutzlasten wie Zustellbestätigung und Fehler erzeugen keine weitere ACK- oder Fehlerkette. Der Live-Ausgangskorb wiederholt den ersten ACK-Timeout über den Primärweg und nutzt eine unabhängige Ersatzroute erst ab dem zweiten fälligen Timeout.

Ab `v0.9.246` ist der sichtbare Praxisrundlauf auf sechs Funkhops erweitert. Die Referenzkette lautet `DO1FFE/P -> DB0NFB -> DL1ABC -> DK5XYZ -> DL2XYZ -> DB0TEST -> DF1ZIEL`; der Rückweg läuft als `FB2-MESH-ACK` über dieselben sechs Hops zurück. Zusätzlich sind Hop-Limit/TTL, fehlende Zielroute, Schleifenerkennung und fehlende Kanalprüfung auf diesem langen Pfad testseitig abgesichert.

Ab `v0.9.247` ist der direkte FB2-Automatikpfad als kompletter Zwei-Instanzen-Audio-QSO geprüft. Station A erzeugt aus der Warteschlange ein FB2-Paket, der Sendemotor läuft erst nach Automatik-, Kanal-, Horchfenster- und Sicherheitsprüfung, Station B empfängt das Paket über den Audiodecoder, erzeugt automatisch ein OK, sendet dieses OK über denselben Audioweg zurück und Station A schließt das QSO ab. Dieser Nachweis läuft über 2-FSK robust, 4-FSK, 8-FSK, 16-MFSK und 32-MFSK. Nicht sendefähige Laborstufen wie OFDM werden in der Automatik vor TX gesperrt.

Der Live-RX-Andockpunkt unterscheidet ab `v0.9.247` die tatsächliche Weiterverarbeitung: direktes QSO, Mesh-Mithören, Mesh-Weiterleitung mit vorbereitetem Warteschlangeneintrag, lokale Mesh-Zustellung, Link-Bake oder eigenes Echo. Dadurch kann die Oberfläche sichtbar zeigen, ob ein empfangener FB2-/FB2-Mesh-Rahmen nur beobachtet, lokal zugestellt oder als Weiterleitung in die Warteschlange gelegt wurde.

Ab `v0.9.248` ist die RX-/TX-Kopplung praxisnäher: bloße CAT-PTT-Freigabe blockiert den FB2-Dauer-RX nicht mehr, aktive PTT oder laufender Sendemotor dagegen schon. Nach TX werden Audio-RX, FB2-Dauer-RX und Automatikprüfung wieder angestoßen. Die Mesh-Verarbeitung prüft im Kern zusätzlich, ob der aktuelle FB2-Rahmen an die eigene Station als nächsten Hop adressiert ist; fremde Hop-Rahmen werden nur beobachtet.

Ab `v0.9.252` ist der automatische Direkt- und Mesh-Pfad weiter gehärtet. Start- und Protokollhistorien werden nicht mehr automatisch beim Fensterstart geladen, sendende FB2-Automatikfälle warten gemeinsam auf einen gültigen Audioausgang, empfangene Mesh-Statuspakete erzeugen Karten- und Routinglinks über denselben Core-Pfad, und der 6-Hop-Mesh-Praxisrundlauf prüft ausdrücklich, dass die automatische Mesh-Aussendung nur 2-FSK robust, 4-FSK, 8-FSK und 16-MFSK nutzt.

Ab `v0.9.253` bewertet eine gemeinsame Geräteprüfung den ersten FB2-Direktversuch vor dem Einreihen: Rufzeichen/Ziel, Frequenz, Betriebsart, Leistung, Audio-RX, FB2-Auto-RX, Audio-TX, Kanalwache, CAT/PTT, Sendesicherheit, Warteschlange und Abbruchregel müssen zusammen plausibel sein. Zusätzlich sperrt der FB2-Mesh-Live-Ausgangskorb automatische Wiederholungen und Ersatzrouten, solange Hin- und Rückweg-Feldnachweise fehlen. Der Nutzer bleibt dabei beim einfachen Ablauf: Nachricht einreihen, Automatik prüfen lassen, RX und Rückmeldung beobachten.

Ab `v0.9.254` ändert sich an der FB2-Funklogik nichts. Die Version vereinheitlicht Logo, Windows-Icon, Anleitung und Webseite, damit der aktuelle Prototyp als zusammengehöriges Programm erkennbar ist.

Ab `v0.9.255` ist der Praxisstart im Direktpfad eindeutiger geführt. Die Geräteprüfung bewertet nicht mehr nur allgemein bereit oder gesperrt, sondern unterscheidet Empfang bereit, Trockenlauf prüfbar und automatisches Senden bereit. Echte CAT-PTT ist ein eigener Prüfpunkt und Voraussetzung für automatisches HF-Senden. Die Vor-TX-Auftragsprüfung nennt die erlaubten Direktmodi bis 32-MFSK; OFDM und breitere Laborstufen bleiben vor dem Sendemotor gesperrt. Im FB2-Mesh-Live-Ausgangskorb wird die automatische Praxisgrenze bis 16-MFSK ausdrücklich angezeigt.

Ab `v0.9.256` wird diese Praxisstartbewertung von der App durchgängiger verwendet: Vor-TX, Fehlerhilfe, automatische Sendemotorprüfung und Feldtestprotokoll beziehen sich auf dieselbe Sicherheitslinie. FB2-Aufträge mit nur trocken prüfbarer Lage bleiben in der Warteschlange und werden nicht in den PTT-/Audio-TX-Pfad weitergereicht. Der FB2-Mesh-Live-Ausgangskorb ergänzt zu ACK-Timeout, Ersatzroute und Fehlerantwort einen normalen Bedienhinweis, damit der Nutzer zuerst den Ablauf und danach die technischen Details sieht.

Ab `v0.9.257` ist der nächste Praxisblock als Core-Bewertung vorhanden. Der Zwei-Stationen-Praxisstart verlangt gleiche Version, Frequenz, Profil und Modus, laufenden RX, aktive Kanalwache, genau einen Nutzauftrag bei Station A, Auto-OK bei Station B und keinen manuellen PTT-Eingriff. Der FT-991A-Hardwarepfad bewertet CAT, Datenbetriebsart, Leistung, PTT-Aus, Not-Aus, Audio-RX/TX, Kanalwache, echte CAT-PTT und Protokollpflicht gemeinsam. Für das Mesh gelten mesh-taugliche direkte FB2-Nachweise als bidirektionale Nachbarlinks; der A-B-C-Praxisrundlauf nutzt deshalb zwei bestätigte Nachbar-QSOs für Hinweg und Rückweg-ACK.

Ab `v0.9.258` wird diese Bewertung stärker an den normalen Bedienfluss angeschlossen. Sobald der Nutzer eine FB2-Direktnachricht in die Warteschlange legt, bereitet die App RX, Kanalprüfung und FB1-Horchfenster vor, bewertet Auto-QSO, Hardwarepfad und Zwei-Stationen-Praxisstart und zeigt das Ergebnis im Funkversuch sowie in der Livepraxis. Das direkte Feldtestprotokoll und die Feldtest-Exportübersicht enthalten diese Lage als Nachweis. `FB2-Mesh-Live` nennt außerdem direkt am offenen Auftrag, ob der bidirektionale Nachbar-Feldnachweis zum nächsten Hop vorhanden ist.

Ab `v0.9.259` werden FB2-Nutzdaten vor dem Rahmenaufbau automatisch mit Brotli in maximaler Stufe komprimiert, wenn die komprimierte Nutzlast kleiner ist als das Original. Komprimierte FB2-Rahmen verwenden Rahmenkopf-Version `2` und tragen eine Kompressionskennung; unkomprimierte Rahmen bleiben Version `1` und werden weiterhin gelesen. Die Nutzdatenlänge und Nutzdaten-CRC beziehen sich immer auf die entpackten Originaldaten, damit Empfang und Feldnachweis denselben Inhalt prüfen. Mesh-Statuspakete enthalten zusätzlich die FunkBrücke-Softwareversion, damit die Mesh-Karte gemischte Stationsstände sichtbar macht.

Ab `v0.9.260` ist die Kompressionsbilanz auch im Bedienfluss sichtbar. Der Direktpfad ist mit komprimierten Nutzdaten von 2-FSK robust bis 32-MFSK geprüft, der automatische Mesh-Pfad mit komprimierten Weiterleitungen von 2-FSK robust bis 16-MFSK. Breitere Mesh-Automatik bleibt weiterhin ein separater Feldfreigabeschritt.

Ab `v0.9.261` zeigt auch der FB2-Empfang die Kompressionsbilanz aus dem Rahmenkopf. Gültige Paket- und Steuerrahmen sowie Duplikate nennen dadurch direkt, ob die empfangenen Nutzdaten unkomprimiert waren oder komprimiert übertragen wurden.

Ab `v0.9.262` ändert sich an der FB2-Rahmenstruktur nichts. Die Bedienoberfläche ist jedoch stärker auf Hauptfenster, Gerätefenster und Detailfenster verteilt, damit Direktbetrieb, Mesh-Live-Status, Audio und Protokoll nicht mehr in einer überladenen Ansicht konkurrieren.

Ab `v0.9.263` sind Direkt- und Mesh-Kompression zusätzlich in den praxisnahen Automatikpfaden abgesichert. Der direkte Auto-QSO-Rundlauf prüft komprimierbare Nutzlast von 2-FSK robust bis 32-MFSK, und der FB2-Mesh-Audio-Rundlauf prüft komprimierte 16-MFSK-Weiterleitung mit Relais und ACK-Rückweg. Die Protokollstruktur bleibt unverändert; der Fortschritt liegt in Abnahme und Bedienbarkeit.

Ab `v0.9.264` bleibt die FB2-Rahmenstruktur unverändert. Beim Einreihen direkter FB2- und FB2-Mesh-Nachrichten bereitet die App RX, Kanal-frei-Prüfung, FB1-Horchfenster und FB2-Dauer-RX direkt vor. Der direkte Audio-Rundlauf prüft zusätzlich stark komprimierbare Nutzdaten von 2-FSK robust bis 32-MFSK. Der Mesh-Audio-Rundlauf kann den Übertragungsmodus aus der Mesh-Bewertung automatisch wählen und führt anschließend Hinweg, Relais, Zielzustellung und Rückweg-ACK über die Audiokette aus.

Ab `v0.9.265` bleibt die FB2-Rahmenstruktur ebenfalls unverändert. Die Arbeit betrifft Bedienbarkeit und Abnahme: schwere Statusketten laufen erst nach sichtbarem Fensterstart, Einstellungen und Über-Informationen liegen in eigenen Fenstern, das Automatikfenster zeigt RX, Dauer-RX, Warteschlange, Zwei-Stationen-Live und Mesh-Freigabe direkter, der Direktpfad sperrt manuelle PTT-Eingriffe, und der Audio-Rundlauf ist zusätzlich mit leicht verrauschten Signalen bis 32-MFSK abgesichert. Die Mesh-Automatikgrenze bleibt bewusst bei 16-MFSK.

Ab `v0.9.266` bleibt die FB2-Rahmenstruktur unverändert. Neu ist die Bedienlogik im Hauptfenster: Chat und Monitor sind getrennt, `ALLE` wird als Broadcast ohne automatisches OK/ACK behandelt, und die Screenshot-/Anleitungs-Erzeugung nutzt getrennte Szenarien für reale Bedienbilder.

Ab `v0.9.267` ist der lokale FB2-Audio- und Automatikpfad bis OFDM schnell erweitert. 2-FSK robust, 4-FSK, 8-FSK, 16-MFSK, 32-MFSK, 64-MFSK, OFDM robust, OFDM normal und OFDM schnell laufen im direkten Audio-QSO, im Auto-OK-Rückweg und im Mesh-Audio-Rundlauf. Der Mesh-Planer wählt profilabhängig den schnellsten stabilen Modus aus Nachbarfähigkeiten, Zuverlässigkeit, Paketverlust, ACK-Zeit und Linkalterung. OFDM nutzt aktuell ein internes Startsymbol und reduzierte Mehrträger-Aussteuerung; Piloten, Equalizer, FEC und echte Funkfeldhärtung bleiben eigene Nacharbeit.

Ab `v0.9.268` zeigt FunkBrücke für jedes geplante TX-Paket den Übertragungsmodus direkt im Bedienfluss. Chat, Warteschlange, Automatikfenster, Betriebsdetails und Sendemotorstatus nennen dadurch zum Beispiel `8-FSK`, `OFDM robust` oder `FB1/klassisch`, bevor der Auftrag tatsächlich gesendet wird. Die Mesh-Moduswahl bewertet zusätzlich Airtime, Nettodurchsatz, Zuverlässigkeit, Paketverlust und ACK-Zeit und korrigiert den Modus laufend genau eine Leiterstufe nach oben oder unten, damit FunkBrücke bei besseren Bedingungen schneller und bei schlechteren Bedingungen robuster wird. OFDM nutzt dafür im lokalen Audiopfad mehrere Trainingssymbole und eine interne Synchronisationssuche; echte Funkfeldtests bleiben trotzdem Pflicht.

Ab `v0.9.269` ist die laufende FB2-Automatik besser nachprüfbar. Der Zwei-Stationen-Ablauf bewertet Rollen, RX/Kanalwache, Warteschlange, Modus, automatische TX/RX-Rückkehr, Auto-OK und Nachweis als zusammenhängende Betriebslage. Der FB2-Live-Monitor übernimmt relevante Paket-, Feldtest-, RX-nach-TX- und Mesh-Modusereignisse. Die Mesh-Modusentscheidung wird als Primär-/Ersatz-Hop mit Linklage, Profilgrenze und Begründung angezeigt, ohne eine zweite Funklogik einzuführen. Nach TX stellt die App RX, Kanal-frei-Prüfung, FB1-Horchfenster und FB2-Dauer-RX wieder bereit, soweit die lokale Audiolage das zulässt.

Ab `v0.9.270` wird der Praxispfad enger geprüft. Der Zwei-Stationen-Rundlauf akzeptiert ACK/Wiederholen nur noch mit passender Sequenz, Originalrichtung, Rückweg, Modus sowie Kopf- und Nutzdaten-CRC. Der FT-991A-Hardwarepfad verlangt plausible FT-991A-/USB-Audio-Gerätenamen. Der Dauer-RX zählt Duplikate getrennt, damit wiederholte gleiche Rahmen nicht erneut in QSO oder Mesh einlaufen. Mesh-Feldnachweise werden nach Aktualität gekoppelt, und der 6-Hop-Praxisrundlauf prüft die exakte Hop-Reihenfolge auf Hin- und Rückweg.

Ab `v0.9.271` ist der FB2-Praxispfad weniger geräteeng und gleichzeitig strenger im Ablauf: Audioquellen bleiben frei wählbar, während der Hardwarepfad nicht typische Geräte nur als Prüfhinweis führt. Der automatische Audiolauf verlangt RX nach TX, bevor ein Rückweg-OK zählt. 2-FSK robust, 4-FSK, 8-FSK und 16-MFSK bilden den explizit lauffähigen Kern-Audiopfad; höhere Modi bis OFDM bleiben im erweiterten Automatikpfad. Jeder Warteschlangenauftrag kann den Modusgrund aus dem FB2-Rahmen anzeigen, und FB2L-Link-Baken übertragen zusätzlich die Softwareversion.

Ab `v0.9.281` sind FB2-Nachbarmodusprobe und Nachbarmodusantwort als eigene kompakte Steuer-Nutzdaten abgesichert. Steuerrahmen für die Modusaushandlung müssen in 2-FSK robust laufen, dürfen keinen schnelleren Nutzdatenmodus melden als das Profil erlaubt und werden verworfen, wenn Rahmenmodus und Steuerinhalt nicht zusammenpassen. Gelernte Hin- und Rückwegmodi speichern zusätzlich die gemeldete Softwareversion. Für Mesh-Weiterleitungen bleibt die Standardgrenze bei sechs Hops; weitergeleitete Pakete behalten den tatsächlichen letzten Rest-Hop bei und werden am letzten direkten Hop nicht wieder auf den Standardwert zurückgesetzt.

Ab `v0.9.282` sind die nächsten Praxisfreigaben enger abgesichert. Der Zwei-Stationen-Praxistest bewertet sieben Startpunkte gemeinsam, die Audio-RX/TX-Kette prüft die Kernmodi 2-FSK robust bis 16-MFSK mit Paket, Rückweg und OK, und der FT-991A-Pfad verlangt zusätzlich RX-Rückkehr nach TX sowie den Ausschluss manueller PTT. Feldnachweise aus einer bestandenen Hardware-TX/RX-Abnahme werden nur gespeichert, wenn sie mesh-tauglich sind; aus dem gespeicherten Nachweis kann die Mesh-Route anschließend einen bidirektionalen Nachbarlink rekonstruieren. Der Drei-Stationen-Rundlauf kann externe Feldnachweise als Freigabequelle nutzen und bricht vor dem ersten Mesh-Schritt ab, wenn ein Hop-Nachweis fehlt. FB2L-Heartbeats werden vor dem Senden gegen Station, Locator, Version, Frequenz, Profil, TTL, Links und Nachbarprofile geprüft.

Ab `v0.9.283` wird der Praxispfad stärker an den tatsächlichen App-Zustand gebunden. Der FT-991A-Pfad trennt Trockenlauf, lokalen Audiotest und echte CAT-PTT-Aussendung. Die App-RX/TX-Kopplung bewertet Audio-RX, FB2-Dauer-RX, Kanalwache, Warteschlange, Sendemotor, PTT, TX-Nachweis, Rückmeldung und RX-Rückkehr gemeinsam. Der direkte FB2-Mindestlauf verlangt Warteschlangenauftrag, automatischen TX, Gegenstations-RX, Auto-OK/Wiederholen, Rückweg, Abschluss und RX nach TX. Mesh-Warteschlangeneinträge führen die Feldnachweis-ID für den nächsten Hop mit, und FB2L-Heartbeats können die aktuelle App-Lage der eigenen Station an die Livekarte melden.

Ab `v0.9.82` ist der FB2-MVP-Artefaktprüfblock sichtbar. Er fasst die Schritte `v0.9.80` bis `v0.9.82` zusammen: gespeicherte JSON-/WAV-Artefakte werden geladen, ausgewählt und gegen ihre Metadaten geprüft. Die Bilanz vergleicht JSON-Lesbarkeit, WAV-Datei, PCM-Format, Samplezahl, Abtastrate, WAV-CRC, Dauer und Sicherheitsstatus. Das ist bewusst nur lokale Wiederanalyse und Soll/Ist-Diagnose ohne Wiedergabe, ohne PTT, ohne Mesh-Weiterleitung und ohne produktiven FB2-TX.

Ab `v0.9.83` führt FunkBrücke das Feldtest-Archiv als sortier- und filterbare Ereignisliste. Dadurch bleiben FB1/Mesh-Feldnotizen, Startstände und offene Sperren für spätere FB2-MVP-Nacharbeit nachvollziehbar, ohne einen produktiven FB2-TX/RX-Pfad zu öffnen.

Ab `v0.9.84` werden empfangene `FB2L`-Link-Baken stärker an die Mesh-Tabelle angebunden. Eine neue Bilanz erzeugt direkte und gemeldete Links, zählt neue sowie erneuerte Einträge und vergleicht die Zielroute vor und nach der Bake. Auch das bleibt Diagnose und Feldtestvorbereitung; produktive Aussendungen laufen weiter über FB1/Mesh.

Ab `v0.9.126` besitzt FB2 eigene Frequenzprofile. FunkBrücke unterscheidet dabei empfohlene Aktivitätsfenster von exklusiven Frequenzen: SSB schmal, FM normal und FM breit/Labor werden gegen Bandplanfenster, geschätzte Signalbreite und statische Sperrfrequenzen geprüft. Bekannte Aktivitätszentren wie FT8, PSK31, WSPR, APRS, DV-/FM-Anruf und Baken-/Schutzbereiche blockieren die Startfreigabe, wenn das geplante FB2-Signal sie berührt. Die Kurzspezifikation liegt unter `docs/fb2-frequenzprofile.md`.

Ab `v0.9.143` gibt es im Mesh-/FB2-Bereich eine FB2-MVP-Betriebsfreigabe. Sie ist der erste Einzelschritt vom Laborpfad zur Lauffähigkeit und bewertet konservativ nur `4-FSK` und `8-FSK`, Audio-RX, Audio-TX, Kanalwache, PTT-Sperre und RX-Nachweis. Die Freigabe nennt getrennt, ob ein späterer Dauer-RX und kontrolliertes Testaudio bereit sind. Produktiver FB2-TX und automatische RX-Umschaltung bleiben weiterhin gesperrt.

Ab `v0.9.144` ist der erste kontrollierte Dauer-RX angeschlossen. Er nimmt Samples aus dem laufenden Audioeingangspuffer, prüft im Hintergrund gedrosselt ausschließlich die MVP-Modi `4-FSK` und `8-FSK` und übernimmt gültige `FB2L`-Link-Baken oder generische `FB2`-Rahmen in den vorhandenen FB2-RX-Pfad. Der Pfad ist rein empfangend: keine PTT, keine automatische TX-Umschaltung, keine produktive FB2-Sendefreigabe.

Ab `v0.9.145` wird derselbe kontrollierte MVP-Pfad profilbewusst bis `32-MFSK` geöffnet. Die MVP-Modi sind `4-FSK`, `8-FSK`, `16-MFSK` und `32-MFSK`; die Betriebsprofile begrenzen weiterhin, was tatsächlich verwendet wird. SSB schmal bleibt auf schmale Modi begrenzt, FM normal kann 16-MFSK nutzen, und 32-MFSK bleibt dem Profil `FM breit/Labor` vorbehalten. Produktiver FB2-TX, automatische TX-Umschaltung und PTT bleiben gesperrt.

Ab `v0.9.146` folgt eine trockene FB2-MVP-Sendeauftragsprüfung. Sie erzeugt für den gewählten MVP-Modus einen echten Rahmen- und Sampleplan, bewertet Modus/Profil, Audioausgang, Kanalwache, Testaudio-Freigabe, PTT und CAT-PTT und zeigt die Prüfpunkte im Mesh-/FB2-Bereich. Diese Stufe ist noch keine Aussendung: keine Wiedergabe, kein Sendemotor, keine automatische TX-Umschaltung und keine PTT.

Ab `v0.9.147` werden bereite trockene FB2-MVP-Sendeaufträge als lokale JSON- und PCM-WAV-Artefakte gespeichert. Die Artefakte enthalten Modus, Sequenz, Rahmen-CRC, WAV-CRC, Samplezahl, Dauer und Sicherheitsstatus. Das ist weiterhin nur ein lokaler Nachweis: keine Wiedergabe, kein Sendemotor, keine PTT und keine Mesh-Weiterleitung.

Ab `v0.9.148` kann dieselbe gespeicherte WAV direkt wieder durch die FB2-RX-Erkennung laufen. Die Rückprüfung vergleicht WAV-Format, Abtastrate, Samplezahl, WAV-CRC, TX-Sperre, RX-Rahmen, Modus, Sequenz, Absender, Empfänger, Nutzdaten und Rahmen-CRC und schreibt eine `.rx.json`-Bilanz neben die Artefakte. Der Mesh-/FB2-Bereich zeigt eine Ampel für diese lokale MVP-Kette. Auch diese Stufe bleibt ohne Wiedergabe, ohne PTT, ohne Sendemotor und ohne Mesh-Weiterleitung.

Ab `v0.9.150` fasst ein eigener FB2-MVP-Kettenstatus diese Einzelschritte zusammen. Die Bewertung prüft Betriebsfreigabe, trockenen Sendeauftrag, JSON/WAV-Artefakt, WAV-RX-Rückprüfung und TX-Sicherheit. Grün bedeutet nur lokale Lauffähigkeit der MVP-Kette; produktiver FB2-TX, automatische PTT, Sendemotor und Mesh-Weiterleitung bleiben weiterhin gesperrt.

Ab `v0.9.151` gibt es einen geführten FB2-MVP-RX-Nachweis. Die Bewertung prüft Audioeingang, profilbedingt erlaubte MVP-Suchmodi bis `32-MFSK`, aktiven oder startbaren Dauer-RX, erwarteten RX-Treffer, lokalen Kettenstatus und TX-Sicherheit. Ein bestätigter RX-Nachweis bedeutet nur, dass der Empfangspfad einen erwarteten FB2-Rahmen zuordnen konnte; produktiver FB2-TX, automatische PTT, Sendemotor und Mesh-Weiterleitung bleiben weiterhin gesperrt.

Ab `v0.9.152` gibt es zusätzlich einen beaufsichtigten FB2-MVP-Test-TX als Einzelschuss. Er ist ausdrücklich kein produktiver FB2-Sendebetrieb: Vor dem Start müssen lokale MVP-Kette, Audioausgang, Audioeingang, Kanalprüfung, FB1-Horchfenster, CAT-Verbindung, echte CAT-PTT und eine eigene Bedienfreigabe grün sein. Der Einzelschuss legt nichts in die Sendewarteschlange, startet kein ACK-Fenster, wiederholt nicht automatisch und leitet nichts ins Mesh weiter. PTT wird nur für diesen einen Test gesetzt und danach wieder ausgeschaltet.

Ab `v0.9.153` wird der Gegenstations-RX für diesen Test-TX sichtbar auswertbar. Jeder gültig dekodierte FB2-Paketrahmen wird als letzter Gegenstationsrahmen gemerkt und kann mit `Gegenstations-RX prüfen` bewertet werden. Die Prüfung belegt Audio-/Dauer-RX-Lage, Paketrahmen, erlaubten MVP-Modus, plausible Stationsdaten, Sequenz, Kopf-CRC, Nutzdaten-CRC und TX-Sicherheit. Sie setzt keine PTT, erzeugt kein ACK, startet keinen Sendemotor, legt nichts in die Warteschlange und leitet nichts ins Mesh weiter.

Ab `v0.9.154` folgt die erste FB2-MVP-ACK/NACK-Regelprüfung. Ein bestätigter Gegenstations-RX kann trocken als Bezug für einen `Steuerung`-Rahmen vom Typ ACK oder NACK bewertet werden. Die Vorschau enthält Sequenz, Originalrichtung, Modus, Kopf-CRC, Nutzdaten-CRC und den Automatikstatus. Diese Stufe sendet weiterhin nicht automatisch: keine PTT, keine CAT-PTT-Freigabe, kein Sendemotor, keine Warteschlange, keine Wiederholung und keine Mesh-Weiterleitung.

Ab `v0.9.155` kann FunkBrücke empfangene FB2-MVP-ACK/NACK-Steuerrahmen deuten und dem ursprünglichen Testpaket zuordnen. Die Auswertung prüft Steuerrahmenart, ACK/NACK-Typ, Sequenz, Rückrichtung, `ORIG`-Richtung, Modus sowie Kopf- und Nutzdaten-CRC gegen das zuletzt vorbereitete Test-TX-Paket. Ein zugeordneter ACK oder NACK ist nur ein Nachweis; automatische Antwort, PTT, Sendewarteschlange, Wiederholung und Mesh-Weiterleitung bleiben gesperrt.

Ab `v0.9.156` gibt es eine kontrollierte manuelle FB2-Antwort-Vormerkung. Die zuletzt erzeugte ACK/NACK-Steuerrahmenvorschau kann mit `Antwort vormerken` gegen Vorschau, Steuerrahmeninhalt, Bedienfreigabe, Kanalwache, TX-Sicherheit und Sendeweg geprüft werden. Das Ergebnis ist bewusst nur ein gesperrter manueller Antwortauftrag: `DarfManuellSenden` bleibt falsch, es wird keine PTT gesetzt, nichts in die Warteschlange gelegt, nichts wiederholt und nichts ins Mesh weitergegeben.

Ab `v0.9.157` wird dieser manuelle ACK/NACK-Antwortauftrag zusätzlich als eigener Sendeauftrag geprüft. Die Prüfung bewertet Vormerkung, Steuerrahmen, Modus/Sequenz, Rückrichtung, Kanalwache, CAT/PTT-Bereitschaft und bewusste Bedienfreigabe. Selbst wenn alles passt, bleibt `DarfSenden` in dieser Stufe absichtlich falsch: Der Auftrag ist nur `prüfbar gesperrt`, setzt keine PTT und löst keine automatische Aussendung aus.

Ab `v0.9.158` kann aus diesem geprüften Antwortauftrag ein einzelner beaufsichtigter ACK/NACK-Steuerrahmen gestartet werden. Dafür müssen Antwort-TX-Freigabe, eigene Einzelschuss-Freigabe, Audioausgang, Kanalwache, CAT-Verbindung und echte CAT-PTT gemeinsam grün sein; direkt vor dem Start läuft erneut die Kanal-frei-Prüfung. Der Einzelschuss setzt PTT nur für diese eine Antwort, schaltet sie danach wieder aus und nimmt die Freigaben zurück. Warteschlange, Wiederholung, ACK-Fenster, automatische Antwort und Mesh-Weiterleitung bleiben auch hier gesperrt.

Ab `v0.9.159` zeigt ein eigener FB2-MVP-Rundlaufstatus die Gesamtfolge als Ampel. Grün bedeutet: Test-TX, Gegenstations-RX, ACK/NACK-Vorschau, manuelle Antwort, Antwortauftrag, ACK/NACK-Einzelschuss und ACK/NACK-RX sind vollständig belegt. Gelb zeigt offene oder nur vorbereitete Schritte, Rot blockierende Sicherheitslagen wie aktive PTT, laufenden Sendepfad oder einen nicht gesperrten produktiven FB2-TX.

Ab `v0.9.160` ergänzt eine passive FB2-MVP-Timeoutprüfung den Rundlauf. Sie bewertet Rundlaufalter, Gegenstations-RX, ACK/NACK-Antwort, Antwort-TX und ACK/NACK-RX gegen feste Beobachtungsfristen. Ein Timeout erzeugt nur Diagnose, Ampelstatus und eine nächste Handlungsaktion. Es wird kein Paket wiederholt, kein ACK/NACK automatisch gesendet, keine Warteschlange gefüllt und nichts ins Mesh weitergeleitet.

`v0.9.161` ändert das FB2-Protokoll nicht, sondern aktualisiert Bedienungsanleitung und Screenshots für Rundlauf- und Timeoutprüfung.

Ab `v0.9.162` bereitet FunkBrücke den ersten beaufsichtigten FB2-MVP-Zwei-Stationen-Test als eigenen Folgebeleg vor. Die Prüfung führt Stationspaar, Frequenz, Profil, Modus, Vor-TX-FB1-Horchfenster, RX-Bereitschaft beider Stationen, Testleitung und Abbruchregel zusammen. Ein aktueller gültiger FB1-Rahmen blockiert; der RX-Pegel bleibt ohne Freigabewirkung. Auch bei vollständiger Vorbereitung entsteht keine automatische Sendefreigabe, keine CAT-PTT, kein Sendemotorstart und keine Mesh-Weiterleitung.

Ab `v0.9.163` wird diese Vorbereitung als bewusste Testbestätigung bedienbar. Das Gegenstationsrufzeichen kann aus einem empfangenen FB2-Paketrahmen vorgefüllt werden, gilt aber erst nach manueller Gegenstationsbestätigung. Testleitung und Abbruchregel werden ebenfalls als eigene Bedienbestätigungen geführt. Ohne diese Häkchen bleibt der Zwei-Stationen-Test nur vorbereitet oder warnend offen; eine automatische Sendefreigabe entsteht weiterhin nicht.

Ab `v0.9.164` erzeugt FunkBrücke aus einer vollständigen Zwei-Stationen-Testbestätigung einen konkreten Einzelschritt-Testauftrag. Dieser enthält Testkennung, Auftragskennung, Sequenznummer, Gegenstation, Frequenz, Profil, Modus, Beobachtungsfenster, Abbruchregel sowie erwartete FB2-Paket- und Steuerrahmen. Die Rahmen sind als `FB2|...` prüfbar, lösen aber keine Aussendung aus: kein Sendebefehl, keine automatische Freigabe, keine CAT-PTT und keine Mesh-Weiterleitung.

Ab `v0.9.165` folgt die harte Startfreigabe für genau einen FB2-MVP-Test-TX aus diesem Zwei-Stationen-Testauftrag. Vor dem Start müssen Testauftrag, Gegenstation/Testleitung/Abbruchregel, RX-Bereitschaft, Kanalprüfung, FB1-Horchfenster, lokale FB2-MVP-Kette, Audioausgang, CAT-Verbindung, echte CAT-PTT und bewusste Bedienfreigabe gemeinsam grün sein. Die Einzelschuss-Schaltfläche bleibt bis dahin deaktiviert; der Startpfad prüft dieselbe Freigabe direkt vor Audioausgabe erneut. Der gesendete Test-TX verwendet Sequenz, Gegenstation und den erwarteten FB2-Paketrahmen aus dem Auftrag. Automatik, Warteschlange, Wiederholung, produktiver FB2-TX und Mesh-Weiterleitung bleiben gesperrt.

`v0.9.166` ändert das FB2-Protokoll nicht, sondern entlastet die interne `SB-R`-Statusprüfung für vollständige Testläufe und Diagnose. Die technische Grenze bleibt unverändert: FB2-MVP-Test-TX und ACK/NACK-Einzelschuss sind nur beaufsichtigte Einzelschritte, kein produktiver Automatikbetrieb.

Ab `v0.9.167` gibt es nach dem beaufsichtigten Test-TX einen eigenen passiven Beobachtungsschritt. Er hält den freigegebenen Auftrag des tatsächlich gesendeten Einzel-TX fest, prüft Audioeingang, Dauer-RX, erwarteten ACK/NACK-Steuerrahmen, Beobachtungsfenster, ACK/NACK-RX und TX-Sicherheit. Diese Stufe sendet nichts: keine PTT, keine Wiederholung, keine Warteschlange, keine automatische Antwort und keine Mesh-Weiterleitung.

Ab `v0.9.168` bindet FunkBrücke empfangene ACK/NACK-Steuerrahmen zusätzlich an den gespeicherten Zwei-Stationen-Testauftrag. Der neue Folgebeleg verknüpft Testauftrag, harte Test-TX-Freigabe, passive Beobachtung, empfangenen Steuerrahmen und ACK/NACK-RX-Ergebnis. Ein ACK/NACK gilt erst dann als vollständig belegt, wenn Richtung, Sequenz, Modus, Beobachtungsfenster sowie Kopf- und Nutzdaten-CRC zum Test-TX-Auftrag passen. Falsche Steuerrahmen werden gesperrt; fehlende Rückmeldungen bleiben warnend und lösen keine automatische Wiederholung aus.

Ab `v0.9.169` wird diese Auftragsbindung in Rundlauf, Timeoutprüfung und Bedienführung verpflichtend mitgeführt. Die Rundlaufampel wird erst Grün, wenn der ACK/NACK-RX nicht nur formal zugeordnet, sondern auch gegen den gespeicherten Zwei-Stationen-Testauftrag bestätigt ist. Die Timeoutprüfung bewertet eine fehlende Auftragsbindung als eigenen passiven Fristpunkt nach dem ACK/NACK-RX. Der FB2-MVP-QSO-Assistent fasste den ersten beaufsichtigten Ablauf zunächst in zehn Schritten zusammen; seit `v0.9.175` führt er denselben Ablauf mit sichtbarem Start-/Rollencheck in elf Schritten. Er bleibt rein passiv: keine PTT, keine automatische Wiederholung, keine Warteschlange und keine Mesh-Weiterleitung.

Ab `v0.9.170` wird der FB2-MVP-QSO-Assistent als geführter Bedienpfad bedienbar. Er zeigt aktuellen Schritt, Fortschritt und nächsten Bedienbefehl und kann die passende vorhandene Prüfung für den nächsten offenen Schritt auslösen. Auch diese Führung bleibt strikt beaufsichtigt: Sie darf keinen Test-TX, keinen ACK/NACK-Einzelschuss, keine PTT, keine Warteschlange, keine Wiederholung und keine Mesh-Weiterleitung automatisch starten.

Ab `v0.9.171` kann ein vollständig grüner, gegen den Zwei-Stationen-Testauftrag gebundener FB2-MVP-QSO-Rundlauf lokal als QSO-Protokoll gespeichert werden. Das Protokoll enthält Stationen, Frequenz, Profil, Modus, Auftrag, Sequenz, ACK/NACK-Typ, Zeitpunkte, Rundlauf-/Timeout-Ampel, Sicherheitsgrenzen und die QSO-Prüfschritte; seit `v0.9.175` sind das elf Schritte mit Start-/Rollencheck. Es wird als JSON und HTML gespeichert und in einer lokalen Historie angezeigt. Unvollständige Abläufe, offene Automatik oder ein nicht gesperrter produktiver FB2-TX werden nicht als Nachweisdatei geschrieben.

Ab `v0.9.172` wird diese lokale QSO-Protokoll-Historie in Feldtestbericht und Exportübersicht als Nachweisquelle ausgewiesen. Die Auswertung nennt Anzahl, neuesten Protokollnachweis, Stationspaar, Auftrag, Sequenz, CRC und Speicherordner. Wenn noch kein vollständiges QSO-Protokoll existiert, erscheint eine Warnung mit der nächsten Handlung statt einer stillen Lücke.

Ab `v0.9.173` wird das neueste lokale FB2-MVP-QSO-Protokoll zusätzlich als Pflichtanlage des Feldtestpakets geprüft. Ist noch kein Protokoll gespeichert, bleibt die Anlage offen und die Berichtprüfung warnt gezielt. Ist ein Protokoll vorhanden, verlinkt die Anlage JSON und HTML und nennt Protokoll-ID, Stationspaar, Auftrag, Sequenz und CRC.

Ab `v0.9.174` gibt es für den ersten echten FB2-MVP-Feldtestablauf einen eigenen Start-/Rollencheck. Der Folgebeleg bindet Testauftrag und harte genau-ein-TX-Freigabe zusammen und prüft zusätzlich Testleitung, sendende Station, empfangende Station, Gegenstationsbestätigung, Vorlesen der Rollen, Frequenz-/FB1-Horchfenster, QSO-Protokollpflicht und Automatikgrenzen. Auch ein bereiter Rollencheck startet nichts selbst: keine PTT, keine Wiederholung, keine Warteschlange, kein produktiver FB2-TX und keine Mesh-Weiterleitung.

Ab `v0.9.175` ist dieser Start-/Rollencheck direkt im FB2-MVP-QSO-Assistenten sichtbar. Der Assistent führt den ersten Ablauf nun in 11 Schritten und setzt den Rollencheck zwischen harte Test-TX-Freigabe und beaufsichtigten Test-TX. Der neue sichtbare Bereich zeigt Status, Startkennung, Rollencheck-Zeile und sieben Prüfpunkte; `Nächsten QSO-Schritt prüfen` aktualisiert diesen Schritt passiv und startet weiterhin keinen Test-TX.

Ab `v0.9.176` ist der Start-/Rollencheck zusätzlich eine blockierende Test-TX-Startbedingung. Die Test-TX-Prüfung führt ihn als eigenen Punkt zwischen Kanalwache und Bedienfreigabe; der echte Einzelschuss berechnet harte Freigabe und Rollencheck unmittelbar vor Kanalprüfung, Audioausgabe und CAT-PTT neu. Die Startschaltfläche wird nur freigegeben, wenn beide Nachweise zum selben Testauftrag gehören. Ist der Rollencheck offen oder gesperrt, wird keine PTT gesetzt und kein Audio gesendet.

Ab `v0.9.177` fasst eine eigene FB2-MVP-Feldtest-Abnahme die Nachweiskette für den ersten beaufsichtigten Zwei-Stationen-Ablauf zusammen. Sie bewertet Start-/Rollencheck, Test-TX mit passiver Beobachtung, Gegenstations-RX, ACK/NACK-Fenster mit Auftragsbindung, Rundlauf, Timeout, QSO-Assistent, gespeichertes QSO-Protokoll und Automatikgrenze als gemeinsame Abnahmebedingung. Grün wird nur erreicht, wenn ein passendes vollständiges QSO-Protokoll zum Auftrag existiert, Rundlauf und Timeout grün sind, keine PTT oder kein Sendepfad läuft und Automatik sowie produktiver FB2-TX gesperrt bleiben.

Ab `v0.9.178` wird diese FB2-MVP-Feldtest-Abnahme zusätzlich in Feldtestbericht und Exportübersicht aufgenommen. Der Bericht enthält eine eigene Abnahmesektion mit Ampel, Abnahmebereitschaft, QSO-Protokollpflicht, allen Prüfpunkten und nächster Handlung. Die Exportübersicht führt dieselben Informationen als Quelle `v0.9.178-FB2-MVP-Feldtest-Abnahme`, damit offene Abnahmepunkte im Feldtestpaket nicht übersehen werden. Auch dieser Nachweis startet keine PTT, keinen Sendemotor, keine Wiederholung und keine Mesh-Weiterleitung.

Ab `v0.9.179` führt der QSO-Assistent den Abschluss als zwölf Schritte. Die ersten elf Schritte bleiben die operative QSO-Kette bis zur Dokumentation; Schritt 12 `Feldtest-Abnahme prüfen` wird danach als passiver Abschluss geführt. Ohne passendes gespeichertes QSO-Protokoll bleibt Schritt 12 offen. Ist das Protokoll vorhanden, zeigt der Schritt die Abnahmeampel und verweist auf Bericht und Export. Das QSO-Protokoll selbst wird weiterhin nach den elf operativen Schritten erzeugt, damit die Abnahme nicht von ihrem eigenen Abschluss abhängt.

Ab `v0.9.180` kann die FB2-MVP-Feldtest-Abnahme als eigenes lokales Abnahme-Protokoll gespeichert werden. Das Protokoll wird als JSON und HTML unter `%APPDATA%\FunkBruecke\fb2-mvp-feldtest-abnahmen` abgelegt, enthält die Abnahmeampel, alle Abnahmepunkte, Sicherheitsgrenzen, Stationsdaten, Frequenz, Modus, Auftrag, Sequenz und das verknüpfte QSO-Protokoll mit CRC. Eine lokale Historie mit Vorschau und Öffnen-Funktion ist im QSO-Assistenten sichtbar. Feldtestbericht und Exportübersicht führen die Abnahme-Protokoll-Historie als eigene Nachweisquelle; das neueste Abnahme-Protokoll wird als Pflichtanlage geprüft. Gespeichert wird nur bei bereiter Abnahme, erfüllter QSO-Protokollpflicht, gesperrtem produktivem FB2-TX und gesperrter Automatik. Auch diese Protokollierung startet keine PTT, keinen Sendemotor, keine Wiederholung und keine Mesh-Weiterleitung.

Ab `v0.9.181` wird das gespeicherte FB2-MVP-Abnahme-Protokoll praktisch gegen das zugehörige QSO-Protokoll geprüft. Die Prüfung vergleicht die Abnahme-JSON-CRC, vorhandene HTML-Anlage, QSO-Protokoll-ID, QSO-CRC, Auftrag, Sequenz, Stationspaar, Frequenz, Profil, Modus sowie die Sicherheitsgrenzen von Abnahme und QSO. Der QSO-Assistent zeigt dafür eine eigene Schaltfläche und eine Prüfansicht; Feldtestbericht, Pflichtanlage und Exportübersicht nutzen dieselbe Bewertung. Fehlende HTML-Anlagen sind Warnungen, falsche QSO-Bezüge, CRC-Abweichungen oder offene Sicherheitsgrenzen sperren den Nachweis. Auch diese Prüfung ist rein lokal und passiv.

Ab `v0.9.182` kann dieselbe Abnahme-Protokoll-Prüfung zusätzlich passive Prüffälle simulieren. FunkBrücke bewertet den Originalnachweis, ein fehlendes QSO-Protokoll, eine abweichende QSO-Sequenz, eine abweichende QSO-CRC und eine fehlende HTML-Anlage gegen die erwartete OK-/Warn-/Sperrlogik. Der QSO-Assistent zeigt dafür `Prüffälle simulieren`; Feldtestbericht und Exportübersicht führen die Quelle `v0.9.182-FB2-MVP-Abnahme-Protokoll-Prüffälle`. Auch diese Prüffälle arbeiten nur lokal mit gespeicherten Dateien und starten keine PTT, keinen Sendemotor, keine Wiederholung und keine Mesh-Weiterleitung.

Ab `v0.9.1` wird diese Grenze im Praxisstart mitgeführt: echte Mehrstations- und Hardwareversuche werden über FB1/Mesh, CAT/PTT, Audio/RX, Kanalwächter und Feldteamfreigabe geprüft. FB2 bleibt dabei sichtbar als Labor- und Planungsschicht, bis echte Messungen eine produktive Umschaltung rechtfertigen.

Ab `v0.9.2` übernimmt das Praxisstart-Protokoll diese Grenze in die Nachweiskette. Der Bericht nennt ausdrücklich, dass echte Praxisstarts weiterhin über FB1/Mesh und die technische Startfreigabe laufen, während FB2 Labor bleibt.

Ab `v0.9.3` übernimmt auch die Vorbereitung des echten Mehrstations-/Hardwareversuchs diese Grenze. Vor-TX-Regel, Funkziel, Funkspur-Erfassung und Nachversuch-Sicherung beziehen sich weiterhin auf FB1/Mesh; FB2 bleibt Labor, Diagnose und Planung.

Ab `v0.9.4` übernimmt auch die Nachversuch-Auswertung diese Grenze. ACK/NACK, Route/Hop, Kanalwächter/FB1-Horchfenster, Funkspur-Nacharbeit und Exportpaket werden als Feldtestbelege bewertet; FB2 bleibt dabei weiterhin Labor-, Diagnose- und Planungsstand ohne produktive Umschaltung.

Ab `v0.9.5` übernimmt auch die Versuchslaufkarte diese Grenze. Startfreigabe, Vor-TX-Horchfenster, Paket-ID, ACK/NACK, Route/Hop, Kanalbeleg und Nachversuch-Sicherung sind Feldtestführung für FB1/Mesh; FB2 bleibt ohne produktive TX-/RX-Freigabe.

Ab `v0.9.6` übernehmen auch die Folgebelege diese Grenze. Offene Laufkartenschritte werden als Feldtest-Nachweisaufgaben für FB1/Mesh gesammelt; FB2 bleibt weiterhin Labor-, Diagnose- und Planungsstand.

Ab `v0.9.7` werden diese Folgebelege priorisiert und mit Ziel-Mehrstationsfall sowie Ziel-Eingabefeld ergänzt. Das verbessert die Feldtestführung, aktiviert aber weiterhin keinen produktiven FB2-TX/RX-Pfad.

Ab `v0.9.8` erzeugt FunkBrücke daraus eine Folgebeleg-Startreihenfolge mit Funk- und Dokumentationsschritten. Das bleibt reine Feldtestführung für FB1/Mesh und aktiviert weiterhin keinen produktiven FB2-TX/RX-Pfad.

Ab `v0.9.9` ergänzt FunkBrücke einen Folgebeleg-Durchführungsplan mit Status bereit/wartet, Abhakpunkt, Ergebnisziel und Nachversuch-Vorbereitung. Auch das bleibt reine Feldtestführung für FB1/Mesh und aktiviert weiterhin keinen produktiven FB2-TX/RX-Pfad.

Ab `v0.9.10` ergänzt FunkBrücke eine Folgebeleg-Feldlauf-Begleitung. Der erste bereite Durchführungsschritt wird mit Startprüfung, Durchführung, Ergebnisübernahme und Nachversuch-Aktualisierung geführt; Funk-Schritte verlangen technische Startfreigabe, Vor-TX-/FB1-Horchfenster und gültige FB1-Belegung. Auch das bleibt reine Feldtestführung für FB1/Mesh und aktiviert weiterhin keinen produktiven FB2-TX/RX-Pfad.

Ab `v0.9.11` ergänzt FunkBrücke eine Folgebeleg-Feldlauf-Erfassung. Jeder Prüfpunkt bekommt Ergebnisstatus, Notizvorlage, Nachweisvorlage, Auswirkung und nächste Aktion für Nachversuch, Bericht und Export. Auch das bleibt reine Feldtestführung für FB1/Mesh und aktiviert weiterhin keinen produktiven FB2-TX/RX-Pfad.

Ab `v0.9.12` ergänzt FunkBrücke eine Folgebeleg-Feldlauf-Nachversuch-Rückwirkung. Jeder erfasste Prüfpunkt wird einem Nachversuchsfeld zugeordnet und nennt Übernahmeregel, offene Nacharbeit sowie nächste Aktion. Auch das bleibt reine Feldtestführung für FB1/Mesh und aktiviert weiterhin keinen produktiven FB2-TX/RX-Pfad.

Ab `v0.9.13` ergänzt FunkBrücke einen Folgebeleg-Nachversuch-Rücklauf. Er markiert übernahmebereite Rückwirkungen als erledigt, führt wartende Punkte als Folgebelege weiter und hält blockierende Punkte für den nächsten Durchführungsplan oben. Auch das bleibt reine Feldtestführung für FB1/Mesh und aktiviert weiterhin keinen produktiven FB2-TX/RX-Pfad.

Ab `v0.9.14` übersetzt FunkBrücke diese Rücklaufpunkte zusätzlich in passive FB2-Messziele. Pro Punkt werden Betriebsprofil, empfohlener Modus, Signalbreite, geschätzte Airtime, Messregel und Sicherheitssperre angezeigt. Das ist Messvorbereitung und Laborbeobachtung; es gibt weiterhin keine produktive FB2-Aussendung und keine automatische FB2-RX-Umschaltung.

Ab `v0.9.15` bewertet FunkBrücke diese Messziele als Messrücklauf. Jeder Punkt wird als verwertbar, offen oder blockiert eingeordnet. Verwertbare Punkte sind nur Laboranlage zu bereits erledigten FB1/Mesh-Rückläufen; offene oder blockierte Punkte bleiben ohne abnahmefähigen Funknachweis.

Ab `v0.9.16` fasst FunkBrücke diesen Messrücklauf zusätzlich als FB2-Laborampel zusammen. Die Ampel unterscheidet vollständige, unvollständige und blockierte Laboranlagen und sagt ausdrücklich, ob die Werte als Berichtanlage dienen dürfen. Sie ist keine produktive FB2-Freigabe.

Ab `v0.9.17` übersetzt FunkBrücke diese Ampel in eine FB2-Feldlauf-Startprüfung. Sie entscheidet vor dem nächsten echten Feldlauf, ob die Laboranlage mitgeführt, nachgearbeitet oder zurückgestellt wird. Der echte Funkpfad bleibt FB1/Mesh.

Ab `v0.9.18` koppelt FunkBrücke diese Entscheidung als FB2-Startprotokoll-Ergänzung an die Vorlesezeile der Testleitung. Dadurch steht vor Ort direkt im Startprotokoll, ob der FB2-Laboranhang mitgeführt, nachgearbeitet, zurückgestellt oder weggelassen wird; FB1/Mesh bleibt dabei der einzige produktive Funkpfad.

Ab `v0.9.73` erzeugt FunkBrücke daraus eine FB2-MVP-Startentscheidung. Sie bewertet Startprotokoll, Laboranlage, Profil/Modus, Sicherheitsgrenze und Rückfallpfad, wählt für einen späteren ersten MVP-Test konservativ `4-FSK` auf `SSB schmal` und `8-FSK` auf FM-Profilen und hält produktiven FB2-TX weiter gesperrt, bis eine eigene Audio-/PTT-Freigabe ergänzt ist.

Ab `v0.9.74` folgt eine FB2-MVP-Audio-/PTT-Prüfung. Sie bewertet Audioausgabe, PTT-Sperre, Einzeltestgrenze und Rückfallpfad für einen späteren lokalen MVP-Audiotest, löst keine CAT-PTT aus und hält produktiven FB2-TX weiter gesperrt.

Ab `v0.9.75` folgt ein FB2-MVP-Audioton-/Loopback-Beleg. Er berechnet Modus, Symbolrate, Ton-/Trägeranzahl, Signalbreite, Abtastrate, Testdauer und Sampleanzahl für den lokalen Laborlauf, hält den Audioton aber im lokalen Puffer/Loopback und legt nichts automatisch auf den TRX-Ausgang.

Ab `v0.9.76` folgt ein FB2-MVP-Samplepuffer-/RX-Rücklauf-Beleg. Er belegt Sampleanzahl, Samples pro Symbol, Symbolfenster, Startfrequenz, Tonabstand, Peak, RMS und eine Pufferprüfsumme für die lokale Diagnose, ohne Audioausgang, Sendemotor, CAT-PTT, Mesh-Weiterleitung oder produktiven FB2-TX zu öffnen.

Ab `v0.9.77` folgt ein FB2-MVP-RX-Laborereignis. Es bildet aus dem lokalen Samplepuffer eine Ereigniskennung, Puffer-CRC, Rücklauf-CRC, Ereignis-CRC, Quelle und Wiederauffindhinweis für Bericht und Export, ohne Audioausgang, Sendemotor, CAT-PTT, Mesh-Weiterleitung oder produktiven FB2-TX zu öffnen.

Ab `v0.9.78` folgt ein FB2-MVP-Artefaktbeleg. Er plant zu diesem RX-Laborereignis einen JSON-Metadatenanker und einen WAV-Rücklaufanker mit Artefakt-CRC und Metadaten-CRC, bleibt aber weiterhin ohne Dateischreiber, Audioausgang, Sendemotor, CAT-PTT, Mesh-Weiterleitung oder produktiven FB2-TX.

Ab `v0.9.79` folgt ein FB2-MVP-Artefaktspeicher. Er schreibt die geplanten JSON-/WAV-Artefakte lokal unter `%APPDATA%\FunkBruecke\fb2-mvp-rx-laborereignisse`, führt JSON- und WAV-Prüfsummen sichtbar mit und bleibt weiterhin ohne automatische Wiedergabe, Sendemotor, CAT-PTT, Mesh-Weiterleitung oder produktiven FB2-TX.

Ab `v0.9.82` folgt der zusammengefasste FB2-MVP-Artefaktprüfblock für `v0.9.80` bis `v0.9.82`. Er lädt gespeicherte JSON-/WAV-Artefakte, zeigt eine Auswahl im Test-Tab und erzeugt eine Soll/Ist-Bilanz für JSON-Lesbarkeit, WAV-Datei, PCM-Format, Samplezahl, Abtastrate, WAV-CRC, Dauer und Sicherheitsstatus. Das bleibt lokale Diagnose ohne Wiedergabe, PTT, Mesh-Weiterleitung oder produktiven FB2-TX.

Ab `v0.9.83` folgt das verbesserte Feldtest-Archiv. Es sammelt aktuellen Entwurf und Zwischenstände als Ereignisse, filtert Warnungen/Sperren oder Freigaben, sortiert nach Zeit, Status oder Quelle, öffnet ausgewählte Archivstände in die Feldtestnotizen und exportiert JSON/HTML als Berichtnachweis.

Ab `v0.9.84` folgt die FB2L-Mesh-Anbindungsbilanz. Empfangene Link-Baken werden nicht nur als Textstatus angezeigt, sondern als prüfbare Linkübernahme mit Route vorher/nachher, neuen und erneuerten Links sowie Exportnachweis geführt.

Ab `v0.9.19` verbindet FunkBrücke diese Vorlesezeile mit einem Feldlauf-Abhakplan. Startprotokoll, Vor-TX-Horchfenster, FB1/Mesh-Erfassung, FB2-Laboranhang und Bericht-/Export-Sicherung werden gemeinsam geführt. Das ändert nichts am Laborstatus: FB2 sendet nicht produktiv und ersetzt keinen FB1/Mesh-Nachweis.

Ab `v0.9.20` bereitet FunkBrücke daraus die konkrete Feldlauf-Nachweisführung vor. Vor-TX-Horchfenster und FB1/Mesh-Erfassung werden mit dem nächsten öffnungsfähigen Mehrstationsfall, Ziel-Eingabefeld und Textbaustein gekoppelt; Startprotokoll, FB2-Laboranhang sowie Bericht und Export bleiben reine Bericht-/Exportziele.

Ab `v0.9.21` prüft ein Feldlauf-Nachweisabgleich, ob die vorbereiteten Ziel-Fälle bereits echte Mehrstationsbewertungen enthalten. Auch dieser Abgleich bleibt bei FB1/Mesh als produktivem Nachweispfad; FB2 wird dadurch nicht freigegeben.

Ab `v0.9.22` bündelt ein Feldlauf-Startauftrag Startprotokoll, Ziel-Fall, Vor-TX-Horchfenster, erstes FB1/Mesh-Paket und Nachlaufnachweis. Der Auftrag bleibt ebenfalls FB1/Mesh-gebunden und verhindert produktive FB2-Aussendungen.

Ab `v0.9.23` belegt ein Feldlauf-Horchfensterbeleg die aktuelle Kanalentscheidung direkt vor dem ersten FB1/Mesh-Paket. Er prüft den letzten FB1-Horchfensterbefund auf frei, belegt oder offen, sperrt bei fremden gültigen FB1-Rahmen und bestätigt erneut, dass FB2 dadurch nicht produktiv sendet.

Ab `v0.9.24` ergänzt FunkBrücke einen Feldlauf-Sendebeleg. Er dekodiert das belegte FB1/Mesh-Paket, nennt Paket-ID, Sequenz, Ziel und ACK-Pflicht und bleibt ebenfalls reine FB1/Mesh-Feldtestführung ohne produktive FB2-Aussendung.

Ab `v0.9.25` ergänzt FunkBrücke den Feldlauf-Nachlaufbeleg. Er bewertet nach dem Sendebeleg ACK/NACK, Route/Hop, Gegenstation, Ziel-Fall, Nachweisabgleich, Nachversuch-Auswertung, Bericht und Export gemeinsam und verhindert Doppelversand bei bereits gesichertem Feldlauf.

Ab `v0.9.26` ergänzt FunkBrücke die Feldlauf-Abschlussentscheidung. Sie bündelt Startauftrag, Horchfenster, Sendebeleg und Nachlaufbeleg, nennt Abschluss, Nacharbeit oder Sperre und bleibt weiterhin reine FB1/Mesh-Feldtestführung ohne produktiven FB2-TX.

Ab `v0.9.27` ergänzt FunkBrücke die Feldlauf-Abschlussnacharbeit. Sie nennt konkrete Ziel-Fall-Aufgaben aus Abschlussentscheidung, Nachweisabgleich und echter Funkspur-Nacharbeit und bleibt ebenfalls reine FB1/Mesh-Feldtestführung ohne produktiven FB2-TX.

Ab `v0.9.28` ergänzt FunkBrücke das Feldlauf-Abschlussprotokoll. Entscheidung, Nacharbeit, Bericht, Exportanlage, Doppelsendungsschutz und Schlussvermerk werden als finaler Feldlaufbeleg mit Protokoll-ID und Archivziel geführt; FB2 bleibt dabei Labor- und Diagnosepfad.

Ab `v0.9.29` ergänzt FunkBrücke das Feldlauf-Praxisprotokoll. Die echte FB1/Mesh-Funklaufakte zeigt Startauftrag, Vor-TX-Horchfenster, Sendebeleg, Nachlauf, Abschlussentscheidung, Abschlussnacharbeit und Abschlussprotokoll mit aktuellem Handgriff; FB2 bleibt weiterhin Labor- und Diagnosepfad.

Ab `v0.9.30` ergänzt FunkBrücke die Feldlauf-Live-Bedienmaske. Sie verdichtet Ziel-Fall, Zielstation, Paket-ID, Horchfenster, TX-Freigabe, ACK/NACK, Route/Hop und aktuellen Handgriff für den echten FB1/Mesh-Feldlauf; FB2 bleibt weiterhin Labor- und Diagnosepfad.

Ab `v0.9.31` ergänzt FunkBrücke den Feldlauf-Live-Erfassungsbogen. Er führt Paket-ID, TX-/RX-Ereignis, ACK/NACK, Route/Hop, Gegenstation, Archivnachweis und Abschluss als Nach-TX-Eingabeliste für den echten FB1/Mesh-Feldlauf; FB2 bleibt weiterhin Labor- und Diagnosepfad.

Ab `v0.9.32` ergänzt FunkBrücke die Feldlauf-Live-Rückführung. Sie erzeugt aus dem Live-Erfassungsbogen einen Mehrstations-Ergebnisentwurf mit Beobachtung, Nachweis, Abweichung und Erfolgsmarkierung; FB2 bleibt weiterhin Labor- und Diagnosepfad.

Ab `v0.9.33` bis `v0.9.35` ergänzt FunkBrücke die Feldlauf-Live-Übernahme. Die Übernahme prüft vorhandene Mehrstationsfelder, füllt speicherbare Live-Werte per Schaltfläche in die Erfassung und führt denselben Beleg in Bericht und Export; FB2 bleibt weiterhin Labor- und Diagnosepfad.

Ab `v0.9.36` bis `v0.9.38` ergänzt FunkBrücke die Feldlauf-Live-Speicherprüfung. Sie prüft nach der Übernahme Ziel-Fall, Live-Quelle, aktuelle Mehrstationsfelder, Pflichtfelder, Platzhalter und Feldversuchs-Startfreigabe, gibt `Live-Ergebnis speichern` nur bei grüner Speicherlage frei und führt den Speicherbeleg in Bericht und Export; FB2 bleibt weiterhin Labor- und Diagnosepfad.

Ab `v0.9.39` bis `v0.9.41` ergänzt FunkBrücke den Feldlauf-Live-Abschlussabgleich. Er vergleicht das gespeicherte Mehrstations-Ergebnis mit Live-Entwurf, Paket-ID, Erfolgsmarkierung und Speicherprüfung und führt den Abschlussbeleg in Test-Tab, Bericht und Export; FB2 bleibt weiterhin Labor- und Diagnosepfad.

Ab `v0.9.42` bis `v0.9.44` ergänzt FunkBrücke den Feldlauf-Live-Nachversuchauftrag. Er leitet aus offenen Abschlussabgleich-Punkten priorisierte nächste Schritte für Speichern, Ziel-Fall, Feldinhalt, Paketnachweis und Erfolgsmarkierung ab und führt den Auftrag in Test-Tab, Bericht und Export; FB2 bleibt weiterhin Labor- und Diagnosepfad.

Ab `v0.9.45` ergänzt FunkBrücke die Feldlauf-Live-Nachversuch-Abhakliste. Sie macht Nachversuchpunkte bedienbar, führt erledigte Punkte als manuelle Arbeitsmarke und erzwingt bei `Neu prüfen` wieder den echten Live-Abschlussabgleich; FB2 bleibt weiterhin Labor- und Diagnosepfad.

Ab `v0.9.46` ergänzt FunkBrücke die Feldlauf-Live-Nachversuch-Zielfeldhilfe. Ziel-Eingabefeld und vorbereiteter Textbaustein werden im Test-Tab, Bericht und Export geführt; FB2 bleibt weiterhin Labor- und Diagnosepfad.

Ab `v0.9.47` ergänzt FunkBrücke die Feldlauf-Live-Nachversuch-Erledigungsprüfung. Platzhaltertexte blockieren den Erledigt-Haken, und echte Paketdaten werden vor dem erneuten Abschlussabgleich verlangt; FB2 bleibt weiterhin Labor- und Diagnosepfad.

Ab `v0.9.48` ergänzt FunkBrücke die Feldlauf-Live-Nachversuch-Abschlussnachprüfung. Sie bewertet die Freigabe für `Nachversuch neu prüfen`, ohne FB2 produktiv zu aktivieren.

## Modusleiter

Die erste FB2-Modusleiter ist im Core als Planungs- und Bewertungsmodell angelegt.

| Modus | Kurzname | Rolle |
| --- | --- | --- |
| `ZweiFskRobust` | `2F` | robuster Fallback und unbekannte Links |
| `VierFsk` | `4F` | robuster Basisbetrieb |
| `AchtFsk` | `8F` | schneller UKW-Standard |
| `SechzehnMfsk` | `16M` | schneller Einzelträgermodus |
| `ZweiunddreissigMfsk` | `32M` | schnelle gute Strecken |
| `VierundsechzigMfsk` | `64M` | experimentell für sehr saubere Strecken |
| `OfdmRobust` | `OFR` | OFDM mit robuster Trägerbelegung |
| `OfdmNormal` | `OFN` | OFDM-Standardprofil für gute Links |
| `OfdmSchnell` | `OFS` | schnelles OFDM für Labor oder sehr gute UKW-Strecken |

Die hinterlegten Bitraten sind weiterhin Planungs- und Laborwerte. Der lokale Audiopfad kann die komplette Leiter bis OFDM schnell modulieren und demodulieren; vor echtem Funkbetrieb müssen Symbolraten, Trägerzahlen, Synchronisation, FEC, Pegel, Verzerrung und Feldtests gegen die jeweiligen Geräteprofile abgeglichen werden.

## Betriebsprofile Und Bandbreiten

FB2 soll später nicht jeden Modus in jeder Betriebsart anbieten. Die Modusleiter wird zusätzlich durch Betriebsprofile begrenzt:

- `SSB schmal`: für typische SSB-Audiokanäle. Hier sind schmale Modi wie 2-FSK, 4-FSK, 8-FSK und höchstens schmale OFDM-Profile sinnvoll. Breite 32-/64-MFSK-Modi dürfen dort nicht automatisch freigegeben werden.
- `FM normal`: für normale FM-Daten- oder Sprachpfade. 2-FSK bis 8-FSK sind realistisch, 16-MFSK und schmale OFDM-Profile müssen am konkreten Gerät geprüft werden.
- `FM breit/Labor`: für breite UKW-Datenpfade, Laborbetrieb oder explizit freigegebene Tests. Hier können breitere MFSK- und schnellere OFDM-Profile erprobt werden.

Der Grund ist wichtig: Bei SSB wird die Audio-Bandbreite praktisch zur belegten HF-Bandbreite. Bei FM ist das Verhalten anders, aber Audiofilter, Pre-/Deemphasis, Begrenzer und der echte Datenpfad des Funkgeräts können breite oder amplitudenempfindliche Signale trotzdem begrenzen. FunkBrücke soll deshalb später aus Profil, Betriebsart und Frequenz ableiten, welche FB2-Modi überhaupt angeboten werden.

Ab `v0.7.13` sind diese Betriebsprofile im Core modelliert. Jedes Profil kennt erlaubte Modi, Standardmodus, schnellsten erlaubten Modus, maximale Profilbandbreite und einen Hinweistext. Die FB2-Modusdefinitionen enthalten zusätzlich eine geschätzte belegte Bandbreite. Die Oberfläche nutzt das Modell bereits in Planung und Airtime-Anzeige: das aktuelle Profil begrenzt die geplanten FB2-Modi und die Modusleiter zeigt erlaubte oder gesperrte Einträge.

Ab `v0.7.14` ist das FB2-Betriebsprofil nicht mehr nur intern abgeleitet, sondern in Kopfbereich, Mesh-Tab und Profil-Manager auswählbar. Die Auswahl wird im Stationsprofil gespeichert und beim Laden, Exportieren oder Importieren wieder übernommen. Alte Profil-JSONs ohne diesen Wert bleiben kompatibel und starten mit `SSB schmal`.

## Schmalbandkandidaten Bis 2,4 kHz

Ab `v0.7.18` gibt es im Core zusätzlich einen FB2-Schmalbandkatalog. Dieser Katalog ist noch kein produktiver Modemcode, sondern eine belastbare Planungsgrundlage für schnelle und sichere Übertragungen auf typischen SSB-Audiokanälen. Alle SSB-Kandidaten müssen maximal 2,4 kHz breit sein.

| Kurzname | Kandidat | Breite | Grobe Nutzrate | Rolle |
| --- | --- | ---: | ---: | --- |
| `MT63-D` | MT63-/DQPSK-artiger Robustmodus | 2,0 kHz | 100-1000 bit/s | sehr robuster Fallback für schwierige Kanäle |
| `ARDOP-A` | ARDOP-ähnlicher Paketmodus | 2,0 kHz | 200-2400 bit/s | adaptive Paket-/ARQ-Stufe für Notfunk |
| `SC-PSK` | Single-Carrier PSK adaptiv | 2,2 kHz | 600-3200 bit/s | robuster Hauptkandidat mit Equalizer und FEC |
| `COFDM-S` | Schmalband-COFDM | 2,2 kHz | 800-4200 bit/s | Mehrträgerkandidat gegen Fading und Mehrwege |
| `PACTOR-B` | PACTOR-artiger Benchmark | 2,4 kHz | 1000-5200 bit/s | technischer Vergleich, nicht direkt zu kopieren |
| `SC-QAM` | Single-Carrier QAM adaptiv | 2,4 kHz | 1200-6000 bit/s | schnelle Stufe für sehr gute und lineare SSB-Kanäle |

Die empfohlene spätere SSB-Leiter beginnt mit robusten Fallbacks und steigt über adaptive ARQ-/PSK-Profile bis zu QAM. Für FunkBrücke ist dabei wichtig: Schnelle Modi dürfen nur mit sauberer Synchronisation, Interleaver, FEC, ARQ, Soft-Decision-Demodulation und automatischer Rückschaltung auf robuste Stufen geplant werden.

Ab `v0.7.19` zeigt die Oberfläche daraus drei Praxisempfehlungen: `Robust` nutzt den ARDOP-ähnlichen Paketmodus, `Normal` nutzt adaptives Single-Carrier-PSK und `Schnell` nutzt adaptives Single-Carrier-QAM. Der Mesh-Tab zeigt diese Stufen in der FB2-Planung; der TX-Tab nennt denselben Status bei der FB2-Airtime-Schätzung. Es bleibt weiterhin eine Planungshilfe ohne produktiven FB2-Sendepfad.

Ab `v0.7.20` ist die robuste SSB-Stufe als technischer Rahmenplan `SB-R` konkretisiert:

| Feld | Wert |
| --- | --- |
| Bandbreite | 2,0 kHz |
| Symbolrate | 600 Baud |
| Modulation | DBPSK/QPSK adaptiv |
| Rohbitrate | 1200 bit/s |
| geplante Nutzrate | ca. 600 bit/s |
| Synchronwort | 64 bit |
| Präambel | 160 bit |
| Pilot/Training | 96 bit je ARQ-Block |
| Kopf/CRC | 96 bit Kopf plus 32 bit Prüfsumme je Block |
| FEC | Rate 1/2 mit Interleaver |
| Interleaver | 1600 ms |
| ARQ-Blockgröße | 96 Nutzdaten-Byte |
| ACK-Fenster | 1200 ms je Block |
| Wiederholungen | maximal 3 |

Die Airtime-Schätzung für `SB-R` rechnet nicht nur mit Nutzdatenbits, sondern mit Synchronwort, Präambel, Pilot-/Trainingsanteilen, Kopf/CRC, FEC-Ausgangsbits und ACK-Fenstern. Dadurch ist sie deutlich näher an einem echten robusten Paketmodus, bleibt aber weiterhin eine Planungsschicht ohne produktiven Modem-TX.

Ab `v0.7.21` gibt es zusätzlich einen internen `SB-R`-Blockcodec. Er macht aus einer Nutzlast eine geordnete Folge von ARQ-Blöcken und bereitet damit die spätere FEC-/Interleaver-Stufe vor. Es entsteht noch kein PSK-/QAM-Signal und es wird weiterhin nichts über Funk gesendet.

| Blockfeld | Inhalt |
| --- | --- |
| Profilkennung | kompakte Kennung für `SB-R` |
| Sequenznummer | gemeinsamer 16-Bit-Zähler der Blockfolge |
| Blockindex | nullbasierter Index des Blocks |
| Blockanzahl | erwartete Gesamtzahl der Blöcke |
| Nutzdatenlänge | tatsächliche Nutzdaten im Block, maximal 96 Byte |
| Nutzdaten-CRC | CRC-16/CCITT über die Blocknutzdaten |
| Kopf-CRC | CRC-16/CCITT über Kopf und Nutzdaten-CRC |
| FEC-Eingang | Blockkopf mit Prüfsummen plus Blocknutzdaten |

Der Codec kann Blöcke einzeln prüfen, beschädigte Kopf-, Nutzdaten- oder FEC-Eingangsdaten erkennen und eine vollständige Blockfolge wieder zur ursprünglichen Nutzlast zusammensetzen. Die Oberfläche zeigt daraus Blockanzahl, maximale Blockgröße und FEC-Eingangsbits für die aktuelle Referenznutzlast.

Ab `v0.7.22` folgt darauf eine interne `SB-R`-FEC-/Interleaver-Laborstufe. Sie ist ausdrücklich noch keine finale Kanalcodierung, sondern eine reproduzierbare technische Stufe zwischen Blockcodec und späterer Symbolabbildung.

| Stufe | Verhalten |
| --- | --- |
| Systematische Daten | übernehmen die FEC-Eingangsdaten des Blockcodecs unverändert |
| Paritätsdaten | pro Eingangbyte ein deterministisch berechnetes Paritätsbyte |
| Labor-FEC-Rate | 1/2, also doppelt so viele codierte Bits wie Eingangbits |
| Byte-Reihenfolge | Originalbyte und Paritätsbyte wechseln sich ab |
| Interleaver | vierzeilige Byte-Verschachtelung innerhalb der geplanten `SB-R`-Interleaver-Tiefe |
| Prüfung | Parität, codierte Bytes, Interleaver-CRC und Rückverschachtelung werden verifiziert |

Diese Stufe macht FEC- und Interleaver-Overhead erstmals als konkrete Bytefolge testbar. Sie erzeugt noch keine DBPSK-/QPSK-Symbole, keine Audiosamples und keinen produktiven Funk-Sendepfad.

Ab `v0.7.23` gibt es auf Basis dieser Interleaverbytes einen internen `SB-R`-Symbolplaner. Er erzeugt noch keine Phasen- oder Audiosamples, legt aber die spätere Symbolabbildung reproduzierbar fest.

| Symbolgruppe | Modulation | Bits pro Symbol | Rolle |
| --- | --- | ---: | --- |
| Blockstart | DBPSK | 1 | robuster Einstieg für Synchronisation und Kopfanteile |
| Nutzteil | QPSK | 2 | schnellerer Teil des verschachtelten Blocks |

Der Symbolplaner berechnet Startbit, Bitanzahl, Symbolanzahl, Symbolwerte und eine CRC über die Symbolwerte. Damit kann FunkBrücke beschädigte Symbolgruppen bereits erkennen, bevor eine echte DBPSK-/QPSK-Wellenform existiert.

Ab `v0.7.24` folgt ein interner `SB-R`-Phasenplaner. Er übersetzt die Symbolwerte in differenzielle Phasenwechsel und berechnet daraus Zielphase und I/Q-Konstellationspunkt.

| Modulation | Symbolwert | Phasenwechsel |
| --- | ---: | ---: |
| DBPSK | 0 | 0° |
| DBPSK | 1 | 180° |
| QPSK | 0 | 45° |
| QPSK | 1 | 135° |
| QPSK | 2 | 315° |
| QPSK | 3 | 225° |

Der Phasenplan führt die Phase blockübergreifend fort, normalisiert sie auf 0° bis 359° und speichert pro Symbol den I/Q-Punkt auf dem Einheitskreis. Eine Phasenprüfsumme je Gruppe macht die Stufe testbar. Noch entstehen keine Audiosamples, keine Pulsformung und kein produktiver Sendepfad.

Ab `v0.7.25` folgt ein interner `SB-R`-Basisbandplaner. Er verbindet Phasenpunkte mit einer konkreten Sample-Zeitplanung, erzeugt aber weiterhin keine Audiosamples.

| Feld | Wert |
| --- | --- |
| Standard-Abtastrate | 48 kHz |
| Symbolrate im Profil `SB-R` | 600 Baud |
| Samples pro Symbol | 80 |
| Pulsformung | Raised-Cosine geplant |
| Roll-off | 0,35 |
| Prüfbarkeit | Segment- und Blockprüfsummen |

Jeder Phasenpunkt wird zu einem Basisbandsegment mit globalem Symbolindex, Startsample, Sampleanzahl, Startzeit, Dauer, geplanter Pulsformung und Amplitudenfenster. Der erste Segmentstart fährt von 0 auf, das letzte Segment fährt wieder auf 0 ab. Diese Stufe ist bewusst nur eine interne Planungs- und Prüfschicht: Es gibt noch keine Sample-Synthese, keine Audioausgabe und keinen produktiven `SB-R`-Sendepfad.

Ab `v0.7.26` erzeugt eine interne `SB-R`-Sample-Synthese aus dem Basisbandplan erstmals konkrete Labor-Samples. Es handelt sich um normalisierte komplexe I/Q-Basisbandsamples, nicht um Audioausgabe.

| Feld | Verhalten |
| --- | --- |
| Samplequelle | Basisbandsegmente aus `v0.7.25` |
| Samples pro Symbol | 80 bei 48 kHz und 600 Baud |
| Phasenverlauf | geglättete Interpolation vom Start- zum Zielwinkel |
| Hüllkurve | Raised-Cosine-Fenster für Auf- und Abfahren |
| Messwerte | Peak und RMS je Segment, Block und Plan |
| Prüfbarkeit | Sample-, Block- und Planprüfsummen |

Die Synthese hält die differenzielle Phase aus dem Phasenplan ein, behandelt Phasenwechsel über 180° als kürzesten negativen Weg und berechnet pro Sample I, Q, Zeit und Amplitude. Diese Daten sind für spätere Demodulator- und Loopbacktests gedacht. Es gibt weiterhin keine Audioausgabe, keine PTT-Ansteuerung und keinen produktiven `SB-R`-Sendepfad.

Ab `v0.7.27` folgt ein interner `SB-R`-Loopback. Er wertet die erzeugten I/Q-Samples wieder aus und prüft, ob die geplanten Symbolwerte und Zielphasen aus der Samplefolge zurückgewonnen werden können.

| Feld | Verhalten |
| --- | --- |
| Quelle | interne I/Q-Samples aus `v0.7.26` |
| Phasenschätzung | lineare Schätzung über Samples mit ausreichender Amplitude |
| Symbolrückgewinnung | DBPSK und QPSK anhand des gemessenen Phasenwechsels |
| Qualitätswerte | gültige Symbole, maximaler Phasenfehler, mittlere Amplitude |
| Fehlererkennung | verdrehte Samplephasen werden als ungültig markiert |
| Prüfbarkeit | Loopback-Prüfsummen je Segment, Block und Plan |

Der Loopback nutzt noch keinen Audioeingang und ist keine echte Funk-Demodulation. Er ist die erste interne Rundlaufprüfung für den `SB-R`-Schmalbandpfad: Blockcodec, FEC, Symbolplan, Phasenplan, Basisband, Sample-Synthese und Symbolrückgewinnung können damit schrittweise verbunden und beschädigte Samplefolgen erkannt werden.

Ab `v0.7.28` folgt eine interne `SB-R`-Datenrückabbildung. Sie setzt die zurückgewonnenen DBPSK-/QPSK-Symbolwerte wieder zu dem verschachtelten Bytebild zusammen, aus dem der Symbolplan ursprünglich erzeugt wurde.

| Feld | Verhalten |
| --- | --- |
| Quelle | gültige oder beschädigte Loopback-Symbole aus `v0.7.27` |
| Symbol-zu-Bit-Abbildung | DBPSK mit 1 Bit/Symbol, QPSK mit 2 Bit/Symbol, jeweils gruppengenau |
| Interleaverbytes | aus den zurückgewonnenen Symbolbits wieder zusammengesetzt |
| FEC-Rücklauf | Entschachtelung zu codierten Labor-FEC-Bytes |
| Aufteilung | systematische FEC-Eingangsbytes und Paritätsbytes werden getrennt geprüft |
| Fehlererkennung | Bytefehler, gültige Blöcke und Prüfsummen je Block und Gesamtplan |

Damit ist die interne Laborkette vom `SB-R`-Blockcodec bis zu I/Q-Samples und wieder zurück auf die FEC-nahe Datenebene geschlossen. Es gibt weiterhin keinen Audioeingang, keine echte Kanalschätzung, keine PTT-Ansteuerung und keinen produktiven `SB-R`-Sendepfad.

Ab `v0.7.29` rekonstruiert eine interne `SB-R`-Nutzdatenrückgewinnung aus den systematischen FEC-Eingangsbytes wieder Blockkopf und Nutzdaten.

| Feld | Verhalten |
| --- | --- |
| Quelle | systematische FEC-Eingangsbytes aus dem Datenrücklauf |
| Blockkopf | Profilkennung, Sequenz, Blockindex, Blockanzahl, Nutzdatenlänge und Kopf-CRC |
| Nutzdatenprüfung | Nutzdaten-CRC und Bytevergleich gegen den ursprünglichen Laborblock |
| Blockfolge | gültige Blöcke werden sortiert wieder zur ursprünglichen Nutzlast zusammengesetzt |
| Fehlererkennung | beschädigte Kopfprüfsumme, Nutzdatenfehler, FEC-Eingangsfehler und unvollständige Blockfolgen |
| Oberfläche | gültige Nutzdatenblöcke, Nutzdatenbytes, Bytefehler und Plan-CRC |

Damit ist der interne `SB-R`-Laborpfad vom Nutzdatenblock über FEC, Interleaver, Symbol-, Phasen-, Basisband- und Sampleebene bis zurück zur zusammengesetzten Nutzlast prüfbar. Es gibt weiterhin keinen Audioeingang, keine echte Funk-Demodulation, keine PTT-Ansteuerung und keinen produktiven `SB-R`-Sendepfad.

Ab `v0.7.30` bündelt ein interner `SB-R`-Rundlaufstatus alle Laborstufen. Zusätzlich entsteht eine vorbereitete RX-Übergabe für spätere FB2-RX-Verarbeitung.

| Feld | Verhalten |
| --- | --- |
| Stufen | Blockcodec, FEC/Interleaver, Symbolplan, Phasenplan, Basisband, I/Q-Samples, Audio-RX-Vorstufe, Sync, Training, Symbolfenster, Symbolabtastung, Demapper, Audio-RX-Datenrücklauf, Audio-RX-Nutzdatenrücklauf, Loopback, Datenrücklauf, Nutzdatenrücklauf, RX-Pfadauswahl, RX-Übergabe, RX-Laborannahme, RX-Schattenannahme und RX-Verarbeitungskandidat |
| Stufenwerte | Kurzname, Anzeige, Elementzahl, Gültigkeit, Kurzmeldung und Prüfsumme |
| Gesamtstatus | gültige und fehlerhafte Stufen, Kurzstatus und Rundlauf-CRC |
| RX-Übergabe | rückgewonnene Nutzlast, Nutzdaten-CRC, Bereit-Flag und Hinweis |
| Fehlerverhalten | fehlerhafte Rundläufe sperren die RX-Übergabe und behalten die Stufenfehler sichtbar |
| Oberfläche | Rundlaufstatus und RX-Übergabestatus in Mesh- und TX-Planung |

Diese Stufe verbindet noch keinen echten Audioeingang und dekodiert noch keine produktiven FB2-Pakete. Sie schafft aber einen klaren internen Übergabepunkt: Sobald ein echter `SB-R`-RX existiert, kann dessen Nutzlast dieselbe Prüflogik und spätere FB2-RX-Verarbeitung verwenden.

Ab `v0.7.31` folgt auf die RX-Übergabe eine interne FB2-RX-Laborannahme.

| Feld | Verhalten |
| --- | --- |
| Quelle | rückgewonnene `SB-R`-Nutzlast aus der RX-Übergabe |
| Laborpayload | Nutzlast ohne `FB2`-Rahmenkopf wird angenommen und bleibt als nicht produktiver RX-Kandidat sichtbar |
| FB2-Rahmen | gültige `FB2`-Rahmen werden aus der Nutzlast gesucht, dekodiert und mit Rahmenkopf übernommen |
| Fehlerverhalten | defekte `FB2`-Kandidaten werden verworfen und sperren die Rundlaufstufe `RXL` |
| Prüfsumme | Annahme-CRC über Übergabe, Quelle, Rahmenstatus und Meldung |
| Oberfläche | Annahmestatus, erkannter FB2-Rahmen oder Laborpayload und Annahme-CRC in Mesh- und TX-Planung |

Auch diese Stufe verbindet noch keinen echten Audioeingang. Sie bereitet nur den sicheren Übergang von der späteren `SB-R`-Demodulation zur bestehenden FB2-Rahmenverarbeitung vor.

Ab `v0.7.32` erzeugt diese Laborannahme einen internen FB2-RX-Verarbeitungskandidaten.

| Feld | Verhalten |
| --- | --- |
| Quelle | geprüfte RX-Laborannahme |
| Zielpfad | bestehende FB2-RX-Verarbeitung der App |
| Laborpayload | bleibt gültig, aber nicht übergabebereit, wenn kein FB2-Rahmen enthalten ist |
| FB2-Rahmen | wird mit Rahmenkopf, RahmenText, Quellpfad, Zielpfad und Kandidaten-CRC bereitgestellt |
| Fehlerverhalten | gesperrte Laborannahmen sperren auch den Verarbeitungskandidaten |
| Oberfläche | neue Stufe `RXP` sowie RX-Verarbeitungsstatus in Mesh- und TX-Planung |

Die App übernimmt neue bereitstehende Labor-FB2-Rahmen einmalig in die bestehende FB2-RX-Verarbeitung. Die Kandidaten-CRC verhindert dabei doppelte Laborübernahmen durch wiederholte Planungsaktualisierungen. Es bleibt ein Laborpfad ohne echten `SB-R`-Audioempfang.

Ab `v0.7.33` fasst ein internes RX-Kettenereignis die drei Übergabepunkte `RX`, `RXL` und `RXP` zusammen.

| Feld | Verhalten |
| --- | --- |
| Status | `Geprüft`, `Bereit`, `Sperre RX`, `Sperre RXL` oder `Sperre RXP` |
| Meldung | kompakter Sperrgrund oder Hinweis zur geprüften Nutzlast |
| Nächste Aktion | kurze Empfehlung für Laboransicht und Bedienung |
| Ereignis-CRC | Prüfsumme über RX-Übergabe, Laborannahme, Verarbeitungskandidat und Meldung |
| Oberfläche | kompakte RX-Kettenzeile in Mesh/TX und dedupliziertes `SB-R-RX`-Ereignis in der FB2-Laborübersicht |

Damit kann der interne `SB-R`-RX-Pfad auch dann nachvollzogen werden, wenn kein FB2-Rahmen übergeben wird oder eine Stufe den Kandidaten bewusst sperrt.

Ab `v0.7.34` liegt vor Loopback und Nutzdatenrücklauf eine interne Audio-RX-Vorstufe für `SB-R`.

| Feld | Verhalten |
| --- | --- |
| Snapshot | beschreibt den erwarteten 48-kHz-Eingangspuffer als Rahmenmetadaten |
| Fenster | Präambel, Synchronwort, Pilot-/Trainingfenster je Block und Datenfenster je Block |
| Synchronisation | Start und Länge des Synchronwortfensters sowie erstes Datenfenster werden samplescharf festgehalten |
| Prüfung | Snapshot-CRC über Sampleplan, Fenster, Sync-Position, Datenstart und Bereitschaft |
| Rundlauf | neue Stufe `ARX` zwischen I/Q-Samples und Loopback |
| Abgrenzung | noch keine produktive Demodulation und kein neuer Schmalband-TX |

Diese Vorstufe schafft die Karte für den späteren echten Audio-RX: Erst wenn der Eingangspuffer, die Synchronwortsuche und die Fensterlogik sauber sind, wird daraus eine produktive `SB-R`-Demodulation.

Ab `v0.7.35` bewertet eine interne Synchronwort-Erkennung dieses vorbereitete Fenster.

| Feld | Verhalten |
| --- | --- |
| Suchfenster | liegt um den erwarteten Synchronwortstart und enthält Reserve vor und nach dem Sync-Fenster |
| Treffer | hält erwarteten Start, gefundene Position und Timing-Abweichung in Samples und Millisekunden fest |
| Qualität | grobe Prozentbewertung aus Timing-Abweichung und Suchfensterlage |
| Prüfsummen | deterministische Synchronwort-CRC und Treffer-CRC |
| Rundlauf | neue Stufe `ARS` zwischen `ARX` und Loopback |
| Abgrenzung | noch keine Nutzdaten-Demodulation, kein Equalizer und kein produktiver Schmalband-TX |

Damit kann FunkBrücke bereits unterscheiden, ob ein späterer Eingangspuffer zeitlich plausibel zum `SB-R`-Rahmen passt. Die eigentliche Symbol- und Nutzdaten-Demodulation bleibt ein Folgeschritt.

Ab `v0.7.36` folgt eine interne Pilot-/Trainingfenster-Auswertung.

| Feld | Verhalten |
| --- | --- |
| Pilotfenster | alle `PIL`-Fenster aus dem Audio-RX-Snapshot werden einzeln bewertet |
| Frequenzsuche | Laborziel ±100 Hz Suchbereich |
| Restabweichung | Zielwert maximal 20 Hz nach Training |
| Korrekturen | Frequenz-, Phasen- und Taktkorrektur werden als Metadaten vorbereitet |
| Rundlauf | neue Stufe `ART` zwischen `ARS` und Loopback |
| Abgrenzung | noch keine Symbolkorrektur auf echten RX-Samples und keine Nutzdaten-Demodulation |

Diese Stufe nimmt den späteren Equalizer- und Trackingpfad vorweg. Sie entscheidet noch nicht über Nutzdaten, zeigt aber, ob Sync und Pilotfenster genug Grundlage für Frequenz- und Phasennachführung liefern.

Ab `v0.7.37` plant FunkBrücke daraus korrigierte Symbolfenster für die späteren Datenbereiche.

| Feld | Verhalten |
| --- | --- |
| Quelle | alle `DAT`-Fenster aus dem Audio-RX-Snapshot |
| Startkorrektur | Timing aus dem Synchronworttreffer plus Taktkorrektur aus dem passenden Pilotfenster |
| Metadaten je Fenster | Rohstart, korrigierter Start, Symbolanzahl, Restfrequenz, Phasenkorrektur, Qualität und CRC |
| Rundlauf | neue Stufe `ARF` zwischen `ART` und Loopback |
| Abgrenzung | noch keine Symbolabtastung, keine Softentscheidungen und keine Nutzdaten-Demodulation |

Damit ist der spätere Demodulator-Einstieg genauer vorbereitet: Die App weiß jetzt, welche korrigierten Datenfenster aus dem Eingangspuffer abgetastet werden müssten, ohne bereits produktive Nutzdaten daraus zu gewinnen.

Ab `v0.7.38` folgt eine interne Symbolabtast-/Softentscheidungsplanung.

| Feld | Verhalten |
| --- | --- |
| Quelle | korrigierte `ARF`-Datenfenster und interne DBPSK-/QPSK-Symbolsegmente |
| Abtastpunkte | Abtaststart, Abtastmitte und Abtastende je Symbol |
| erwartete Entscheidung | Modulation, Symbolwert und Softbit-Anzahl als Metadaten |
| Rundlauf | neue Stufe `ARA` zwischen `ARF` und Loopback |
| Abgrenzung | noch kein echter Samplevergleich, kein Demapper-Rücklauf und keine Nutzdaten-Demodulation |

Damit ist der spätere Demapper vorbereitet: Die App kennt nun die Abtaststellen und die erwartete Symbolstruktur, entscheidet aber noch nicht aus echten RX-Samples.

Ab `v0.7.39` gruppiert ein interner Audio-RX-Demapper diese geplanten Abtastpunkte zu erwarteten Softbits.

| Feld | Verhalten |
| --- | --- |
| Quelle | geplante `ARA`-Abtastpunkte mit erwarteter DBPSK-/QPSK-Symbolstruktur |
| Softbits | Blockindex, Symbolindex, Bitindex, erwarteter Bitwert, Zuverlässigkeit und CRC je Softbit |
| Gruppen | DBPSK- und QPSK-Softbits werden blockweise für den späteren FEC-Rücklauf zusammengefasst |
| Rundlauf | neue Stufe `ADM` zwischen `ARA` und Loopback |
| Abgrenzung | noch keine echte Sampleentscheidung, kein produktiver Demapper-Rücklauf und keine Nutzdaten-Demodulation |

Damit ist die spätere Brücke von Symbolabtastung zu Interleaver-/FEC-nahen RX-Daten klarer vorbereitet. Die Stufe ist weiterhin deterministische Laborlogik und nutzt noch keine echten empfangenen Audiosamples.

Ab `v0.7.40` führt ein interner Audio-RX-Datenrücklauf diese Demapper-Softbits wieder in FEC-nahe Bytefolgen zurück.

| Feld | Verhalten |
| --- | --- |
| Quelle | `ADM`-Softbits und blockweise DBPSK-/QPSK-Gruppen |
| Rücklauf | Interleaverbytes, codierte FEC-Bytes, systematische FEC-Eingangsbytes und Paritätsbytes |
| Prüfung | Softbitfehler, Byteabweichungen zum internen FEC-Referenzpfad und CRCs |
| Rundlauf | neue Stufe `ARD` zwischen `ADM` und Loopback |
| Abgrenzung | noch keine echte Sampleentscheidung und noch keine produktive Nutzdaten-Demodulation aus Audio-RX |

Damit ist die spätere Verbindung vom Audio-RX-Demapper zum vorhandenen Blockkopf-/Nutzdatenrücklauf vorbereitet. Die Stufe arbeitet noch mit geplanten Softbits, nicht mit echten Entscheidungen aus empfangenen Audiosamples.

Ab `v0.7.41` rekonstruiert ein interner Audio-RX-Nutzdatenrücklauf aus diesen `ARD`-FEC-Eingangsbytes wieder Blockkopf, Nutzdatenblöcke und vollständige Nutzlast.

| Feld | Verhalten |
| --- | --- |
| Quelle | systematische FEC-Eingangsbytes aus dem Audio-RX-Datenrücklauf |
| Rückgewinnung | Blockkopf, Nutzdaten, FEC-Eingang und zusammengesetzte Nutzlast |
| Prüfung | Kopf-CRC, Nutzdaten-CRC, FEC-Eingangsvergleich, Bytefehler und Blockfolge |
| Rundlauf | neue Stufe `ARN` zwischen `ARD` und Loopback |
| Oberfläche | gültige Blöcke, Nutzdatenbytes, Bytefehler und Plan-CRC in Mesh- und TX-Planung |
| Abgrenzung | noch keine echte Sampleentscheidung und noch keine produktive Nutzdaten-Demodulation aus Audio-RX |

Damit ist die spätere Verbindung vom Audio-RX-Datenrücklauf zur bestehenden Nutzdatenprüfung vorbereitet. Noch bleibt der Pfad ein deterministischer Referenzlauf, damit echte Sampleentscheidungen später kontrolliert gegen dieselbe Logik laufen können.

Ab `v0.7.42` bewertet eine interne RX-Pfadauswahl den Audio-RX-Nutzdatenrücklauf und den bisherigen Loopback-Nutzdatenrücklauf als getrennte Übergabekandidaten.

| Feld | Verhalten |
| --- | --- |
| Kandidaten | Audio-RX-Nutzdatenrücklauf und Loopback-Nutzdatenrücklauf |
| Aktiver Pfad | vorerst `LBK`, also der kontrollierte Loopback-Laborpfad |
| Audio-RX | technisch prüfbar, aber noch nicht für die produktive RX-Übergabe freigegeben |
| Rundlauf | neue Stufe `RXS` zwischen Nutzdatenrücklauf und RX-Übergabe |
| Oberfläche | aktiver Pfad, Audio-RX-Kandidat, Loopback-Kandidat, Nutzdatenbytes und CRC |
| Abgrenzung | noch keine echte Sampleentscheidung und noch keine Umschaltung auf produktiven Audio-RX |

Damit ist die spätere Umschaltung vorbereitet, ohne den bisherigen Laborpfad zu verlieren. Die RX-Übergabe bleibt kontrolliert am Loopback-Pfad, solange der Audio-RX-Pfad noch keine echten Sampleentscheidungen verarbeitet.

Ab `v0.7.43` prüft eine interne RX-Schattenannahme den Audio-RX-Kandidaten parallel zur aktiven Loopback-Laborannahme.

| Feld | Verhalten |
| --- | --- |
| Quelle | Audio-RX-Kandidat aus der RX-Pfadauswahl und aktive Loopback-Laborannahme |
| Audio-RX-Annahme | dekodiert Laborpayloads und gültige `FB2`-Rahmen wie eine Annahme, übernimmt aber nichts produktiv |
| Vergleich | Nutzdaten-Gleichheit, Annahme-Gleichheit und FB2-Rahmenstatus gegen den aktiven Loopback-Pfad |
| Prüfsumme | eigene Schatten-CRC über Kandidaten, aktive Annahme, Vergleichsstatus und Meldung |
| Rundlauf | neue Stufe `RSH` zwischen `RXL` und `RXP` |
| Oberfläche | Schattenannahmestatus, Bytezahl, Nutzdatenvergleich, Annahmevergleich und CRC in Mesh- und TX-Planung |
| Abgrenzung | keine aktive Übergabe, keine echte Sampleentscheidung und keine produktive Nutzdaten-Demodulation |

Damit kann der spätere Audio-RX-Pfad schon gegen die kontrollierte Loopback-Annahme laufen. Erst wenn diese Schattenprüfung auch mit echten Samples zuverlässig deckungsgleich bleibt, kommt eine Umschaltung der aktiven RX-Übergabe infrage.

Ab `v0.7.44` ist diese Schattenannahme Bestandteil des kompakten RX-Kettenereignisses.

| Feld | Verhalten |
| --- | --- |
| Ereignisquelle | RX-Übergabe, RX-Laborannahme, RX-Schattenannahme und RX-Verarbeitungskandidat |
| Schattenabweichung | ungültige oder abweichende `RSH`-Prüfungen erzeugen den Status `Sperre RSH` |
| Verarbeitungsschutz | bei einer Kettensperre durch `RSH` wird kein FB2-RX-Verarbeitungskandidat übernommen |
| Laborübersicht | Schattenabweichungen erscheinen als eigenes `SB-R-RSH`-Ereignis mit Sperrgrund und nächster Aktion |
| Abgrenzung | weiterhin keine aktive Umschaltung auf Audio-RX und keine produktive Nutzdaten-Demodulation |

Damit wird der Schattenpfad nicht nur als Messwert, sondern als kontrollierter Sicherheitszustand geführt. Sobald echter Audio-RX in diese Kette eingespeist wird, kann FunkBrücke Abweichungen früh melden, ohne den stabilen Loopback-Laborpfad zu verlieren.

Ab `v0.7.45` wird dieser Schattenpfad mit einer vorbereiteten Audio-RX-Kandidatenquelle aus dem echten Audioeingangspuffer verbunden.

| Feld | Verhalten |
| --- | --- |
| Quelle | `SB-R-Eingangspuffer` mit Sampleanzahl, Abtastrate, Dauer und Aktivstatus |
| Bereitstatus | der Puffer gilt ab 0,5 s Audio bei aktivem Eingang als vorbereitete Schattenquelle |
| Prüfsumme | eigene Quellen-CRC fließt in die Schatten-CRC ein |
| Oberfläche | Mesh- und TX-Planung zeigen eine eigene `FB2-Schmalband-RX-Quelle`-Zeile |
| Abgrenzung | die Schattenannahme nutzt weiterhin die stabile Laborreferenz; echte Samples treffen noch keine produktive Entscheidung |

Damit ist die spätere echte Eingangspuffer-Auswertung an die Sicherheitskette angebunden, ohne die kontrollierte Loopback-Annahme zu ersetzen. Der nächste Schritt kann gezielt eine echte Synchronwortsuche auf dieser Quelle vorbereiten.

Ab `v0.7.51` sind die geplanten Schritte `v0.7.46` bis `v0.7.51` als zusammengefasste Audio-RX-Schattenkette umgesetzt.

| Feld | Verhalten |
| --- | --- |
| Stufen | Synchronwortsuche, Pilot-/Training, Symbolfenster, Demapper, FEC-/Interleaver-Rücklauf und Nutzdatenrücklauf |
| Eingangspufferbewertung | meldet pro Stufe, ob genügend Samples vorhanden sind und die interne Referenzstufe prüfbar ist |
| Fortschritt | bereite Stufen, Prozentwert, fehlende Samples und nächste Aktion |
| Prüfsumme | eigene Ketten-CRC, zusätzlich in der Schattenannahme eingebunden |
| Oberfläche | neue `FB2-Schmalband-RX-Schattenkette`-Zeile in Mesh- und TX-Planung |
| Abgrenzung | Diagnose- und Schattenmetadaten, keine produktive Sampleentscheidung und keine automatische RX-Umschaltung |

Damit ist der komplette geplante Schattenpfad vom Sync bis zur Nutzdatenrückgewinnung in einer Sicherheitskette sichtbar. Unvollständige Eingangspuffer werden als Diagnose geführt, blockieren aber nicht die stabile Loopback-Laborannahme.

Ab `v0.7.52` ergänzt FunkBrücke eine kontrollierte Audio-RX-Testauswertung für echte bzw. aufgezeichnete `SB-R`-Samples.

| Feld | Verhalten |
| --- | --- |
| Testaufzeichnung | bewertet Sampleanzahl, Abtastrate, Dauer, Peak, RMS, Gleichanteil und Vorzeichenwechsel |
| Signatur | eine Sample-Signatur-CRC macht Änderungen an der kontrollierten Aufnahme sichtbar |
| Rahmenvergleich | prüft Aufzeichnungslänge, Abtastrate und Pegel gegen den erwarteten `SB-R`-Rahmen |
| Rundlauf | neue Stufe `RXT` hinter der Audio-RX-Schattenkette |
| Oberfläche | neue `FB2-Schmalband-RX-Testauswertung`-Zeile in Mesh- und TX-Planung |
| Abgrenzung | auswertbare Testaufnahmen bleiben ohne produktive RX-Freigabe und ohne automatische Umschaltung |

Damit kann der spätere echte Samplepfad mit realen Aufnahmegrößen und Pegelwerten geprobt werden, während die Nutzdatenübergabe weiterhin kontrolliert beim Loopback-Laborpfad bleibt.

Ab `v0.7.53` folgt darauf eine kontrollierte Audio-RX-Sampleentscheidung für die Testaufnahme.

| Feld | Verhalten |
| --- | --- |
| Abtastung | nutzt die geplanten Symbolmitten aus dem `SB-R`-Abtastplan |
| Entscheidung | ordnet jeden Samplewert einem erwarteten Symbolwert zu |
| Referenzvergleich | zählt Treffer und Abweichungen gegen die Laborreferenz |
| Rundlauf | neue Stufe `RSE` hinter der Testauswertung `RXT` |
| Oberfläche | neue `FB2-Schmalband-RX-Sampleentscheidungen`-Zeile in Mesh- und TX-Planung |
| Abgrenzung | auch vollständige Treffer bleiben Diagnose und geben den produktiven RX-Pfad nicht frei |

Damit ist erstmals nicht nur die Aufnahme selbst, sondern eine reproduzierbare symbolnahe Entscheidung sichtbar. Die Nutzdatenübergabe bleibt trotzdem beim sicheren Loopback-Laborpfad.

Ab `v0.7.54` folgt darauf eine kontrollierte Softbitdiagnose aus den Sampleentscheidungen.

| Feld | Verhalten |
| --- | --- |
| Quelle | nutzt die entschiedenen Symbolwerte aus `RSE` |
| Diagnose | leitet erwartete und entschiedene Bitwerte je Symbol ab |
| Referenzvergleich | zählt Softbit-Treffer und Abweichungen gegen die Laborreferenz |
| Rundlauf | neue Stufe `RSB` hinter den Sampleentscheidungen `RSE` |
| Oberfläche | neue `FB2-Schmalband-RX-Softbitdiagnose`-Zeile in Mesh- und TX-Planung |
| Abgrenzung | auch vollständige Softbit-Treffer bleiben Diagnose und geben den produktiven RX-Pfad nicht frei |

Damit kann der echte Samplepfad erstmals bitnah gegen die bestehende Demapper-Referenz beobachtet werden. Die Nutzdatenübergabe bleibt weiter beim sicheren Loopback-Laborpfad.

Ab `v0.7.55` folgt darauf eine kontrollierte Demapperdiagnose aus den Softbitentscheidungen.

| Feld | Verhalten |
| --- | --- |
| Quelle | nutzt die entschiedenen Softbits aus `RSB` |
| Gruppierung | bündelt Softbits blockweise nach Demapper-Gruppe und Modulation |
| Referenzvergleich | vergleicht erwartete und entschiedene Bitfolgen je Gruppe |
| Rundlauf | neue Stufe `RSD` hinter der Softbitdiagnose `RSB` |
| Oberfläche | neue `FB2-Schmalband-RX-Demapperdiagnose`-Zeile in Mesh- und TX-Planung |
| Abgrenzung | auch vollständige Gruppentreffer bleiben Diagnose und geben den produktiven RX-Pfad nicht frei |

Damit kann der echte Samplepfad erstmals gruppennah gegen die bestehende Demapper-Referenz beobachtet werden. Der Datenrücklauf bleibt noch Laborpfad und wird nicht produktiv aus den Diagnosedaten gespeist.

Ab `v0.7.56` folgt darauf eine kontrollierte Datenrücklaufdiagnose aus den gruppierten Demapperdiagnosebits.

| Feld | Verhalten |
| --- | --- |
| Quelle | nutzt die entschiedenen Bitfolgen aus `RSD` |
| Bytebildung | packt die RSD-Bits blockweise zu erwarteten und entschiedenen Byte-Kandidaten |
| Referenzvergleich | zählt Byte-Treffer, Byteabweichungen und Bitabweichungen gegen die Laborreferenz |
| Rundlauf | neue Stufe `RDD` hinter der Demapperdiagnose `RSD` |
| Oberfläche | neue `FB2-Schmalband-RX-Datenrücklaufdiagnose`-Zeile in Mesh- und TX-Planung |
| Abgrenzung | auch vollständige Byte-Treffer bleiben Diagnose und geben den produktiven RX-Pfad nicht frei |

Damit kann der echte Samplepfad erstmals byteweise gegen die bestehende Datenrücklauf-Referenz beobachtet werden. FEC- und Nutzdatenrückgewinnung bleiben weiterhin Laborpfad und werden nicht produktiv aus den Diagnosedaten gespeist.

Ab `v0.7.57` folgt darauf eine kontrollierte FEC-/Nutzdatendiagnose aus den RDD-Byte-Kandidaten.

| Feld | Verhalten |
| --- | --- |
| Quelle | nutzt die entschiedenen Byte-Kandidaten aus `RDD` |
| FEC-Spiegelung | entschachtelt RDD-Bytes, trennt systematische FEC-Eingangsbytes und Paritätsbytes |
| Nutzdatenprüfung | versucht Blockkopf und Nutzdaten aus den FEC-Eingangsbytes zu rekonstruieren |
| Referenzvergleich | zählt Interleaver-, codierte, FEC-Eingangs-, Paritäts- und Nutzdatenabweichungen |
| Rundlauf | neue Stufe `RDF` hinter der Datenrücklaufdiagnose `RDD` |
| Oberfläche | neue `FB2-Schmalband-RX-FEC-/Nutzdatendiagnose`-Zeile in Mesh- und TX-Planung |
| Abgrenzung | auch vollständige FEC-/Nutzdaten-Treffer bleiben Diagnose und geben den produktiven RX-Pfad nicht frei |

Damit kann der echte Samplepfad erstmals bis zu Blockkopf und Nutzdaten gegen die bestehende Referenz beobachtet werden. Die RX-Pfadauswahl und produktive Übergabe bleiben weiter gesperrt.

Ab `v0.7.58` werden diese diagnostisch rückgewonnenen `RDF`-Nutzdaten als gesperrter Audio-RX-Schattenkandidat in die RX-Pfadauswahl geführt.

| Feld | Verhalten |
| --- | --- |
| Quelle | nutzt die gültige `RDF`-FEC-/Nutzdatendiagnose |
| Kandidat | eigener Pfadkurzname `RDF` neben `ARX` und `LBK` |
| Prüfdaten | hält Sequenznummer, Nutzdatenbytes, Nutzdaten-CRC, Kandidatenstatus und Kandidaten-CRC fest |
| Rundlauf | `RXS` meldet Audio-RX, `RDF`-Schatten und Loopback gemeinsam |
| Oberfläche | die `FB2-Schmalband-RX-Pfadauswahl` zeigt zusätzlich `RDF-Schatten` mit Bytezahl und CRC |
| Abgrenzung | der `RDF`-Kandidat bleibt immer gesperrt und wird nicht produktiv ausgewählt |

Damit kann der echte Samplepfad erstmals als eigener Kandidat neben dem bisherigen Audio-RX-Referenzpfad und dem sicheren Loopback-Laborpfad beobachtet werden. Auch vollständige Übereinstimmung führt noch nicht zu einer produktiven RX-Umschaltung.

Ab `v0.7.59` bewertet die RX-Pfadauswahl diese drei Kandidaten paarweise.

| Feld | Verhalten |
| --- | --- |
| Paare | `ARX/LBK`, `RDF/LBK` und `ARX/RDF` |
| Abweichungen | zählt Byteabweichungen je vergleichbarem Paar, inklusive Längenabweichungen |
| Sperrgrund | meldet nicht vergleichbare Kandidaten und echte Byteabweichungen kompakt |
| Prüfsumme | eigener Vergleichs-CRC, zusätzlich in Auswahl- und Schattenannahme-CRC enthalten |
| Oberfläche | die `FB2-Schmalband-RX-Pfadauswahl` zeigt drei Vergleichswerte und den Sperrgrund |
| Abgrenzung | der Vergleich gibt keine produktive RX-Umschaltung frei |

Damit ist sichtbar, ob Audio-RX, `RDF`-Schatten und Loopback deckungsgleich sind, ob `RDF` noch nicht vergleichbar ist oder ob echte Byteabweichungen vorliegen.

Ab `v0.7.60` wird dieser Vergleich als eigenes kompaktes RX-Kettenereignis sichtbar.

| Feld | Verhalten |
| --- | --- |
| Status | `Hinweis RXS` bei offenen Vergleichen, `Sperre RXS` bei echten vergleichbaren Abweichungen |
| Laborereignis | eigene Kennung `SB-R-RXS` in der FB2-Laborübersicht |
| Abgrenzung | `SB-R-RXS` ist getrennt von `SB-R-RSH`, damit Kandidatenvergleich und Schattenannahme nicht vermischt werden |
| Prüfsumme | Ereignis-CRC enthält die Flags für Kandidatenvergleich, Abweichung und die Vergleichs-CRC |
| Oberfläche | Mesh- und TX-Planung behalten die Vergleichswerte; die Laborübersicht bekommt zusätzlich die verdichtete Ereigniszeile |
| Abgrenzung | auch `Sperre RXS` bleibt Diagnose und schaltet nicht produktiv auf den Audio-RX- oder `RDF`-Pfad um |

Damit sieht man in einer einzigen Laborzeile, ob der echte Audio-RX-/`RDF`-Pfad nur noch nicht vergleichbar ist oder ob er bereits messbar von der sicheren Loopback-Referenz abweicht.

Ab `v0.7.61` enthält das RX-Kettenereignis zusätzlich eine geführte Maßnahmenliste.

| Feld | Verhalten |
| --- | --- |
| Stufen | `RXS`, `RSH`, `RXL` und `RXP` |
| Status | `Sperre`, `Hinweis`, `Bereit` oder `OK` |
| Priorität | Sperren stehen vor Hinweisen, Hinweise vor Bereitschaft und OK-Zuständen |
| Prüfdaten | jede Maßnahme hat Meldung, nächste Aktion und eigene Prüfsumme |
| Ereignisbindung | die Maßnahmenprüfsummen gehen in die RX-Kettenereignis-CRC ein |
| Oberfläche | die FB2-Laboransicht zeigt die Maßnahmen direkt unter dem Laborstatus |
| Abgrenzung | die Liste ist Diagnoseführung und erteilt keine produktive FB2-RX- oder TX-Freigabe |

Damit wird aus der langen RX-Kette eine kurze Arbeitsliste: Erst sieht man die blockierende oder offene Stufe, dann die nächste sinnvolle Prüfung.

Ab `v0.7.62` erzeugt das RX-Kettenereignis aus dieser Arbeitsliste zusätzlich einen kompakten RX-Prüfbericht.

| Feld | Verhalten |
| --- | --- |
| Bericht-ID | `SB-R-RX` |
| Gesamtstatus | `Sperre`, `Hinweis`, `Bereit` oder `OK` |
| Hauptstufe | erste priorisierte Maßnahme, zum Beispiel `RXS` oder `RXP` |
| Zähler | Sperren, Hinweise, bereite Übergaben und OK-Stufen |
| Kurzbericht | eine kurze Zusammenfassung für Bedienung und spätere Feldtests |
| Nächste Aktion | direkt aus der wichtigsten Maßnahme übernommen |
| Prüfsumme | eigene Bericht-CRC, zusätzlich in der RX-Kettenereignis-CRC enthalten |
| Oberfläche | der Bericht erscheint kompakt im FB2-Laborbereich |
| Abgrenzung | der Bericht gibt keinen produktiven FB2-Pfad frei |

Damit ist der aktuelle Laborzustand nicht nur als Einzelliste sichtbar, sondern auch als zusammenfassbarer Prüfpunkt mit eigener CRC greifbar.

Ab `v0.7.63` kann dieser Prüfpunkt zusätzlich als Laborprotokoll gespeichert werden.

| Feld | Verhalten |
| --- | --- |
| Dateiformate | JSON für maschinelle Auswertung, HTML für menschliche Laborablage |
| Speicherort | `%APPDATA%\FunkBruecke\fb2-rx-pruefberichte` |
| Zuordnung | Protokoll-ID, Softwareversion, Station, Profil, Sequenz und Platzhalter für spätere Audioaufnahme |
| Inhalt | Ereignisstatus, Bericht, Maßnahmenliste, nächste Aktion und alle relevanten CRCs |
| Protokoll-CRC | eigene Prüfsumme über Bericht, Ereignis, Zuordnung und Maßnahmen |
| Oberfläche | Schaltfläche `RX-Prüfbericht speichern` im FB2-Laborbereich |
| Abgrenzung | weiterhin reine Diagnose ohne produktiven FB2-RX oder FB2-TX |

Ab `v0.7.64` wird diese lokale Ablage wieder auffindbar.

| Feld | Verhalten |
| --- | --- |
| Übersicht | die letzten gespeicherten Prüfberichte werden mit Zeit, Status, Profil, Sequenz, Audiozuordnung und CRC-Status geladen |
| Audio-Referenz | beim Speichern entsteht automatisch eine `SB-R`-Audio-/Eingangspuffer-Kennung |
| Pseudopfad | die Zuordnung nutzt `eingangspuffer://...` oder `metadaten://...`, bis echte Audiodateien gespeichert werden |
| Nachpflege | Audio-ID und Audio-Pfad können neu geschrieben werden; die Protokoll-CRC wird danach neu berechnet |
| Grenze | auch geladene und verknüpfte Berichte bleiben Laborprotokolle ohne produktive FB2-Freigabe |

Ab `v0.7.65` kann die Audio-Referenz bei vorhandenen Samplewerten auf eine echte WAV-Datei zeigen.

| Feld | Verhalten |
| --- | --- |
| Speicherort | `%APPDATA%\FunkBruecke\fb2-rx-aufnahmen` |
| Format | Mono-WAV, 16-bit PCM, Abtastrate aus der `SB-R`-Aufzeichnung |
| Dateiname | Audio-ID mit Zeit, Sequenznummer und Aufzeichnungs-CRC |
| Verknüpfung | der RX-Prüfbericht erhält direkt den WAV-Pfad |
| Rückfall | ohne Samplewerte bleibt die bisherige Metadaten-Referenz erhalten |
| Grenze | weiterhin Laboraufzeichnung ohne produktive RX-/TX-Freigabe |

Ab `v0.7.66` wird die verknüpfte WAV-Datei beim Laden der Prüfberichtübersicht wieder geprüft.

| Feld | Verhalten |
| --- | --- |
| WAV-Prüfung | RIFF/WAVE-Kennung, mono 16-bit PCM, Abtastrate und Datenchunk werden geprüft |
| Metadaten | Sampleanzahl, Dauer, Peak, RMS und Sample-CRC werden in der Oberfläche angezeigt |
| Referenzen | `metadaten://...` und `eingangspuffer://...` bleiben sichtbare Referenzen ohne WAV-Fehlerstatus |
| Wiederanalyse | gültige WAV-Dateien sind als spätere kontrollierte `SB-R`-Laborquelle markiert |
| Grenze | die Prüfung startet noch keine produktive RX-Umschaltung und keinen FB2-TX |

Ab `v0.7.67` kann diese Wiederanalyse manuell aus der Prüfbericht-Auswahl gestartet werden.

| Feld | Verhalten |
| --- | --- |
| Aktion | `WAV wiederanalysieren` lädt die ausgewählte geprüfte WAV-Datei |
| Laborquelle | aus den PCM-Samples entsteht eine neue `SB-R`-Testaufzeichnung |
| Referenz | die Auswertung läuft gegen den aktuellen `SB-R`-Laborreferenzplan |
| Diagnose | `RXT`, Sampleentscheidungen, Softbits, Demapper, Datenrücklauf und FEC-/Nutzdaten werden aktualisiert |
| Grenze | weiterhin keine produktive RX-Umschaltung und keine FB2-TX-Freigabe |

Ab `v0.7.68` wird die Wiederanalyse zusätzlich als eigenes Laborereignis beschrieben.

| Feld | Verhalten |
| --- | --- |
| Ereignisart | `WAV-RX` in der FB2-Laborereignisliste |
| Bindung | ursprüngliche Protokoll-ID, Audioaufnahme und Audio-Pfad |
| Prüfsummen | alte und aktuelle Bericht-CRC, Protokoll-CRC, Audio-Sample-CRC, Aufzeichnungs-CRC und RXT-CRC |
| Abweichungsstatus | `deckungsgleich`, `Bericht-CRC abweichend`, `Samplelänge abweichend`, `wartet` oder technische Sperrgründe |
| Grenze | weiterhin reine Laborprotokollierung ohne produktive RX-Umschaltung |

Ab `v0.7.69` ist der Laborereignisverlauf in der Oberfläche filterbar.

| Feld | Verhalten |
| --- | --- |
| Verlauf | intern werden die letzten Laborereignisse als eigener Verlauf gehalten |
| Filter | `Alle`, `WAV-RX`, `deckungsgleich`, `wartet`, `CRC abweichend`, `RXT ungültig` und Sperren/Hinweise |
| Ereigniszeile | Zeit, Aktion, Modus, Sequenz, Qualität, Status, Kurzmeldung und nächste Aktion |
| Detail | ausgewähltes Ereignis zeigt vollständige Meldung, Dauer und nächste Aktion |
| Grenze | Bedien- und Diagnosehilfe; keine produktive FB2-Freigabe |

Ab `v0.7.70` entsteht aus dem `WAV-RX`-Ereignis zusätzlich eine kompakte Wiederanalyse-Bilanz.

| Feld | Verhalten |
| --- | --- |
| Bilanzbindung | Protokoll-ID, Audio-ID, Gesamtstatus, nächste Aktion und Bilanz-CRC |
| Bericht | alte Bericht-CRC aus dem gespeicherten Prüfbericht gegen aktuelle Bericht-CRC der `SB-R`-Referenz |
| Audio | WAV-Sample-CRC aus der Datei-Prüfung und Aufzeichnungs-CRC der geladenen Testaufzeichnung |
| RXT | CRC der kontrollierten RX-Testauswertung samt Bewertung `auswertbar`, `wartet` oder `ungültig` |
| Samplelänge | erwartete Rahmen-Samples gegen geladene Samples mit Abweichung |
| Status | Abweichungsstatus und Freigabestatus, weiterhin ohne produktive Umschaltung |

Ab `v0.7.71` können mehrere solcher Bilanzen im Vergleichsverlauf priorisiert werden.

| Feld | Verhalten |
| --- | --- |
| Verlauf | bis zu zwölf zuletzt betrachtete `WAV-RX`-Bilanzen |
| Priorität | `P1 kritisch`, `P2 Abweichung`, `P3 beobachten`, `P4 OK` |
| Sortierung | technische Sperren vor Referenzabweichungen, Wartefällen und unauffälligen Bilanzen |
| Anzeige | Zeit, Protokoll, Audio-ID, Auffälligkeit, Status, Bilanz-CRC und nächste Aktion |
| Grenze | Vergleichsanzeige; weiterhin keine produktive FB2-RX-Umschaltung |

Ab `v0.7.72` wird dieser Vergleichsverlauf dauerhaft lokal nutzbar.

| Feld | Verhalten |
| --- | --- |
| Speicherung | JSON unter `%APPDATA%\FunkBruecke\fb2-rx-wav-vergleich\vergleichsverlauf.json` |
| Startverhalten | geprüfte Vergleichseinträge werden beim Programmstart wieder geladen |
| Export | CSV und HTML unter `%APPDATA%\FunkBruecke\fb2-rx-wav-vergleich\exporte` |
| Prüfung | veränderte oder ungültige Vergleichseinträge werden verworfen |
| Grenze | Laborprotokoll und Nachvollziehbarkeit; weiterhin keine produktive FB2-RX-Umschaltung |

Ab `v0.7.73` ist der gespeicherte Verlauf mit der Prüfbericht-Auswahl verbunden.

| Feld | Verhalten |
| --- | --- |
| Auswahlbezug | Protokoll-ID des ausgewählten Prüfberichts gegen Protokoll-ID im Vergleichseintrag |
| Auswahlstatus | zeigt Priorität, Auffälligkeit, Bilanz-CRC und Gesamtstatus zum ausgewählten Prüfbericht |
| Filter | `Alle`, `Auswahl`, `P1 kritisch`, `P2 Abweichung`, `P3 beobachten`, `P4 OK`, `RXT ungültig`, `CRC abweichend` |
| Kernlogik | Filter- und Protokollzuordnung liegen im FB2-Kern und sind automatisiert geprüft |
| Grenze | Such- und Bedienhilfe; weiterhin keine produktive FB2-RX-Umschaltung |

Ab `v0.7.74` entsteht aus Prüfberichtliste und Vergleichsverlauf eine kompakte Historie je Protokoll.

| Feld | Verhalten |
| --- | --- |
| Historienquelle | gespeicherte FB2-RX-Prüfberichte plus gültige `WAV-RX`-Vergleichseinträge |
| Offene Einträge | Prüfberichte ohne Wiederanalyse bleiben sichtbar und empfehlen eine `WAV-RX`-Wiederanalyse |
| Analysierte Einträge | zeigen Vergleichspriorität, Auffälligkeit, Bilanz-CRC, Status und nächste Aktion |
| Sortierung | neueste Prüfberichte zuerst, maximal zwölf sichtbare Historieneinträge |
| Grenze | Laborübersicht; weiterhin keine produktive FB2-RX-Umschaltung |

Ab `v0.7.75` wird diese Historie zusätzlich als RX-Entscheidungshilfe ausgewertet.

| Feld | Verhalten |
| --- | --- |
| Stufen | `Technische Sperre`, `Laborhinweis`, `Freigabekandidat`, `Offen` |
| Kriterium | abgeleitet aus Wiederanalysezustand, Priorität, Auffälligkeit und Vergleichsstatus |
| Anzeige | Stufe, Protokoll, Profil, Priorität, Kriterium, Bilanz-CRC und Empfehlung |
| Prüfung | Entscheidungseinträge und Gesamtauswertung sind mit CRCs gebunden |
| Grenze | Freigabekandidaten bleiben reine Laborhinweise; weiterhin keine produktive FB2-RX-Umschaltung |

Ab `v0.7.76` schreibt der vorhandene `WAV-RX`-Export zusätzlich Entscheidungsdateien.

| Feld | Verhalten |
| --- | --- |
| Vergleichsexport | bleibt als CSV und HTML erhalten |
| Entscheidungsexport | zusätzliche CSV- und HTML-Datei mit Stufe, Rang, Kriterium, Empfehlung, Freigabe-Flag und CRCs |
| Prüfung | nicht prüfbare Entscheidungen werden vor dem Schreiben abgewiesen |
| Anzeige | Exportstatus nennt Vergleichs- und Entscheidungsdateien sowie Entscheidung-CRC |
| Grenze | Labordokumentation; weiterhin keine produktive FB2-RX-Umschaltung |

Ab `v0.7.77` hängen Feldtestnotizen direkt an den RX-Entscheidungseinträgen.

| Feld | Verhalten |
| --- | --- |
| Ursache | kurze Einordnung, warum der Eintrag diese Stufe bekommen hat |
| Beobachtung | aktuelle Laborlage aus Vergleichsstatus oder offenem Zustand |
| Maßnahme | nächster sinnvoller Feld- oder Laborschritt |
| Ergebnis | kompakter Ergebniswert wie `gesperrt`, `prüfen`, `Kandidat` oder `offen` |
| Grenze | Feldtestdokumentation; weiterhin keine automatische Freigabe |

Ab `v0.7.78` bewertet die RX-Entscheidung zusätzlich die Stabilität jedes Eintrags.

| Feld | Verhalten |
| --- | --- |
| Prozentwert | 0 bis 100, als prüfsummengebundene Laborbewertung |
| Stufe | `gesperrt`, `offen`, `prüfen`, `vorläufig`, `brauchbar`, `stabil` oder `niedrig` |
| Freigabekandidat | Punkte aus P4-Priorität, deckungsgleichem Vergleich, unauffälliger Bilanz, CRC-Bindung, gültigem Prüfbericht und Alter |
| Gegenindikatoren | technische Sperren, Laborhinweise und offene Prüfberichte bleiben niedrig oder gesperrt bewertet |
| Grenze | Stabilität ist Dokumentation und Entscheidungshilfe; weiterhin keine produktive FB2-RX-Umschaltung |

Ab `v0.7.79` entsteht daraus zusätzlich ein Stabilitätsverlauf über die RX-Entscheidung.

| Feld | Verhalten |
| --- | --- |
| Kandidaten | Anzahl der Freigabekandidaten in der aktuellen Entscheidung |
| Stabile Kandidaten | Freigabekandidaten ab 90 Prozent Stabilität |
| Brauchbare Kandidaten | Freigabekandidaten ab 75 Prozent Stabilität |
| Profil | führendes Profil nach stabilen und brauchbaren Kandidaten |
| Trend | zum Beispiel `einzeln stabil`, `mehrfach stabil`, `prüfen`, `offen` oder `gesperrt` |
| Empfehlung | nächster Labor- oder Feldserienschritt ohne produktive Freigabe |
| Prüfung | Verlauf-CRC und Entscheidung-CRC binden den Verlauf an die Einzelentscheidungen |
| Grenze | Verlauf ist Feldtest- und Laborhilfe; weiterhin keine produktive FB2-RX-Umschaltung |

Ab `v0.7.80` wird für jeden RX-Entscheidungseintrag eine Feldserienkennung abgeleitet.

| Feld | Verhalten |
| --- | --- |
| Kennung | Kombination aus Profil, Protokoll-ID-Stamm und Audioaufnahme-ID-Stamm |
| Normalisierung | variable Zeit-, Sequenz- und CRC-Teile werden ausgeblendet |
| Verlauf | zählt Feldserien und mehrfach stabile Feldserien und nennt die führende Feldserie |
| Trend | unterscheidet stabile Feldserie von mehreren stabilen Einzelserien |
| Prüfung | Feldserienkennung und Feldserien-Zähler sind Teil der Prüfsummen |
| Grenze | vorläufige lokale Ableitung; später sollen echte Feldmetadaten bevorzugt werden |

Ab `v0.7.81` bekommen gespeicherte `SB-R`-RX-Prüfberichte echte Feldmetadaten.

| Feld | Verhalten |
| --- | --- |
| Gegenstation | Rufzeichen der getesteten Gegenstation oder Leitstation |
| Testort | kurzer Ort, Aufbau oder Laborplatz |
| Frequenz | aktuelle oder manuell eingetragene Testfrequenz |
| Betriebsart | aktuelle oder manuell eingetragene Betriebsart |
| Feldserie | manuelle Kennung für zusammengehörige Feldtests |
| Prüfung | eigene Metadaten-CRC plus Einbindung in die Protokoll-CRC |
| Kompatibilität | ältere Prüfberichte ohne Feldmetadaten bleiben lesbar und prüfbar |
| Grenze | weiterhin Labor- und Feldtestdokumentation ohne produktive FB2-Freigabe |

Ab `v0.7.82` wird diese echte Feldserienkennung in Historie und RX-Entscheidung bevorzugt.

| Feld | Verhalten |
| --- | --- |
| Quelle | gespeicherte Feldserienkennung aus dem RX-Prüfbericht |
| Vorrang | echte Kennung wird vor der abgeleiteten Kennung verwendet |
| Rückfall | ältere Berichte ohne echte Kennung nutzen weiter Profil-/Protokoll-/Audio-Ableitung |
| Verlauf | stabile und brauchbare Kandidaten werden nach echter Feldserie gruppiert |
| Oberfläche | Prüfbericht-Historie nennt die Feldserie und zählt Berichte mit echter Feldserie |
| Grenze | weiterhin Entscheidungshilfe ohne produktive RX-Umschaltung |

Ab `v0.7.83` ergänzt die RX-Entscheidung eine Feldserien-Bilanz.

| Feld | Verhalten |
| --- | --- |
| Gesamt | alle Prüfstände der Feldserie |
| Stabil | Freigabekandidaten ab 90 Prozent Stabilität |
| Brauchbar | Freigabekandidaten ab 75 Prozent Stabilität |
| Kritisch | P1- oder kritisch markierte Prüfstände |
| Offen | Prüfstände ohne WAV-Wiederanalyse |
| Gesperrt | technische Sperren oder gesperrte Stabilitätsstufen |
| Stabilität | höchste und durchschnittliche Stabilität der Serie |
| Status | zum Beispiel `stabil`, `brauchbar`, `kritisch`, `offen` oder `gesperrt` |
| Prüfung | jede Bilanz besitzt eine eigene Bilanz-CRC und ist Teil der Entscheidung-CRC |
| Grenze | weiterhin Feldtest- und Laborhilfe ohne produktive FB2-Freigabe |

Ab `v0.7.84` werden die echten Feldmetadaten in dieser Auswertung durchgereicht.

| Feld | Verhalten |
| --- | --- |
| Historie | zeigt Feldserie plus Gegenstation, Testort, Frequenz und Betriebsart |
| Entscheidung | jeder Eintrag enthält die konkreten Felddaten aus dem Prüfbericht |
| Bilanz | sammelt je Feldserie die vorkommenden Gegenstationen, Testorte, Frequenzen und Betriebsarten |
| Export | CSV und HTML enthalten diese Angaben in Entscheidung und Feldserien-Bilanz |
| Prüfung | Entscheidungseintrag-CRC und Bilanz-CRC binden die Felddaten ein |
| Grenze | weiterhin Labor- und Feldtestentscheidung ohne produktive FB2-Freigabe |

Ab `v0.7.85` prüft die Feldserien-Bilanz zusätzlich, ob diese Felddaten innerhalb einer Serie einheitlich bleiben.

| Feld | Verhalten |
| --- | --- |
| Zähler | getrennte Anzahl für Gegenstationen, Testorte, Frequenzen und Betriebsarten |
| Status | `einheitlich` oder `gemischt` |
| Warnung | nennt die gemischten Felder, bevor eine Serie fachlich bewertet wird |
| Oberfläche | Filter für gemischte Felddaten, einzelne Mischfelder, echte und abgeleitete Serien |
| Export | CSV und HTML enthalten Status, Warnung und Feldanzahlen |
| Prüfung | Status und Warnung sind Teil der Bilanz-CRC |

Ab `v0.7.86` hängt an dieser Warnung eine Ursachenanzeige.

| Feld | Verhalten |
| --- | --- |
| Prüfberichte | nennt die betroffenen Protokoll-IDs der Feldserie |
| Entscheidungen | nennt je Protokoll Entscheidungstufe und Priorität |
| Ursachen | listet bei gemischten Felddaten die abweichenden Werte je Protokoll |
| Oberfläche | zeigt diese drei Zeilen direkt unter der Bilanzwarnung |
| Export | CSV und HTML enthalten Prüfberichte, Entscheidungen und Ursachen |
| Prüfung | alle drei Angaben sind Teil der Bilanz-CRC |

Ab `v0.7.87` wird diese Ursachenanzeige in der Oberfläche bedienbar.

| Feld | Verhalten |
| --- | --- |
| Auswahl | eine sichtbare Feldserien-Bilanz kann direkt gewählt werden |
| Aktion | `Ursache öffnen` nimmt den ersten betroffenen Prüfbericht der Serie |
| Historie | die passende Prüfbericht-Historienzeile wird mit `Auswahl:` markiert |
| Entscheidung | der zugehörige RX-Entscheidungseintrag wird ebenfalls markiert |
| Vergleich | der WAV-Vergleich schaltet auf den Auswahlfilter |
| Grenze | weiterhin Labor- und Feldtesthilfe ohne produktive FB2-Freigabe |

Ab `v0.7.99` ist diese Bedienhilfe als größerer Block abgerundet.

| Feld | Verhalten |
| --- | --- |
| Volltext | zur ausgewählten Bilanz wird ein ungekürzter Ursachenbericht angezeigt |
| Export | der Bericht kann als lokale Textdatei unter `%APPDATA%\FunkBruecke\fb2-rx-feldserien-ursachen` gespeichert werden |
| Robustheit | der Sprung nutzt die vollständige erste betroffene Protokoll-ID, auch wenn die Tabellenzeile gekürzt ist |
| UKW | 4 m wird als vorsichtiges Profil und Frequenzvorlage ergänzt; Bandplanhinweise nennen lokale Daten-/Simplexbereiche |
| Audio | die RX-Kalibrierung bewertet zusätzlich die Pegelreserve bis zum Clipping |
| Kanal | aktives Horchfenster ohne laufenden Audioeingang blockiert TX, weil kein FB1-Rahmen geprüft werden kann |

## FB2L-Link-Bake

Direkte Mesh-Nachbarn tauschen künftig kleine `FB2L`-Link-Baken aus. Diese Kurzpakete enthalten nicht die komplette Routingtabelle, sondern nur die wichtigsten Link- und Modusdaten.

Textmarker:

```text
FB2L|<Base64Url-Binärblock>|<CRC16-CCITT-HEX>
```

Der innere Nutzdatenblock ist binär und enthält:

- Version,
- Sequenznummer,
- Erzeugungszeit,
- Gültigkeitsdauer,
- eigenes Rufzeichen,
- Profil-Maximalmodus,
- stabilen Maximalmodus,
- aktuellen Modus,
- Rückfallmodus,
- Fehlerquote,
- ACK-Zeit,
- maximal zwei beste Nachbarn mit Rufzeichen, Maximalmodus, stabilem Modus, Zuverlässigkeit, ACK-Zeit und Alter.

Die Zwei-Nachbarn-Grenze ist bewusst gesetzt, damit Link-Baken sparsam bleiben. Vollständige Mesh-Information entsteht über mehrere Baken und empfangene Nutzpakete hinweg.

Ab `v0.7.6` kann FunkBrücke `FB2L`-Rahmen aus einem demodulierten Textpuffer herausfinden. Damit darf vor oder nach der Link-Bake Rauschen, Textrest oder späterer Synchronisationsinhalt stehen, solange ein vollständiger `FB2L|...|CRC`-Rahmen im Text enthalten ist.

Ab `v0.9.84` erzeugt FunkBrücke aus einer empfangenen `FB2L`-Bake zusätzlich eine Mesh-Anbindungsbilanz. Sie übernimmt den direkt gehörten Bakensender als bidirektionalen Mesh-Link, übernimmt bis zu zwei gemeldete Nachbarlinks, zählt neue und erneuerte Links und zeigt, ob dadurch eine Route zum Ziel entsteht oder bestätigt wird. Die Oberfläche nennt Quelle, Qualität, Latenz, Verlust, Vertrauen, Alter und den gemeldeten Modus je Link.

## Allgemeiner FB2-Rahmen

Für spätere Nutzdaten, Steuerpakete und Linkinformationen gibt es ab `v0.7.6` einen technischen FB2-Rahmen:

```text
FB2|<Base64Url-Kopf>|<Base64Url-Nutzdaten>
```

Der Kopf ist binär und enthält:

- Kennung `FB2`,
- Rahmenversion,
- Rahmenart,
- verwendeten FB2-Modus,
- Sequenznummer,
- Nutzdatenlänge,
- CRC-16/CCITT der Nutzdaten,
- Absender,
- Empfänger,
- CRC-16/CCITT des Kopfes.

Die Rahmenart unterscheidet aktuell Link-Bake, Paket und Steuerung. Der Rahmen ist bewusst unabhängig von FB1 definiert, damit später alle Paketarten über 4-FSK, 8-FSK, MFSK oder OFDM übertragen werden können. In `v0.7.6` ist dieser Rahmen noch eine technische Vorstufe: FunkBrücke kann ihn kodieren, dekodieren und im RX-Pfad erkennen, nutzt ihn aber noch nicht als produktiven Sendepfad.

## FB2-Laborpfad

Ab `v0.7.7` gibt es einen kontrollierten Laborpfad für 4-FSK und 8-FSK. Dieser Pfad:

- erzeugt einen technischen `FB2`-Paketrahmen,
- moduliert den Rahmen intern mit dem Mehr-FSK-Experiment,
- demoduliert dieselben Samples zurück in Text,
- sucht den `FB2`-Rahmen im Textpuffer,
- prüft Kopf, Nutzdaten-CRC und Nutztext,
- übergibt den gültigen Rahmen an die bestehende FB2-RX-Verarbeitung.

Der Laborpfad ist absichtlich kein produktiver Funk-Sendepfad. Er nutzt keine PTT, keine reale Audioausgabe und ersetzt FB1 noch nicht. Er macht aber erstmals sichtbar, dass der neue FB2-Rahmen zusammen mit 4-FSK und 8-FSK als vollständiger interner Rundlauf funktioniert.

Ab `v0.7.8` kann derselbe Laborrahmen bewusst als Testaudio über den gewählten Audioausgang ausgegeben werden. Diese Ausgabe:

- benötigt eine eigene sichtbare Freigabe,
- prüft vorher den Kanal über die bestehende FB1-Kanalprüfung samt Horchfenster,
- nutzt weiterhin keine PTT,
- nimmt die Freigabe nach jedem Versuch automatisch zurück,
- protokolliert Modus, Sequenz, Samples und Dauer im Audio- und Paketmonitor.

Damit ist 4-FSK/8-FSK erstmals als reale Audioausgabe testbar, ohne den produktiven FB1-Sendemotor zu ersetzen. Bei anliegender VOX oder extern geschalteter PTT muss der Stationsaufbau trotzdem wie bei jedem Audiosignal bewusst kontrolliert werden.

Ab `v0.7.9` gibt es zusätzlich einen manuellen FB2-Audio-RX für 4-FSK und 8-FSK. Dieser RX-Pfad:

- nutzt den bestehenden Live-RX-Puffer des Audioeingangs,
- sucht im Samplepuffer nach dem wahrscheinlichen Signalbeginn,
- toleriert kurze Vorläufe vor dem eigentlichen Mehr-FSK-Signal,
- demoduliert den Puffer als 4-FSK oder 8-FSK,
- erkennt `FB2L`-Link-Baken und generische `FB2`-Rahmen,
- übergibt gültige Rahmen an die vorhandene FB2-RX-Verarbeitung.

Der FB2-Audio-RX ist in dieser Version noch eine manuelle Laboraktion. Er ersetzt den FB1-Live-RX nicht und entscheidet noch nicht automatisch, ob ein eingehendes Signal FB1, 4-FSK oder 8-FSK ist.

Ab `v0.7.10` fasst der Mesh-Tab Loopback, Testaudio und Audio-RX in einer gemeinsamen FB2-Laborübersicht zusammen. Diese Übersicht zeigt letzte Aktion, Modus, Sequenz, Qualität, Dauer, nächste Aktion und eine kurze Ereignisliste. Damit wird der Laborpfad bedienbarer: interne Rundläufe, bewusst freigegebene Audioausgaben, Kanalblockaden, RX-Fehler und erfolgreiche RX-Übernahmen landen an derselben Stelle. Auch diese Stufe bleibt ein Laborpfad ohne produktiven FB2-Sendebetrieb.

Ab `v0.7.11` merkt sich FunkBrücke den zuletzt tatsächlich ausgegebenen FB2-Testaudio-Rahmen als erwartetes RX-Ziel. Der Mesh-Tab zeigt Zielmodus, Zielsequenz, Nutzdatenkurztext und einen Vergleichsstatus. Wenn der manuelle FB2-Audio-RX danach einen Rahmen findet, werden Modus, Sequenz, Absender, Empfänger und Rahmeninhalt gegen die Erwartung geprüft. Link-Baken zählen dabei bewusst nicht als passender Pakettreffer.

Ab `v0.7.12` gibt es zusätzlich die gemeinsame Aktion `FB2 RX suchen`. Sie wertet denselben Audioeingangspuffer nacheinander als 4-FSK und 8-FSK aus, sammelt die Einzelergebnisse und übernimmt das beste gültige Ergebnis. Wenn ein erwarteter Testaudio-Rahmen vorhanden ist, wird ein dazu passender Treffer bevorzugt. Die Oberfläche zeigt die Suchversuche mit Modus, Trefferstatus und Qualität.

Ab `v0.7.15` unterstützt der Laborpfad zusätzlich 16-MFSK. Loopback, bewusst freigegebenes Testaudio, manueller Audio-RX und automatische RX-Suche können diesen Modus verwenden, wenn das aktuelle FB2-Betriebsprofil ihn erlaubt. `SSB schmal` blockiert 16-MFSK im Labor; `FM normal` und `FM breit/Labor` geben ihn frei. Die automatische Suche verwendet dadurch bei SSB nur die schmalen Labormodi und auf FM zusätzlich 16-MFSK.

Ab `v0.7.16` wird der manuelle Laborpfad über eine zentrale Modusauswahl bedient. Die Auswahl zeigt 4-FSK, 8-FSK und 16-MFSK mit erlaubtem oder gesperrtem Profilstatus. Loopback, Testaudio und manueller Audio-RX verwenden denselben gewählten Modus; gesperrte Modi bleiben sichtbar, werden aber bei Ausführung blockiert. Die automatische RX-Suche bleibt unabhängig davon profilgeführt und prüft alle erlaubten Labormodi.

Ab `v0.7.17` ergänzt 32-MFSK die breite Laborstufe. Der Modus ist in der zentralen Auswahl sichtbar, wird aber nur im Profil `FM breit/Labor` freigegeben. `SSB schmal` und `FM normal` sperren 32-MFSK für Loopback, Testaudio und manuellen Audio-RX; die automatische RX-Suche bezieht 32-MFSK ebenfalls nur im Laborprofil ein.

## Mesh-Auswahl

FB2 plant pro Ziel:

- Primär-Hop,
- Ersatz-Hop,
- Sendemodus zum Primär-Hop,
- Sendemodus zum Ersatz-Hop,
- Zuverlässigkeit und ACK-Zeit.

Es wird nicht parallel doppelt gesendet. Auch wichtiger oder dringender Verkehr nutzt zuerst den besten Pfad. Bei Timeout, Fehler oder schlechter Linkbewertung wird auf den Ersatz-Hop oder auf einen robusteren Modus gewechselt.

Die Moduswahl berücksichtigt:

- maximal unterstützten Modus,
- stabilen Maximalmodus,
- Zuverlässigkeit,
- Paketverlust,
- Alter der Messung,
- ACK-Zeit.

Unbekannte Nachbarn starten mit `2-FSK robust`.

## Abgrenzung Zu FB1

`FB1` bleibt aktuell der produktive Rahmen für Chat, ACK/NACK, Datei, Formular, Status und Mesh-Weiterleitung. `FB2` ist ab `v0.7.4` als Core-Grundlage vorhanden, aber noch nicht als vollständiger Audio-/OFDM-Sendepfad aktiv.

Ab `v0.7.5` ist FB2 in der Oberfläche sichtbar:

- Der Mesh-Tab zeigt eine `FB2L`-Link-Bake-Vorschau mit geschätzter Dauer.
- Primär-Hop und Ersatz-Hop werden mit geplantem Modus angezeigt.
- Die zwei besten Link-Bake-Nachbarn sind mit Maximalmodus, stabilem Modus, Zuverlässigkeit, ACK-Zeit und Alter sichtbar.
- Der TX-Tab zeigt pro sendefähigem Auftrag eine FB2-Airtime-Schätzung und die Modusleiter für den ersten Rahmen.

Ab `v0.7.6` erkennt die Oberfläche `FB2L`-Link-Baken und generische `FB2`-Rahmen im manuellen RX-Feld sowie in demodulierten Textpuffern. Zusätzlich gibt es ein erstes 4-FSK-/8-FSK-Modemexperiment mit Rundlauftests. Ab `v0.7.7` verbindet der FB2-Laborpfad Rahmenkopf, Mehr-FSK-Modem und RX-Verarbeitung. Ab `v0.7.8` kann der FB2-Laborrahmen mit eigener Freigabe und Kanalprüfung als Testaudio ausgegeben werden. Ab `v0.7.9` kann der Audioeingangspuffer manuell als 4-FSK/8-FSK ausgewertet werden. Ab `v0.7.10` führt die Oberfläche Loopback, Testaudio und Audio-RX in einer gemeinsamen Laborbedienung zusammen. Ab `v0.7.11` wird der zuletzt ausgespielte Testaudio-Rahmen als erwartetes RX-Ziel mit dem manuellen Audio-RX verglichen. Ab `v0.7.12` sucht die Laborbedienung automatisch in 4-FSK und 8-FSK und wählt das beste gültige Ergebnis. Ab `v0.7.13` begrenzt ein Core-Modell die geplanten Modi nach `SSB schmal`, `FM normal` und `FM breit/Labor`. Ab `v0.7.14` ist dieses Profil sichtbar auswählbar und im Stationsprofil persistent. Ab `v0.7.15` erweitert 16-MFSK den profilbewussten Laborpfad. Ab `v0.7.16` bündelt eine zentrale Labormodus-Auswahl die manuellen FB2-Laboraktionen. Ab `v0.7.17` ist 32-MFSK als breite Laborstufe nur für `FM breit/Labor` aktiv. Ab `v0.7.18` beschreibt ein testbarer Schmalbandkatalog schnelle und robuste SSB-Kandidaten bis 2,4 kHz. Ab `v0.7.19` sind daraus robuste, normale und schnelle Schmalbandempfehlungen in Mesh- und TX-Planung sichtbar. Ab `v0.7.20` konkretisiert `SB-R` das robuste SSB-Profil mit Rahmenplan und Airtime-Overhead. Ab `v0.7.21` zerlegt der interne `SB-R`-Blockcodec Nutzdaten in prüfbare ARQ-Blöcke und erzeugt FEC-Eingangsdaten. Ab `v0.7.22` erzeugt eine Labor-FEC daraus codierte und verschachtelte Bytes. Ab `v0.7.23` plant der Core daraus DBPSK-/QPSK-Symbolgruppen. Ab `v0.7.24` werden daraus differenzielle Phasenwechsel und I/Q-Konstellationspunkte geplant. Ab `v0.7.25` plant der Core daraus Sample-Zeitachsen, Pulsformungsmetadaten und Basisbandprüfsummen. Ab `v0.7.26` entstehen daraus interne I/Q-Samples mit Peak/RMS und Prüfsummen. Ab `v0.7.27` gewinnt ein interner Loopback aus diesen Samples Symbolwerte und Zielphasen zurück. Ab `v0.7.28` bildet der Core diese Loopback-Symbole wieder zu Interleaver- und FEC-nahen Bytes zurück. Ab `v0.7.29` rekonstruiert der Core daraus wieder prüfbare Blockköpfe und Nutzdaten. Ab `v0.7.30` bündelt der Core den gesamten internen Rundlauf und stellt die Nutzlast als vorbereitete RX-Übergabe bereit, weiterhin ohne Audioausgabe.

Ab `v0.7.31` prüft eine interne FB2-RX-Laborannahme diese Nutzlast als Laborpayload oder gültigen FB2-Rahmen und sperrt defekte FB2-Kandidaten.

Ab `v0.7.32` stellt der Core daraus geprüfte FB2-RX-Verarbeitungskandidaten bereit; die App übernimmt neue bereitstehende Labor-FB2-Rahmen kontrolliert in die bestehende FB2-RX-Verarbeitung.

Ab `v0.7.33` verdichtet ein RX-Kettenereignis die Zustände von `RX`, `RXL` und `RXP` und schreibt deduplizierte `SB-R-RX`-Ereignisse in die FB2-Laborübersicht.

Ab `v0.7.34` bereitet eine interne Audio-RX-Vorstufe für `SB-R` die späteren Eingangspuffer-Snapshots vor. Präambel-, Synchronwort-, Pilot- und Datenfenster werden samplescharf geplant, mit CRC geprüft und als neue Rundlaufstufe `ARX` in Mesh- und TX-Planung angezeigt. Auch diese Stufe bleibt ohne produktive Demodulation.

Ab `v0.7.35` ergänzt der Core eine interne Synchronwort-Erkennung auf diesem Snapshot. Die neue Rundlaufstufe `ARS` meldet Suchfenster, Timing-Abweichung, grobe Qualität und Treffer-CRC und wird in Mesh- und TX-Planung sichtbar. Eine produktive Nutzdaten-Demodulation ist weiterhin nicht aktiv.

Ab `v0.7.36` ergänzt der Core eine interne Pilot-/Trainingfenster-Auswertung. Die neue Rundlaufstufe `ART` meldet Pilotfenster, Frequenzabweichung, Restabweichung, Korrekturwerte, Qualität und CRC. Die Zielwerte sind ±100 Hz Suchbereich und höchstens 20 Hz Restabweichung, weiterhin ohne produktive Nutzdaten-Demodulation.

Ab `v0.7.37` ergänzt der Core eine interne Symbolfenster-Planung nach Sync und Training. Die neue Rundlaufstufe `ARF` meldet Datenfenster, Symbolanzahl, Startkorrektur, Restabweichung und CRC. Auch diese Stufe bleibt Laborlogik und startet noch keine produktive Nutzdaten-Demodulation.

Ab `v0.7.38` ergänzt der Core eine interne Symbolabtast-/Softentscheidungsplanung. Die neue Rundlaufstufe `ARA` meldet Abtastpunkte, Softbits, Qualität und CRC. Auch diese Stufe bleibt Laborlogik und startet noch keinen produktiven Demapper.

Ab `v0.7.39` ergänzt der Core eine interne Audio-RX-Demapper-/Softbit-Gruppierung. Die neue Rundlaufstufe `ADM` meldet Gruppen, Softbits, Zuverlässigkeit und CRC. Auch diese Stufe bleibt Laborlogik ohne echte Sampleentscheidung und startet noch keinen produktiven Demapper-Rücklauf.

Ab `v0.7.40` ergänzt der Core einen internen Audio-RX-Datenrücklauf. Die neue Rundlaufstufe `ARD` meldet Interleaverbytes, FEC-Eingangsbytes, Softbitfehler und CRC. Auch diese Stufe bleibt Laborlogik ohne echte Sampleentscheidung und startet noch keine produktive Nutzdaten-Demodulation.

Ab `v0.7.41` ergänzt der Core einen internen Audio-RX-Nutzdatenrücklauf. Die neue Rundlaufstufe `ARN` meldet gültige Blöcke, Nutzdatenbytes, Bytefehler und CRC. Auch diese Stufe bleibt Laborlogik ohne echte Sampleentscheidung und startet noch keine produktive Nutzdaten-Demodulation.

Ab `v0.7.42` ergänzt der Core eine interne RX-Pfadauswahl. Die neue Rundlaufstufe `RXS` meldet aktiven Pfad, Audio-RX-Kandidat, Loopback-Kandidat, Nutzdatenbytes und CRC. Der Loopback-Laborpfad bleibt aktiv; der Audio-RX-Kandidat ist prüfbar, aber noch nicht für produktive Übergabe freigegeben.

Ab `v0.7.43` ergänzt der Core eine interne RX-Schattenannahme. Die neue Rundlaufstufe `RSH` meldet Audio-RX-Rahmenstatus, Nutzdatenvergleich, Annahmevergleich und Schatten-CRC. Die aktive RX-Übergabe bleibt weiterhin beim Loopback-Laborpfad.

Ab `v0.7.44` meldet das RX-Kettenereignis Schattenabweichungen als `Sperre RSH`. Solche Sperren werden in der FB2-Laborübersicht als `SB-R-RSH` sichtbar und verhindern die kontrollierte Laborübernahme in die bestehende FB2-RX-Verarbeitung.

Ab `v0.7.45` ist zusätzlich die vorbereitete Eingangspufferquelle in der RX-Schattenannahme sichtbar. Sie liefert Sampleanzahl, Dauer, Aktivstatus, Bereitstatus und Quellen-CRC, bleibt aber noch eine beobachtete Quelle ohne produktive Sampleentscheidung.

Ab `v0.7.51` ist daraus eine zusammengefasste Audio-RX-Schattenkette geworden. Sync, Training, Symbolfenster, Demapper, FEC-Rücklauf und Nutzdatenrücklauf werden als Stufen mit Fortschritt, fehlenden Samples, nächster Aktion und Ketten-CRC sichtbar. Der produktive FB1-Pfad bleibt unverändert.

Ab `v0.7.52` prüft eine kontrollierte Audio-RX-Testauswertung echte bzw. aufgezeichnete Samples gegen diese Schattenkette. Die neue Stufe `RXT` meldet Sampleanzahl, Pegelwerte, Längenabweichung, Signatur-CRC und Freigabestatus. Auch eine auswertbare Testaufnahme schaltet nicht produktiv auf `SB-R` um.

Ab `v0.7.53` tastet die neue Stufe `RSE` die geplanten Symbolmitten der Testaufnahme ab, entscheidet Symbolwerte und meldet Treffer, Abweichungen, Pegel sowie Entscheidungs-CRC. Die Ergebnisse bleiben Labor- und Diagnosewerte ohne produktive RX-Freigabe.

Ab `v0.7.54` leitet die neue Stufe `RSB` daraus erwartete und entschiedene Softbits ab. Sie meldet Softbit-Treffer, Abweichungen, Zuverlässigkeit und CRC. Auch diese Diagnose bleibt ohne produktive RX-Freigabe.

Ab `v0.7.55` bündelt die neue Stufe `RSD` diese Softbits zu Demappergruppen. Sie meldet Gruppenanzahl, auswertbare Gruppen, Softbit-Treffer, Abweichungen und CRC. Auch diese Diagnose bleibt ohne produktive RX-Freigabe.

Ab `v0.7.56` packt die neue Stufe `RDD` die RSD-Bits zu Byte-Kandidaten. Sie meldet Blockanzahl, auswertbare Blöcke, Byte-Treffer, Byte- und Bitabweichungen sowie CRC. Auch diese Diagnose bleibt ohne produktive RX-Freigabe.

Ab `v0.7.57` entschachtelt die neue Stufe `RDF` diese Byte-Kandidaten zu FEC-Eingangs- und Paritätsbytes und prüft Blockkopf sowie Nutzdaten gegen die Laborreferenz. Sie meldet gültige FEC-Blöcke, gültige Nutzdatenblöcke, FEC-/Nutzdatenabweichungen und CRC. Auch diese Diagnose bleibt ohne produktive RX-Freigabe.

Ab `v0.7.58` führt `RXS` die aus `RDF` rückgewonnenen Nutzdaten zusätzlich als gesperrten Audio-RX-Schattenkandidaten. Die Auswahlprüfsumme berücksichtigt diesen Kandidaten, aber der aktive Pfad bleibt weiterhin `LBK`.

Ab `v0.7.59` meldet `RXS` zusätzlich die Kandidatenvergleichsdiagnose. Sie zählt `ARX/LBK`, `RDF/LBK` und `ARX/RDF`, hält Sperrgründe fest und bleibt ohne produktive RX-Freigabe.

Ab `v0.7.60` gibt die RX-Kette daraus ein eigenes Laborereignis aus. `Hinweis RXS` kennzeichnet noch offene Vergleiche, `Sperre RXS` kennzeichnet echte vergleichbare Abweichungen, und die FB2-Laborübersicht führt beides unter `SB-R-RXS`.

Ab `v0.7.61` fasst die RX-Kette `RXS`, `RSH`, `RXL` und `RXP` zusätzlich als geführte Maßnahmenliste zusammen. Sperren, Hinweise, übergabebereite Kandidaten und OK-Zustände sind priorisiert und prüfsummengesichert.

Ab `v0.7.62` erzeugt die RX-Kette daraus einen kompakten Prüfbericht mit Gesamtstatus, Hauptstufe, Zählerständen, nächster Aktion und eigener CRC. Dieser Bericht ist für Bedienung und spätere Feldtestdokumentation vorbereitet und war in `v0.7.62` zunächst noch ohne Datei-Export.

Ab `v0.7.63` ist dieser Prüfbericht als JSON- und HTML-Laborprotokoll speicherbar. Das Protokoll enthält Zuordnung, Ereignisstatus, Berichtsdaten, Maßnahmen, Audioaufnahme-Platzhalter und eigene Protokoll-CRC; es bleibt weiterhin ohne produktive FB2-Freigabe.

Ab `v0.7.64` lädt die Oberfläche gespeicherte Prüfberichte wieder als Übersicht und verknüpft neue Protokolle automatisch mit der aktuellen `SB-R`-Audio-/Eingangspuffer-Referenz. Die Verknüpfung ist noch keine WAV-Ablage, aber eine prüfsummengesicherte Brücke vom Laborbericht zur späteren Audioaufnahme.

Ab `v0.7.65` speichert FunkBrücke diese Brücke als echte WAV-Datei, sobald die kontrollierte Aufzeichnung Samplewerte enthält. Der Prüfbericht verweist dann auf die Audiodatei; fehlen Samplewerte, bleibt die Metadaten-Referenz erhalten.

Ab `v0.7.66` prüft die Oberfläche beim Wiederladen der Übersicht die verknüpfte WAV-Datei und zeigt die wichtigsten Audiodaten samt Sample-CRC. Damit ist die spätere erneute kontrollierte `SB-R`-Auswertung aus gespeicherten Aufnahmen vorbereitet.

Ab `v0.7.67` kann diese vorbereitete Aufnahme tatsächlich erneut durch die kontrollierte `SB-R`-RX-Testdiagnose geführt werden. Die App lädt die WAV-Samples als Laborquelle und aktualisiert die Diagnoseketten, bleibt aber ausdrücklich ohne produktive RX-Umschaltung.

Ab `v0.7.68` erzeugt diese Wiederanalyse ein eigenes Ereignis mit Protokoll-ID, Bericht-/Audio-CRCs und Abweichungsstatus. Damit lässt sich später besser nachvollziehen, ob eine alte Aufnahme noch zum aktuellen `SB-R`-Referenzplan passt.

Ab `v0.7.69` kann dieser Laborereignisverlauf nach wichtigen Statuslagen gefiltert werden. Die Detailanzeige macht pro Ereignis sichtbar, welche Meldung protokolliert wurde und welche nächste Aktion empfohlen ist.

Ab `v0.7.70` ergänzt die Oberfläche direkt unter der Wiederanalyse-Meldung eine kompakte Bilanz. Sie zeigt die wichtigsten Prüfpunkte nebeneinander und hält die Bilanz selbst mit einer CRC fest.

Ab `v0.7.71` wird daraus ein kleiner priorisierter Vergleichsverlauf. Wiederholte Analysen desselben Prüfberichts ersetzen den älteren Eintrag, und auffällige Bilanzen stehen automatisch oben.

Ab `v0.7.72` bleibt dieser Vergleichsverlauf nach Neustart erhalten und kann als CSV-/HTML-Laborprotokoll exportiert werden. Der Export ist für Auswertung und Dokumentation gedacht, nicht als Sendefreigabe.

Ab `v0.7.73` zeigt die Prüfbericht-Auswahl den passenden Vergleichsstatus direkt an. Der sichtbare Verlauf kann auf die Auswahl oder auf Prioritäten und Auffälligkeiten eingeschränkt werden.

Ab `v0.7.74` ergänzt die Oberfläche eine Historie, die offene und bereits wiederanalysierte Prüfberichte nebeneinander sichtbar macht. Das bereitet spätere RX-Entscheidungskriterien vor, löst aber noch keine Freigabe aus.

Ab `v0.7.75` entsteht daraus eine eigene RX-Entscheidungsliste. Technische Sperren stehen oben, Laborhinweise folgen, danach kommen Freigabekandidaten und offene Prüfberichte. Die Liste ist als Vorbereitung für spätere echte RX-Entscheidungskriterien gedacht und bleibt ausdrücklich ohne produktive Umschaltung.

Ab `v0.7.76` wird diese Entscheidungsliste beim `WAV-Vergleich exportieren` als eigene CSV- und HTML-Datei mitgeschrieben. Dadurch lassen sich Vergleichsverlauf und Entscheidungslage gemeinsam archivieren, ohne dass daraus eine Sendefreigabe entsteht.

Ab `v0.7.77` enthält jede Entscheidung zusätzlich eine Feldtestnotiz. In der Oberfläche steht sie direkt unter der Empfehlung; im Entscheidungsexport wird sie als Ursache, Beobachtung, Maßnahme und Ergebnis ausgegeben.

Ab `v0.7.78` enthält jede Entscheidung zusätzlich eine Stabilitätszeile. Die Oberfläche zeigt Prozentwert, Stufe und Begründung; der CSV-/HTML-Entscheidungsexport schreibt dieselben Werte mit. Die Eintrag-CRC bindet diese Stabilität ein, damit nachträgliche Änderungen auffallen.

Ab `v0.7.79` zeigt dieselbe Entscheidung zusätzlich einen Stabilitätsverlauf. Mehrere stabile Kandidaten werden als `mehrfach stabil` zusammengefasst; CSV und HTML nennen Kandidatenzahlen, führendes Profil, Empfehlung und Verlauf-CRC. Auch dieser Verlauf ist keine produktive Freigabe.

Ab `v0.7.80` enthält jede Entscheidung zusätzlich eine Feldserienkennung. Der Export zeigt diese Kennung je Eintrag und ergänzt den Verlauf um Feldserien, mehrfach stabile Feldserien und führende Feldserie.

Ab `v0.7.81` enthalten gespeicherte `SB-R`-RX-Prüfberichte echte Feldmetadaten mit Gegenstation, Testort, Frequenz, Betriebsart und manueller Feldserienkennung. JSON, HTML-Bericht und Oberfläche zeigen diese Angaben; die Metadaten sind mit eigener CRC und Protokoll-CRC geschützt.

Ab `v0.7.82` bevorzugen Prüfbericht-Historie, RX-Entscheidung und Stabilitätsverlauf diese echte Feldserienkennung. Dadurch werden mehrere deckungsgleiche Wiederanalysen derselben Feldtestserie korrekt zusammengefasst, während ältere Berichte ohne Feldserie weiter über die abgeleitete Kennung gruppiert werden.

Ab `v0.7.83` enthält die Entscheidung zusätzlich eine Feldserien-Bilanz. Oberfläche und Export zeigen pro Serie Gesamtzahl, stabile, brauchbare, kritische, offene und gesperrte Prüfstände, Status, Empfehlung und Bilanz-CRC.

Ab `v0.7.84` zeigen Oberfläche und Export zusätzlich die echten Felddaten aus den Prüfberichten. Gegenstation, Testort, Frequenz und Betriebsart erscheinen je Historien- und Entscheidungseintrag; die Feldserien-Bilanz fasst diese Angaben pro Serie zusammen.

Ab `v0.7.85` markiert die Feldserien-Bilanz gemischte Felddaten. Oberfläche und Export nennen betroffene Felder und die Anzahl unterschiedlicher Gegenstationen, Testorte, Frequenzen und Betriebsarten.

Ab `v0.7.86` ergänzt die Feldserien-Bilanz die zugehörigen Protokoll-IDs, Entscheidungseinträge und konkrete Ursachen je gemischtem Protokoll. Dadurch lässt sich eine falsch zusammengefasste Serie schneller auf einzelne Prüfberichte zurückführen.

Ab `v0.7.87` kann die Oberfläche aus dieser Bilanz heraus die passende Historien- und Entscheidungsstelle markieren und den WAV-Vergleich auf diese Auswahl begrenzen.

Ab `v0.7.99` zeigt FunkBrücke zusätzlich einen ungekürzten Ursachenbericht zur ausgewählten Feldserie und kann ihn exportieren. Der produktive FB1-Pfad bleibt davon getrennt; die strengere Kanalprüfung betrifft nur die lokale TX-Freigabe vor einer Aussendung.

Ab `v0.8.0` wird diese Trennung auch als Protokoll-Arbeitsfassung geführt. Der Protokoll-Tab zeigt `FB1`, Mesh, `FB2L`, `FB2` und `OFDM` mit Status, Version, Zweck und Grenze aus dem Core-Modell.

Ab `v0.8.1` betrifft die Änderung vor allem den produktiven `FB1`-/Mesh-Dateipfad: Der Dateien-Tab zeigt eine Wiederanlaufprüfung für Resume, NACKs, offene Zustellungen und fehlende lokale Daten. Der FB2-Laborstatus bleibt unverändert.

Ab `v0.8.2` ergänzt FunkBrücke Kompatibilitätsregeln und eine Mehrstationsdiagnose für den produktiven `FB1`-/Mesh-Pfad. Der FB2-Laborstatus bleibt weiterhin unverändert: `FB2L`, `FB2`, `SB-R` und `OFDM` liefern Planung und Diagnose, aber keine produktive TX- oder RX-Freigabe.

Ab `v0.8.3` ergänzt FunkBrücke Feldtestgrenzen für Paketgröße, Datei-Limit, Mesh-TTL, Hop-Limit, Duplikat-Merker, Link-Alter, Retry und Prioritäten. Auch diese Änderung betrifft den produktiven `FB1`-/Mesh-Arbeitsrahmen und verändert den FB2-Laborstatus nicht.

Ab `v0.8.4` ergänzt FunkBrücke den Feldtest-Kurzstart für reale FB1-/Mesh-Mehrstationsversuche. Die Liste führt durch Kanalprüfung, FB1-ACK, Mesh-Route, echte Weiterleitung, kleine Datei, NACK/Resume und Auswertung. Auch diese Änderung ist Betriebs- und Testführung für den produktiven FB1-/Mesh-Pfad; FB2, FB2L, SB-R und OFDM bleiben weiterhin Labor, Diagnose und Planung.

Ab `v0.8.5` ergänzt FunkBrücke eine Feldtest-Diagnosehilfe für den produktiven FB1-/Mesh-Pfad. Kanalblockade, fehlende Route, alte Links, fehlendes Mesh-ACK, TTL, Retry, Resume und NACK werden klarer erklärt. Der FB2-Laborstatus bleibt unverändert: keine produktive FB2-TX-Freigabe und keine automatische FB2-RX-Umschaltung.

Ab `v0.8.6` bewertet die Feldtest-Kurzstartliste jeden Schritt als offen, bereit, Warnung, Sperre oder erledigt. Diese Änderung betrifft weiterhin nur die Bedien- und Testführung des produktiven FB1-/Mesh-Pfads; FB2, FB2L, SB-R und OFDM bleiben Labor, Diagnose und Planung.

Ab `v0.8.7` enthält der Protokollstand zusätzlich einen Feldtest- und Mitentwickler-Katalog. Er beschreibt die produktiven FB1-/Mesh-Vorgaben, die benötigten Nachweise und die weiterhin gesperrte produktive Nutzung von FB2, SB-R und OFDM. Der FB2-Laborstatus bleibt unverändert.

Ab `v0.8.8` kann der Protokoll-Tab eine Feldtest-Exportübersicht aus Abnahme, Archiv, Mesh, Protokollstand, Feldtestgrenzen und Kurzstartstatus erzeugen. Diese Änderung sammelt Nachweise für den produktiven FB1-/Mesh-Pfad; FB2, SB-R und OFDM bleiben weiterhin Labor, Diagnose und Planung.

Ab `v0.8.9` kann aus dieser Übersicht zusätzlich eine Feldtestbericht-Vorlage als Markdown und HTML exportiert werden. Auch diese Änderung betrifft nur Nachweisführung und Berichtspaket für den produktiven FB1-/Mesh-Pfad; FB2, SB-R und OFDM bleiben Labor, Diagnose und Planung.

Ab `v0.8.10` können Beobachtung, Ursache, Maßnahme, Ergebnis und beteiligte Stationen direkt im Protokoll-Tab erfasst und in den Feldtestbericht übernommen werden. Der FB2-Laborstatus bleibt unverändert.

Ab `v0.8.11` werden Feldtestbericht-Entwürfe lokal gespeichert und beim Programmstart wieder geladen. Das betrifft weiterhin nur Nachweisführung und Feldtestorganisation; FB2 bleibt Labor, Diagnose und Planung ohne produktive TX-/RX-Umschaltung.

Ab `v0.8.12` warnt die Oberfläche bei ungespeicherten Änderungen im Feldtestbericht-Entwurf. Auch diese Änderung betrifft nur Dokumentation und Feldtestorganisation; der FB2-Laborstatus bleibt unverändert.

Ab `v0.8.13` speichert FunkBrücke die letzten zehn Feldtestbericht-Entwurfsstände als Zeitachse und kann einen ausgewählten Zwischenstand wieder übernehmen. FB2 bleibt dadurch unverändert Labor, Diagnose und Planung.

Ab `v0.8.14` kann diese Entwurfs-Zeitachse als JSON/HTML-Nachweis exportiert oder bereinigt werden, ohne den aktuellen Entwurf zu löschen. FB2 bleibt dadurch weiterhin unverändert Labor, Diagnose und Planung.

Ab `v0.8.15` bis `v0.9.78` wird die Feldtest-Nachweisführung weiter ausgebaut: Zeitachsen-Export als Berichtanlage, Berichtprüfung, vollständige Exportübersicht im Bericht, Einfrierprüfung für `FB1`/Mesh `v0.8`, konkrete Mehrstations-Testfälle, Ergebnis-/Nachweisstatus je Mehrstationsfall, lokale Speicherung dieser Ergebnisse, gezielte Übernahme in Feldtestbericht, Beta-Checkliste, Freigabeampel, Mesh-Neustartprüfung, Simulationen, verdichtete Beta-Auswertung, Beta-Kurzstart, Nachweispaket, Startcheck, Beta-Wiederaufnahme, Beta-Startpaket, Feldteam-Checkliste mit direkter Erfassung von Teilnehmern, Standort, Antenne und Testfreigabe, dauerhaft gespeicherte Feldteamdaten, Beta-Releasecheck, geführter Mehrstations-Testmodus, eine Prüfung echter Funkspuren mit Paket-ID, ACK/NACK, Route/Hop, Gegenstation, Codec und Archivnachweis, eine Sperrenauflösung für funkspur-lösbare, teilweise lösbare und manuelle Releasecheck-Sperren, fallabhängige Erfassungshilfen für Mehrstations-Ergebnisse, eine automatische Pflichtfeldprüfung beim Speichern, eine sichtbare Pflichtfeldübersicht vor dem Speichern, die Übernahme derselben fallabhängigen Pflichtfelder in echte Funkspuren, Exportübersicht und Beta-Releasecheck, die Funkspur-Nacharbeit mit Bearbeitungsstatus, Freigabestatus, Berichtübernahme und Releasecheck-Freigabe, direkte Nacharbeitsmarker, einen vollständigen Beta-Feldversuch-Durchlauf, einen v0.9.0-Organisationscheck, eine v0.9.0-Startmappe, den kompakten Beta-Startstatus, offene Feldtestdaten, einen Exportpaket-Prüfer, einen Beta-Probelauf als Generalprobe, einen Markdown-/HTML-Export der v0.9.0-Startmappe, die Startmappen-Gegenprüfung gegen Berichtanlagen und gespeicherte Mehrstationsdaten, die Beta-Startentscheidung als Testleiter-Freigabe, das Testleiter-Startprotokoll als kurze Freigabezeile in Export, Bericht und Startmappe, die abhakbare Feldversuchs-Startfreigabe mit Startzeitnachweis, deren Kopplung mit dem ersten Schritt des geführten Mehrstations-Testmodus, den nächsten Funkarbeitspunkt für den ersten offenen echten Funkfall nach Startfreigabe, dessen direkte Öffnung der passenden Mehrstations-Erfassung, eine Arbeitsanweisung mit erstem offenen Pflichtfeld und Ziel-Eingabefeld, eine neutrale Textbaustein-Übernahme in Beobachtung, Nachweis oder Abweichung, eine blockierende Platzhalterprüfung vor dem Speichern, die automatische Weiterführung zum nächsten Funkarbeitspunkt nach dem Speichern, einen durchgehenden Feldversuchs-Ablauf, der Startfreigabe, Testmodus-Phase, Funkarbeitspunkt und Ergebnisübernahme koppelt, dessen Übernahme in Feldtest-Exportübersicht und v0.9.0-Startmappe, die Gegenprüfung der Ablaufbelege gegen Berichtanlagen und gespeicherte Mehrstationsdaten, die durchgehende Freigabe-Kette bis zur Anzeige `Bereit für echten Mehrstationsversuch`, eine technische Startfreigabe aus CAT/PTT, Audio/RX, Kanalprüfung, FB1-Horchfenster und TX-Sperren, deren Übernahme in Exportübersicht, Startmappe, Startmappen-Gegenprüfung und Feldtestbericht, deren direkte Nennung in Beta-Startentscheidung, Testleiter-Startprotokoll und Feldversuchs-Startfreigabe, einen Technik-Vorstart-Probelauf ohne Aussendung für dieselben Punkte, dessen Kopplung als Pflichtnachweis in Startmappe, Startmappen-Gegenprüfung, Beta-Startentscheidung und Testleiter-Startprotokoll, dessen Übernahme in Feldversuchs-Startfreigabe und ersten Mehrstations-Testmodus-Schritt, dessen Weitergabe in Feldversuchs-Ablauf, Ergebnisübernahme und Berichtdetails, dessen sichtbare Aufnahme in offene Feldtestdaten und kompakten Beta-Startstatus sowie eine Priorisierung offener Feldtestdaten nach blockierender Wirkung und Quelle mit kurzer Prioritätsbegründung je Aufgabe und einer Fokusliste für blockierende offene Aufgaben, einem Sperrenfilter, Fokusnachweisen in Export/Startmappe/Bericht und Kategorien je offener Aufgabe sowie einer Funkversuchsführung mit Funkziel, Vor-TX-Prüfung, Paketnachweis und Fehlerreaktion je Mehrstations-Testmodus-Schritt sowie manuellen Mehrstations-Fehlerfallsimulationen für fehlendes FB1-ACK, blockierten Kanal vor TX, falsche Route und abgelaufenen Mesh-Link sowie einem Einfrierstand für eingefrorene, feldtestoffene und produktiv gesperrte Laborbereiche sowie dessen Übernahme in Feldtest-Exportübersicht, Startmappe, Startentscheidung und Feldtestbericht sowie einer Feldtestoffen-Vorprüfung für Routing, Datei/NACK und Resume samt direktem Abgleich gegen gespeicherte Mehrstationsfälle 02/03 und 04, deren Übernahme offener Beleglücken in offene Feldtestdaten, Fokusliste und nächsten Funkarbeitspunkt, einen v0.9.0-Startkandidaten als letzte Ampel aus Startentscheidung, Freigabe-Kette, Startfreigabe, Ablauf, Funkarbeitspunkt und Exportpaket, einen v0.9.1-Praxisstart als letzte Feldstartprüfung aus Startkandidat, echter Hardware, Kanalwächter, Feldteam und Sicherung nach dem Versuch, ein v0.9.2-Praxisstart-Protokoll, eine v0.9.3-Vorbereitung des echten Mehrstations-/Hardwareversuchs mit Funkziel, Vor-TX-Regel, Funkspur-Erfassung und Nachversuch-Sicherung, eine v0.9.4-Nachversuch-Auswertung, eine v0.9.5-Versuchslaufkarte, v0.9.6-Folgebelege, die v0.9.7-Folgebeleg-Zielhilfe, die v0.9.8-Folgebeleg-Startreihenfolge, den v0.9.9-Folgebeleg-Durchführungsplan, die v0.9.10-Folgebeleg-Feldlauf-Begleitung, die v0.9.11-Folgebeleg-Feldlauf-Erfassung, die v0.9.12-Folgebeleg-Feldlauf-Nachversuch-Rückwirkung, den v0.9.13-Folgebeleg-Nachversuch-Rücklauf, die v0.9.14-Folgebeleg-FB2-Messvorbereitung, den v0.9.15-Folgebeleg-FB2-Messrücklauf und die v0.9.16-Folgebeleg-FB2-Laborampel sowie die v0.9.17-Folgebeleg-FB2-Feldlauf-Startprüfung und die v0.9.18-Folgebeleg-FB2-Startprotokoll-Ergänzung sowie den v0.9.19-Folgebeleg-Feldlauf-Abhakplan, die v0.9.20-Folgebeleg-Feldlauf-Nachweisvorbereitung, den v0.9.21-Folgebeleg-Feldlauf-Nachweisabgleich, den v0.9.22-Folgebeleg-Feldlauf-Startauftrag und den v0.9.23-Folgebeleg-Feldlauf-Horchfensterbeleg und den v0.9.24-Folgebeleg-Feldlauf-Sendebeleg und den v0.9.25-Folgebeleg-Feldlauf-Nachlaufbeleg und die v0.9.26-Folgebeleg-Feldlauf-Abschlussentscheidung und die v0.9.27-Folgebeleg-Feldlauf-Abschlussnacharbeit, das v0.9.28-Folgebeleg-Feldlauf-Abschlussprotokoll und das v0.9.29-Folgebeleg-Feldlauf-Praxisprotokoll sowie die v0.9.30-Folgebeleg-Feldlauf-Live-Bedienmaske und den v0.9.31-Folgebeleg-Feldlauf-Live-Erfassungsbogen und die v0.9.32-Folgebeleg-Feldlauf-Live-Rückführung und die v0.9.35-Folgebeleg-Feldlauf-Live-Übernahme sowie die v0.9.38-Folgebeleg-Feldlauf-Live-Speicherprüfung sowie den v0.9.41-Folgebeleg-Feldlauf-Live-Abschlussabgleich sowie den v0.9.44-Folgebeleg-Feldlauf-Live-Nachversuchauftrag als Bericht- und Exportnachweise sowie die v0.9.45-Folgebeleg-Feldlauf-Live-Nachversuch-Abhakliste mit Abhakstatus, Neuprüfung, Bericht und Export sowie die v0.9.46-Folgebeleg-Feldlauf-Live-Nachversuch-Zielfeldhilfe mit Ziel-Eingabefeld und Textbaustein sowie die v0.9.47-Folgebeleg-Feldlauf-Live-Nachversuch-Erledigungsprüfung mit Platzhalter- und Paketdatenprüfung sowie die v0.9.48-Folgebeleg-Feldlauf-Live-Nachversuch-Abschlussnachprüfung sowie die v0.9.73-Folgebeleg-FB2-MVP-Startentscheidung sowie die v0.9.74-Folgebeleg-FB2-MVP-Audio-/PTT-Prüfung sowie die v0.9.75-Folgebeleg-FB2-MVP-Audioton/Loopback sowie die v0.9.76-Folgebeleg-FB2-MVP-Samplepuffer/RX-Rücklauf sowie die v0.9.77-Folgebeleg-FB2-MVP-RX-Laborereignis sowie die v0.9.78-Folgebeleg-FB2-MVP-Artefaktbeleg. FB2 bleibt dadurch weiterhin Labor, Diagnose und Planung ohne produktive TX-/RX-Umschaltung.

Ab `v0.9.4` kommt die Nachversuch-Auswertung als eigener Bericht- und Exportnachweis hinzu. Sie bewertet die belegten ACK/NACK-, Route-/Hop-, Gegenstations-, Kanalwächter-/FB1-Horchfenster-, Nacharbeits- und Exportpaketdaten, ohne FB2 produktiv zu aktivieren.

Ab `v0.9.5` kommt die Versuchslaufkarte als eigener Bericht- und Exportnachweis hinzu. Sie führt den echten Versuch in sieben Schritten und bleibt ebenfalls reine Feldtestführung ohne produktive FB2-Aktivierung.

Ab `v0.9.6` kommen Folgebelege als eigener Bericht- und Exportnachweis hinzu. Sie sammeln offene Laufkartenschritte als Nachweisaufgaben und bleiben ebenfalls reine Feldtestführung ohne produktive FB2-Aktivierung.

Ab `v0.9.7` kommt die Folgebeleg-Zielhilfe hinzu. Sie nennt Priorität, Ziel-Mehrstationsfall und Ziel-Eingabefeld im Bericht und Export, bleibt aber ebenfalls reine Feldtestführung ohne produktive FB2-Aktivierung.

Ab `v0.9.8` kommt die Folgebeleg-Startreihenfolge hinzu. Sie sortiert die priorisierten Belege in Funk- und Dokumentationsschritte und bleibt ebenfalls reine Feldtestführung ohne produktive FB2-Aktivierung.

Ab `v0.9.9` kommt der Folgebeleg-Durchführungsplan hinzu. Er macht aus der Startreihenfolge eine praktische Abarbeitung mit bereit/wartet, Abhakpunkt, Ergebnisziel und Nachversuch-Vorbereitung, bleibt aber ebenfalls reine Feldtestführung ohne produktive FB2-Aktivierung.

Ab `v0.9.10` kommt die Folgebeleg-Feldlauf-Begleitung hinzu. Sie führt den ersten bereiten Durchführungsschritt mit Start-, Durchführungs-, Ergebnis- und Nachversuch-Prüfpunkten, bleibt aber ebenfalls reine Feldtestführung ohne produktive FB2-Aktivierung.

Ab `v0.9.11` kommt die Folgebeleg-Feldlauf-Erfassung hinzu. Sie bereitet Ergebnisstatus, Notiz, Nachweis, Auswirkung und nächste Aktion je Prüfpunkt vor, bleibt aber ebenfalls reine Feldtestführung ohne produktive FB2-Aktivierung.

Ab `v0.9.12` kommt die Folgebeleg-Feldlauf-Nachversuch-Rückwirkung hinzu. Sie ordnet die erfassten Prüfpunkte den Nachversuchsfeldern zu, bleibt aber ebenfalls reine Feldtestführung ohne produktive FB2-Aktivierung.

Ab `v0.9.13` kommt der Folgebeleg-Nachversuch-Rücklauf hinzu. Er entscheidet, welche Rückwirkungen erledigt sind, welche als Folgebelege offen bleiben und welche blockierend in den nächsten Durchführungsplan gehören, bleibt aber ebenfalls reine Feldtestführung ohne produktive FB2-Aktivierung.

Ab `v0.9.14` kommt die Folgebeleg-FB2-Messvorbereitung hinzu. Sie nennt pro Rücklaufpunkt Messziel, Betriebsprofil, empfohlenen Modus, Signalbreite, Airtime, Messregel und produktive Sperre, bleibt aber ebenfalls reine Feldtestführung ohne produktive FB2-Aktivierung.

Ab `v0.9.15` kommt der Folgebeleg-FB2-Messrücklauf hinzu. Er trennt verwertbare Laboranlagen von offenen oder blockierten Messpunkten und bleibt ebenfalls reine Feldtestführung ohne produktive FB2-Aktivierung.

Ab `v0.9.16` kommt die Folgebeleg-FB2-Laborampel hinzu. Sie verdichtet dieselbe Lage für die Testleitung und verhindert, dass offene oder blockierte Laborwerte als vollständige Anlage erscheinen.

Ab `v0.9.17` kommt die Folgebeleg-FB2-Feldlauf-Startprüfung hinzu. Sie hält die Startentscheidung für den Laboranhang fest und stellt blockierte FB2-Laborwerte zurück, ohne daraus eine produktive Sperre für FB1/Mesh abzuleiten.

Ab `v0.9.18` kommt die Folgebeleg-FB2-Startprotokoll-Ergänzung hinzu. Sie übernimmt dieselbe Entscheidung in eine Vorlesezeile für die Testleitung und trennt Startprotokoll-Sperren weiterhin klar von nicht blockierenden FB2-Laborlagen.

Ab `v0.9.73` kommt die Folgebeleg-FB2-MVP-Startentscheidung hinzu. Sie wählt konservativ `4-FSK` auf `SSB schmal` und `8-FSK` auf FM-Profilen, prüft Sicherheitsgrenze und Rückfallpfad und bleibt ohne produktive FB2-TX-Freigabe.

Ab `v0.9.74` kommt die Folgebeleg-FB2-MVP-Audio-/PTT-Prüfung hinzu. Sie prüft Audioausgabe, PTT-Sperre, Einzeltestgrenze und Rückfallpfad, bevor ein späterer lokaler MVP-Audiotest vorbereitet wird.

Ab `v0.9.75` kommt die Folgebeleg-FB2-MVP-Audioton/Loopback hinzu. Sie belegt den lokalen MVP-Audiopuffer mit Modus, Symbolrate, Signalbreite, Abtastrate, Testdauer und Sampleanzahl, ohne TRX-Audioausgabe oder produktive FB2-PTT zu öffnen.

Ab `v0.9.76` kommt die Folgebeleg-FB2-MVP-Samplepuffer/RX-Rücklauf hinzu. Sie führt daraus einen lokalen Pufferbeleg mit Symbolfenster, Pegelgrenze, Puffer-CRC und RX-Rücklaufdiagnose, bleibt aber ohne TRX-Audioausgabe und ohne produktive FB2-PTT.

Ab `v0.9.77` kommt die Folgebeleg-FB2-MVP-RX-Laborereignis hinzu. Sie bildet eine wiederauffindbare Ereigniskennung, Puffer-CRC, Rücklauf-CRC und Ereignis-CRC als Bericht-/Exportanker, bleibt aber ohne TRX-Audioausgabe und ohne produktive FB2-PTT.

Ab `v0.9.78` kommt die Folgebeleg-FB2-MVP-Artefaktbeleg hinzu. Sie bindet das RX-Laborereignis an geplante JSON- und WAV-Artefaktnamen sowie Artefakt-CRC und Metadaten-CRC, bleibt aber ohne echten Dateischreiber, ohne TRX-Audioausgabe und ohne produktive FB2-PTT.

Ab `v0.9.79` kommt die Folgebeleg-FB2-MVP-Artefaktspeicher hinzu. Sie schreibt die lokalen JSON-/WAV-Artefakte, dokumentiert JSON-/WAV-Prüfsummen in Oberfläche, Bericht und Export und bleibt ohne Wiedergabe, PTT, Mesh-Weiterleitung oder produktiven FB2-TX.

Ab `v0.9.82` kommt die Folgebeleg-FB2-MVP-Artefaktprüfung hinzu. Sie lädt die gespeicherten Artefakte wieder, prüft die WAV-Datei gegen die Metadaten und dokumentiert die Soll/Ist-Bilanz in Oberfläche, Bericht und Export. Wiedergabe, PTT, Mesh-Weiterleitung und produktiver FB2-TX bleiben gesperrt.

Ab `v0.9.83` kommt das verbesserte Feldtest-Archiv hinzu. Es macht gespeicherte Feldtestnotizen als Ereignisse suchbarer, öffnungsfähig und exportierbar, damit reale FB1/Mesh-Beobachtungen später gezielt in die FB2-Nacharbeit einfließen können.

Ab `v0.9.84` kommt die FB2L-Mesh-Anbindungsbilanz hinzu. Sie macht sichtbar, welche direkten und gemeldeten Links eine empfangene Link-Bake in die Mesh-Tabelle einbringt und ob die Zielroute dadurch geöffnet oder bestätigt wird.

Ab `v0.9.85` kommt der Paketwarteschlangen-Trockenlauf hinzu. Er prüft im TX-Tab die FB1-/Mesh-Sendewarteschlange mit Priorität, Kanalregel und FB1-Horchfensterstatus, ohne Audioausgabe, PTT oder produktiven FB2-TX zu öffnen. Damit bleibt sichtbar, welcher Rückfallpfad vor einem späteren FB2-Test wirklich sendefähig wäre.

Ab `v0.9.86` kommt der gesperrte FB2-MVP-Audio-Ausgabepfad hinzu. Er liegt zwischen Audio-/PTT-Prüfung und Audioton/Loopback, benennt den Zielausgang, verlangt gesperrte Audiofreigabe, getrennte PTT und weiter gesperrten produktiven FB2-TX. Er ist reine Vorbereitung und spielt keine Samples ab.

Ab `v0.9.87` wird dieser Ausgabepfad härter abgesichert: erwartetes Audioformat `PCM mono 16 bit`, 48 kHz, Spitzenwertgrenze 0,70, Effektivwertgrenze 0,35 und der Rückfall auf FB1/Mesh sind eigene Prüfpunkte. Damit ist vor späteren Einzeltests klar, welches Ausgabeformat überhaupt zulässig wäre; Wiedergabe, PTT, Sendemotor und produktiver FB2-TX bleiben weiterhin gesperrt.

Ab `v0.9.88` entsteht daraus eine FB2-MVP-Testaudio-Vorbereitung. Sie bildet einen lokalen Sampleplan für den MVP-Modus und nennt Samplezahl, Dauer, Audioformat, Abtastrate und Pegelgrenzen. Der Beleg startet keine Wiedergabe und löst keine PTT aus; er ist nur die kontrollierte Vorstufe für einen später bewusst gestarteten Einzeltest.

Ab `v0.9.89` wird die FB2-MVP-Artefaktprüfung als Soll/Ist-Bilanz erweitert. Schema, Ereigniskennung, MVP-Modus, Artefaktbindung, produktive FB2-TX-Sperre und ein Gesamtbild ergänzen die bisherige JSON-/WAV-Prüfung. Dadurch ist besser sichtbar, ob gespeicherte Metadaten, WAV-Rücklauf und Sicherheitssperren zusammenpassen.

Ab `v0.9.90` wird daraus eine geführte FB2-MVP-Testlauf-Bedienfolge. Die Schritte Sicherheitsprüfung, Artefakt laden, Soll/Ist vergleichen, Audiofreigabe prüfen und Ergebnis exportieren erscheinen als eigener Nachweis. Auch diese Führung startet keine Wiedergabe und löst keine PTT aus.

Ab `v0.9.91` folgt daraus ein FB2-MVP-Lauffähigkeitsplan. Er trennt lokale Audioausgabe ohne PTT, Geräte-Loopback, RX-Erkennung, Funk-Einzeltest und produktiven FB2-TX als Sicherheitsstufen. Nur die nächste lokale Stufe wird vorbereitet; Wiedergabe, PTT, Sendemotor, Mesh-Weiterleitung und produktiver FB2-TX bleiben weiterhin gesperrt.

Ab `v0.9.92` bis `v0.9.97` wird diese lokale MVP-Leiter als Bedien- und Nachweiskette sichtbar: Einzeltest-Freigabemaske, Audio-Testausgabe-Vorbereitung, lokale Audioausgabe ohne PTT, Geräte-Loopback-Erfassung, RX-Erkennung gegen Loopback und Lauffähigkeitsampel. Die Ampel bewertet nur lokale Lauffähigkeit. Auch bei Grün bleiben PTT, Sendemotor, Mesh-Weiterleitung, Funk-Einzeltest und produktiver FB2-TX gesperrt.

Ab `v0.9.98` bis `v0.9.104` wird die Leiter in Richtung echter lokaler RX-Nachweise gehärtet: Testlaufdiagnose, Audioeingang-Capture, Capture-RX-Kopplung, JSON-/WAV-Loopback-Artefakt, geführter MVP-Testlauf, Geräteprüfung-Vorbereitung und Funknähe-Vorbereitung. Funknähe ist dabei ausdrücklich nur Planung: Vor jeder späteren Aussendung muss ein FB1-Horchfenster laufen; ein gültiger FB1-Rahmen blockiert, RX-Pegel allein entscheidet nicht, und der Sendeauftrag bleibt gesperrt.

Ab `v0.9.105` bis `v0.9.111` wird diese Leiter zum lokalen Gerätepfad ausgebaut. Der Capture-Messlauf belegt Start/Stopp und echte Live-Samples, die Capture-WAV-Speicherung schreibt daraus eine prüfbare PCM-WAV, die WAV-RX-Auswertung lädt diese Datei erneut und schickt sie durch die automatische FB2-RX-Erkennung. Danach vergleichen Soll/Ist-Prüfung, FT-991A-Gerätecheck, Geräte-Trockenlauf und Funknähe-Entscheidungsmatrix die lokale Audioausgabe, den Capture-Rücklauf, CAT-Lesbarkeit, PTT-aus, HF-Sperre, FB1-Horchfenster und Testleitung. Auch ein bereiter Matrixbefund bleibt nur Vorbereitung: keine automatische Sendefreigabe, keine CAT-PTT und kein produktiver FB2-TX.

Ab `v0.9.112` bis `v0.9.118` wird dieser Gerätepfad bedienbarer und releasefester. Der Capture-Messlauf kann im Test-Tab ausdrücklich gestartet, gestoppt, geleert und manuell als WAV gespeichert werden; beim Stoppen bleibt der Puffer erhalten. Eine Capture-WAV-Verwaltung listet die letzten Aufnahmen, erlaubt Auswahl, erneute Analyse und Ordneröffnung. Die WAV-RX-Diagnose nennt geprüfte Modi, besten Modus, Rahmenstatus, Symboltreffer, Abweichungen, Qualität und Erwartung. Dazu kommen ein FT-991A-Trockenlauf-Assistent, ein gegen Hänger gehärteter Screenshot-Helfer für die bebilderte Anleitung, ein lokal speicherbares Geräte-Trockenlauf-Protokoll und eine Funknähe-Test-Checkliste mit Frequenz-frei, FB1-Horchfenster, gültiger-FB1-Rahmen-blockiert-Regel, Testleitung, Gegenstation und Abbruchregel. Auch diese Stufe bleibt ausdrücklich ohne automatische Sendefreigabe, ohne CAT-PTT und ohne produktiven FB2-TX.

Ab `v0.9.119` bis `v0.9.125` wird daraus eine geführte lokale Geräte- und Funknähe-Vorbereitung. Gespeicherte Trockenlauf-Protokolle erscheinen als Historie mit Vorschau und Öffnen-Funktion. Ein lokaler FT-991A-Audiotest führt durch Audioausgang, Audioeingang, sicheres Testaudio ohne PTT, Capture, WAV und RX-Prüfung. Die Audio-Soll/Ist-Bewertung vergleicht Soll-Samples und Soll-Dauer mit Capture-WAV, Abweichungen und RX-Befund. Trockenlauf-Protokolle werden in Feldtestbericht und Exportübersicht als Nachweis aufgenommen. Zusätzlich entstehen eine speicherbare Funknähe-Live-Vorprüfung, ein Funknähe-Trockenlauf ohne Aussendung und ein Vorbereitungsplan für den ersten beaufsichtigten Funknähe-Test. Auch diese Stufe bleibt ohne automatische Sendefreigabe, ohne CAT-PTT und ohne produktiven FB2-TX.

Ab `v0.9.19` kommt der Folgebeleg-Feldlauf-Abhakplan hinzu. Er bindet Vorlesezeile, Vor-TX-Horchfenster, FB1/Mesh-Erfassung, FB2-Laboranhang und Bericht-/Export-Sicherung zusammen und bleibt reine Feldtestführung ohne produktive FB2-Aktivierung.

Ab `v0.9.20` kommt die Folgebeleg-Feldlauf-Nachweisvorbereitung hinzu. Sie ordnet Vor-TX und FB1/Mesh-Erfassung dem nächsten Mehrstationsfall zu und hält vorbereitete Textbausteine fest, ohne daraus eine produktive FB2-Freigabe abzuleiten.

Ab `v0.9.21` kommt der Folgebeleg-Feldlauf-Nachweisabgleich hinzu. Er vergleicht vorbereitete Ziel-Fälle mit den gespeicherten Mehrstationsbewertungen und zeigt offene oder bestätigte FB1/Mesh-Nachweise getrennt von FB2-Laborhinweisen.

Ab `v0.9.22` kommt der Folgebeleg-Feldlauf-Startauftrag hinzu. Er macht aus Abhakplan, Nachweisvorbereitung und Nachweisabgleich eine praktische Bedienkette: kein neuer Sendelauf bei bereits vollständigen Nachweisen, und bei offenen Funknachweisen nur FB1/Mesh nach freiem Horchfenster.

Ab `v0.9.23` kommt der Folgebeleg-Feldlauf-Horchfensterbeleg hinzu. Er hält den aktuellen FB1-Horchfensterbefund als freien, belegten oder offenen Kanalbeleg fest und sperrt TX bei fremdem gültigem FB1-Rahmen; RX-Pegel allein zählt weiterhin nicht.

Ab `v0.9.24` kommt der Folgebeleg-Feldlauf-Sendebeleg hinzu. Er verbindet freien Horchfensterbeleg, letzten FB1-Rahmen und Sendemotorstatus und übernimmt die Paket-ID als Pflichtbeleg für Nachweisabgleich, Nachversuch-Auswertung, Bericht und Export.

Ab `v0.9.25` kommt der Folgebeleg-Feldlauf-Nachlaufbeleg hinzu. Er bündelt Paket-ID, ACK/NACK, Route/Hop, Gegenstation, Mehrstations-Ziel-Fall, Nachversuch-Auswertung und Exportpaket zu einer Abschlussentscheidung für den echten FB1/Mesh-Feldlauf.

Ab `v0.9.26` kommt die Folgebeleg-Feldlauf-Abschlussentscheidung hinzu. Sie entscheidet, ob der echte FB1/Mesh-Feldlauf geschlossen wird, ob Nachweise im Ziel-Fall nachgetragen werden müssen oder ob eine Sperre den Abschluss verhindert.

Ab `v0.9.27` kommt die Folgebeleg-Feldlauf-Abschlussnacharbeit hinzu. Sie benennt offene Ziel-Fall-Werte mit Fallnummer, Ziel-Eingabefeld, Pflichtfeld, Befund, nächster Aktion und Marker, damit der Abschluss erst nach belegter Nacharbeit gesichert wird.

Ab `v0.9.28` kommt das Folgebeleg-Feldlauf-Abschlussprotokoll hinzu. Es erzeugt aus Abschlussentscheidung und Nacharbeit einen Schlussbeleg mit Protokoll-ID, Testleiterbezug, Archivziel, Doppelsendungsschutz und Entwurfsstatus bei offener Nacharbeit.

Ab `v0.9.29` kommt das Folgebeleg-Feldlauf-Praxisprotokoll hinzu. Es führt die Feldlaufkette als sieben Schritte für den Testleiter: Startauftrag, Horchfenster, Sendebeleg, Nachlauf, Abschlussentscheidung, Abschlussnacharbeit und Abschlussprotokoll.

Ab `v0.9.30` kommt die Folgebeleg-Feldlauf-Live-Bedienmaske hinzu. Sie zeigt Ziel-Fall, Zielstation, Paket-ID, Horchfenster, TX-Freigabe, ACK/NACK, Route/Hop und aktuellen Handgriff in einer kompakten Bedienlage für den echten FB1/Mesh-Feldlauf.

Ab `v0.9.31` kommt der Folgebeleg-Feldlauf-Live-Erfassungsbogen hinzu. Er sammelt Paket-ID, TX-/RX-Ereignis, ACK/NACK, Route/Hop, Gegenstation, Archivnachweis und Abschluss direkt nach dem Feldlauf als prüfbare Eingabeliste.

Ab `v0.9.32` kommt die Folgebeleg-Feldlauf-Live-Rückführung hinzu. Sie prüft den Ziel-Mehrstationsfall und erzeugt daraus einen speicherbaren Ergebnisentwurf erst nach vollständigem Live-Erfassungsbogen.

Ab `v0.9.33` bis `v0.9.35` kommt die Folgebeleg-Feldlauf-Live-Übernahme hinzu. Sie vergleicht vorhandene Mehrstationsfelder, übernimmt Live-Werte in die Erfassung und belegt diesen Schritt in Bericht und Export.

Ab `v0.9.36` bis `v0.9.38` kommt die Folgebeleg-Feldlauf-Live-Speicherprüfung hinzu. Sie prüft übernommene Live-Werte vor dem Speichern, sperrt unsichere Lagen und belegt die Speicherentscheidung in Bericht und Export.

Ab `v0.9.39` bis `v0.9.41` kommt der Folgebeleg-Feldlauf-Live-Abschlussabgleich hinzu. Er prüft nach dem Speichern den gespeicherten Mehrstationsfall gegen Live-Entwurf, Paketnachweis und Erfolgsmarkierung und belegt den Abschluss in Test-Tab, Bericht und Export.

Ab `v0.9.42` bis `v0.9.44` kommt der Folgebeleg-Feldlauf-Live-Nachversuchauftrag hinzu. Er plant aus offenen Abschlussabgleich-Punkten den nächsten Funk- oder Dokumentationsschritt und belegt diese Entscheidung in Test-Tab, Bericht und Export.

Ab `v0.9.45` kommt die Folgebeleg-Feldlauf-Live-Nachversuch-Abhakliste hinzu. Sie öffnet den Ziel-Fall, markiert Nachversuchpunkte als erledigt und prüft danach wieder gegen den echten Abschlussabgleich.

Ab `v0.9.46` kommt die Folgebeleg-Feldlauf-Live-Nachversuch-Zielfeldhilfe hinzu. Sie bereitet Beobachtung, Nachweis oder Abweichung als Ziel-Feld samt Textbaustein vor.

Ab `v0.9.47` kommt die Folgebeleg-Feldlauf-Live-Nachversuch-Erledigungsprüfung hinzu. Sie prüft vor dem Abhaken Ziel-Feld, Platzhalterfreiheit, Paket-ID, ACK/NACK, Gegenstation, Codec, Route/Hop und Archivnachweis.

Ab `v0.9.48` kommt die Folgebeleg-Feldlauf-Live-Nachversuch-Abschlussnachprüfung hinzu. Sie bündelt Abhakliste, blockierende Punkte, Ziel-Fall, Paket-ID und Freigabe für den erneuten Abschlussabgleich.