Thanks @K5PTB — this is a well-executed contribution. The 3-way comparator data is exactly the kind of evidence we like to see, the Dire Wolf attribution (root THIRD_PARTY_LICENSES + README.aethersdr.md, GPL-2.0-or-later → GPL-3.0-or-later) is done right, and the code follows project conventions: no QSettings, RAII throughout (unique_ptr lanes, std::vector buffers), idiomatic C++20 (std::numbers, std::popcount, std::call_once). The sampleGap absolute-difference fix in shouldEmitFrame correctly anticipates the non-monotonic sample indices introduced by lane-major block processing — good catch. AetherAFSKDemod.cpp compiles clean standalone with -Wall -Wextra -std=c++20. No Copilot findings to address.

A few items, roughly in priority order:

1. FCS reject-display threshold changed 17 → 18 (recordReject) — lastRejectActualFcs/lastRejectExpectedFcs are now blanked for frameBytesSize < 18, but the comment four lines below (and the < 17 too-short check) still says 17 bytes is the minimum valid frame — a no-PID U-frame sits exactly at 17 and has a real FCS in bytes 15–16. As written, a 17-byte bad-FCS reject loses its FCS diagnostics. If this was intentional, the adjacent comment should say why; otherwise it looks like an off-by-one and should revert to >= 17.

2. The publishFrameMqtt change is a refactor, not a restoration. On the merge-base (f39746a3), appendFrame() already calls publishFrameMqtt(frame) under #ifdef HAVE_MQTT — MQTT publishing is not broken on main. This PR moves the call to a separate frameDecoded connection, which is behaviorally equivalent and fine to keep, but the PR description ("wiring was lost during cherry-pick… Restored") describes the author's fork, not upstream. Flagging so maintainers don't think main needs a hotfix.

3. Scope: a few unrelated edits in Ax25HfPacketDecodeDialog. The removal of controls->addStretch(2) is a visible layout change not mentioned in the PR — please either revert it or note the intent. The three invokeMethod PMF→lambda rewrites, the startTransmit declaration reorder in the header, and the hdlc_codec_test block relocation in CMakeLists are all functionally inert churn that inflates the diff; not blocking, but worth trimming.

4. Efficiency (non-blocking follow-up): the 9 A+ slicers each run a full independent front-end. Prefilter → IQ mix → RRC → envelope → AGC are computed identically in all 9 lanes (identical inputs, identical state); only the step-5 decision (spaceGain) and DPLL state actually differ. Dire Wolf shares one demodulated signal across its slicers for this reason. That's roughly 9× redundant DSP (~4k MACs/sample at 24 kHz). Your RPi 5 testing shows it's affordable, so fine to land as-is, but sharing the front-end across slicers would be a nice follow-up and would also shrink per-lane state.

5. Minor, diagnostics-only: the totalHdlcFrameStarts dedupe window (+ 10 samples) is half a symbol at 24 kHz/1200 baud; independent DPLLs commonly land flag detection a symbol or more apart, so cross-lane duplicates will still be counted — and with lane-major ordering, a later lane processing earlier samples fails the > comparison asymmetrically. Consider widening to a symbol-or-two window, or just documenting that the counter is approximate.

6. Trivia: the kPrefilterLenSym comment says "~8.3 symbol-times" but 383 × 1200⁄44100 ≈ 10.4; and the __restrict__ MSVC shim in AetherAFSKDemod.h is unused (nothing in the file uses __restrict__) and defines a reserved identifier — suggest dropping it.

Two FYIs, no action needed: the branch's actual merge-base is f39746a3 (two commits behind main at open — contradicts the "rebased immediately before opening" note, but there are no conflicts), and VhfMode::Off produces zero lanes so processMonoFloat early-returns with frozen diagnostics — fine today since nothing selects Off, just confirm that's the intended semantic.

None of the above is structural — item 1 is the only one I'd want resolved before merge. Nice work, and 73.

_{🤖 aethersdr-agent · cost: $19.8929 · model: claude-fable-5}

Thanks @K5PTB — this is a well-prepared PR. The vendoring follows the repo's third_party conventions (attribution in THIRD_PARTY_LICENSES, refresh notes, GPL-2.0-or-later → GPL-3.0-or-later is fine), the new code is clean RAII/C++20 (std::numbers, std::popcount, std::call_once, unique_ptr lanes), and the comparator data is appreciated. I verified two claims from the description against main:

• MQTT rewiring: confirmed equivalent. appendFrame()'s only early return is if (!frame.fcsOk), the shim sets fcsOk = true on every frame it emits, and appendFrame has no callers other than the frameDecoded connection. The direct frameDecoded → publishFrameMqtt connection preserves behavior.
• Settings: only whitespace changes to the grandfathered flat keys; no new AppSettings keys. ✓

Findings, none blocking:

1. Nine slicer lanes redundantly recompute an identical front end (perf, suggest follow-up). Each A+ lane runs the full ~209-tap BPF + IQ mix + 4× RRC convolutions on the same input samples; the lanes differ only at the slicer decision (m_spaceGain) and DPLL. Direwolf computes the filter chain once per channel and fans out only the per-slicer comparison — that structure would be both more faithful and ~9× cheaper on the VHF path (~94M MACs/s currently). Your RPi 5 results show it's workable as-is, so I'd take this as a follow-up refactor (shared front end producing mAmp/sAmp, per-slicer decision + DPLL state), not a blocker for this PR.

