js8core: compound-call commands and SNR as desktop, GCC includes

[randal007]

Hi again! Thanks for pulling the #104 fixes into the core in #105. Two more from the X6100 port (a third, withdrawn, is struck out below), each its own commit:

1. Commands and SNR to and from compound calls (KG4UHM/6) packed as desktop. pack_cmd() / unpack_cmd() used (cmd & 0x1F) << 2 | (num & 0x03). Desktop's Varicode::packCmd() packs an SNR command as [1][type][6-bit number] (type 1 = HEARTBEAT SNR) and any other command as its 7-bit value. So every command in a compound-directed frame differed from desktop's, and an SNR kept only 2 bits. Found on the air 2026-10-11: my reply "KG4UHM/6 SNR -03" went out as SNR -31, and KG4UHM/6's heartbeat ACKs (from desktop) showed up here as "HW CPY?". Now desktop's two functions. varicode_roundtrip gets 14 new checks: frames to and from KG4UHM/6 against desktop's own buildMessageFrames() (built with Qt), and desktop's compound frames reading back with their command and SNR.

2. Ultra (JS8 60) decoded on Turbo's schedule. Withdrawn (reverted in 5a108cf): I misread desktop. It decodes JS8 60 once a slot at samplesNeeded(), as the engine already does; thanks @punk-kaos (see the comments).

3. <functional> and <cstring> includes. varicode.hpp uses std::function and jsc.cpp std::strncmp; libc++ pulls the headers in transitively, GCC's libstdc++ doesn't always.

Tested: these are the same changes as local patches 16 and 1 in the X6100 port's copy of the core (third-party/js8core, with your #105 changes there too). That copy's tests pass, including the new varicode_roundtrip checks, built with GCC. Patch 16 has been on the air on X6100s since beta 5.1 (2026-10-12). I haven't built this branch with the Android toolchain.

73, Randal VE7NHW

🤖 Generated with Claude Code

[punk-kaos]

I see one small bug in your Ultra timing code, you removed
if (sm.id == protocol::SubmodeId::C ||
sm.id == protocol::SubmodeId::I) {
samples_needed = sm.symbol_samples * JS8_NUM_SYMBOLS;
retry_samples = sample_rate;

That removes the start-delay allowance and 500 ms guard from Ultra's decode threshold.
That means you're running your first decode at 2.528s, when its impossible to have all 79 symbols in less than 2.628s. That means you're trying to decode 100ms before you have enough symbols and essentially wasting the first decode attempt then catching it on the second.

[randal007]

Thanks, you're right, and the bigger mistake was mine: I misread desktop. Its turboOrUltra branch decodes Turbo and Ultra once a slot at samplesNeeded() (79 symbols + start delay + 0.5 s), not as soon as the symbols are in. So the engine's own path for I was already desktop's. I've reverted the Ultra commit here (5a108cf) and in our copy. The other two commits stand.

Out of curiosity I measured how much the early try actually loses. Generated single-frame signals, decoded with legacy_decode on a window cut off where each attempt would fire, 20 noise seeds per point (DT = how late the sending station's clock is).

Ultra (first try 2.528 s, desktop 3.128 s, retry 3.528 s):

	first	desktop	retry
−9 dB and up, DT −0.2 to +0.5	≈ all	≈ all	≈ all
−11 dB, DT 0	17/20	18/20	18/20
−13 dB, DT +0.3	2/20	5/20	6/20
−13 dB, DT +0.5	0/20	6/20	6/20

So the first try does decode on-time signals (the missing 100 ms is mostly the last Costas block), but loses weak or late ones, which then show up 0.4 s after desktop would have had them.

Turbo, for your information only (it's your design, and it holds up): first try 3.95 s, desktop 4.55 s, retry 4.95 s. With DT −0.2 to +0.1 the first try equals desktop at every SNR. At DT +0.3 it misses some even when strong (−9 dB: 12/20, 0 dB: 18/20, desktop 20/20); the retry at 4.95 s gets every one desktop gets. Oddly DT +0.3 was worse than +0.5 on the first try (−9 dB: 12/20 vs 20/20); I haven't dug into why. The same 100 ms start delay applies to Turbo, so its first try is also before the end of the signal.

73, Randal VE7NHW