Repository navigation
v0.14.0 — V4 headerless wire format (breaking)
V4 headerless wire format — profile_index in the bootstrap marker
Why
Through the relay, HIGH+ never activated in auto-detect (it decoded 98/98 when the profile was forced). Root cause: the LMS warmup sat before the protocol header, but the warmup constellation depends on profile_index — only known after the header. The auto-detect anchor pass trained the FFE on the warmup with the wrong (anchor) constellation and corrupted the QPSK Golay header, so profile_index was never read. 0.13.18 patched this with a two-pass FFE; 0.14.0 removes the cause structurally.
What changed
- The protocol header is dropped. Its only live field,
profile_index, moves into the bootstrap marker (which self-equalises via its own sync — strictly more robust than the old header). New burst layout:
PREAMBLE → MARKER(profile_index, META) → WARMUP → META_CW → [MARKER → 2·CW]* - The RX reads the profile from the marker before training the FFE on the warmup → no more anchor-profile guessing, no two-pass fragility. Every segment is now self-describing, so re-entry after a channel outage is faster.
- Marker payload (still 12 B / 96 symbols) gains
profile_index+fmt_version+ anEOT_FRAMEflag; the EOT frame is headerless too. - Bonus: fixed a latent drift-estimator bug (the marker-fit Gardner now accounts for periodic preamble re-insertions).
Also in this release
fix(rx): widened sliding-window for slow ROBUST/ULTRA profiles.chore(gui): bundlertlsdr.dllas a Tauri resource (Windows builds).docs(gui): document the collector HMAC secret in BUILD_DEBIAN.
Validation (offline)
modem-core154/154 (loopback all profiles, marker, frame, drift).- Channel-sim + chunk-injection worker harness: HIGH / HIGH+ / HIGH++ all auto-detect and decode bit-exact, 0 codewords lost (every TX codeword recovered, RaptorQ repair not even needed).
- Pending: OTA both-ends retest through the relay (coordinate a correspondent, both on 0.14.0).
Assets (amd64 / Linux desktop)
nbfm-modem-gui_0.14.0_amd64.debnbfm-modem-gui_0.14.0_amd64.AppImage
arm64 / Raspberry Pi builds are produced separately on the Pi.