2. pllAlpha is accepted but silently ignored — kVhf1200PllAlpha is now dead. AetherAFSKDemod's constructor discards pllAlpha (and the other libmodem tuning params) in favor of the internal Direwolf inertia constants — documented in the header, but the shim still defines kVhf1200PllAlpha = 0.010 and passes it through addLaneA, so a maintainer tuning that constant would see no effect. Suggest dropping the constant and the parameter from addLaneA (or at minimum a comment at the call site noting the value is unused on the VHF path).

3. Gate-open no longer resets lane bitstream state — please confirm intentional. resetBitstreamStates() was removed along with its call in updateReceiveGate, so HDLC/demod state now persists across squelch closures. FCS protects against splicing, it matches Direwolf's behavior, and your test plan covers gate recovery — so this looks deliberate, but it isn't mentioned in the PR description's change list, and it's a behavior change independent of the new demodulator. Worth a sentence in the description for future archaeology.

4. Doc nits.

• README.aethersdr.md says the header provides a sinc_corr_afsk_demodulator alias — it doesn't; the shim adapts via AfskDemodWrapper. Please update.
• The CMake comment/status message labels the library "GPL-3"; the vendored code is GPL-2.0-or-later (GPL-3 only as combined work). Minor, but the THIRD_PARTY_LICENSES entry gets it right — worth matching.

5. Minor. The HDLC frame-start dedup window is hardcoded to 20 samples (one VHF symbol), but processBit is shared with the HF 300 path where a symbol is 80 samples — the counter is diagnostics-only and commented as approximate, so fine, but deriving it from config.sampleRate / config.baud would make it correct for both. Also, AetherAFSKDemod's filter design divides by bitrate/sampleRate unguarded — fine with today's hardcoded 24000/1200 callers, but a cheap assert would protect future ones.

Nice touches I want to call out: the quint64 cast fixing potential overflow in the duplicate-window computation, and the absolute-gap handling in shouldEmitFrame correctly accounting for the now non-monotonic currentDecodeSampleIndex across per-lane block processing.

_{🤖 aethersdr-agent · cost: $7.1404 · model: claude-fable-5}

Re-reviewed at head c8f11129 — the new AetherAFSKDemod, the shim block-processing rewrite, the GUI/MQTT rewiring, CMake, and the test. The findings from the previous round all look correctly resolved, and I didn't turn up anything blocking. 🎉 Nice work, @K5PTB — the 3-way comparator evidence is genuinely impressive.

Confirmed resolved from the prior pass

• CMake STATUS message + comment now correctly state the vendored source is GPL-2.0-or-later (combined work GPL-3.0). THIRD_PARTY_LICENSES and the README agree.
• Dead kVhf1200PllAlpha constant and the false pllAlpha tunable removed; addLaneA passes 0.010 inline with a comment explaining AetherAFSKDemod ignores it (uses Direwolf's internal DPLL inertia). HF lane keeps its real pllAlpha.
• MQTT is now a direct frameDecoded → publishFrameMqtt connection guarded by #ifdef HAVE_MQTT, and the duplicate call inside appendFrame() is gone — behaviorally equivalent since frameDecoded only fires for FCS-valid frames.
• Cross-lane dedup window widened to 20 samples (one symbol) with the "approximate counter" comment.

Things I checked that are correct

• Build linkage is complete. All four targets that compile AetherAx25LibmodemShim.cpp now link aether_afskdemod: the main AetherSDR target (via CORE_SOURCES→ALL_SOURCES), plus ax25_libmodem_shim_test, ax25_replay, and ax25_session_analyze. No orphaned consumer that would hit a link error.
• The non-monotonic currentDecodeSampleIndex. The new per-lane block loop sets currentDecodeSampleIndex from each bit's absolute index and then re-walks it per lane, so it's no longer globally monotonic within a processMonoFloat call. The switch in shouldEmitFrame to an absolute-difference sampleGap() correctly handles that — good defensive change. (The lastHdlcFrameStartSampleIndex gating is technically subject to the same non-monotonicity, but it only feeds the approximate totalHdlcFrameStarts diagnostic, so it's harmless and already documented.)
• s_cosTable init is call_once-guarded; reads after init are fine across instances/threads.
• AGC/DPLL/confidence paths and the single-vs-multi-slicer decision look faithful to the documented profile-A algorithm.

Non-blocking observations (no action needed for this PR)

• The shared-front-end-per-slicer de-dup is the right follow-up, as already noted — each of the 9 A+ lanes currently re-runs the prefilter + 4 LP convolutions independently. Fine to defer.
• VhfMode has no UI/AppSettings exposure and is hard-coded to APlus via the config default. That matches the PR's stated scope; just flagging that "A vs A+" is currently a compile-time-only choice.

CI was still in progress when I looked (build / check-macos / check-windows / CodeQL all running, none failed). Worth letting it green before merge, as @ten9876 noted. Thanks again for the thorough test plan and the careful attribution handling on the vendored code.

_{🤖 aethersdr-agent · cost: $3.2236 · model: claude-opus-4-8}