fix(dax-iq): make DAX-IQ fully usable — meter, rate switching, state

[Ozy311]

Summary

Stacked on #3521 (the core fix that makes DAX-IQ actually deliver samples). Because both PRs target main, this one currently shows all 8 commits — the first 3 belong to #3521; the 5 commits unique to this PR are the UX/state fixes listed below. Once #3521 merges, this diff auto-reduces to just those 5. Please review/merge #3521 first.

With IQ finally flowing, the DAX-IQ applet's UX/state handling — never exercised because the feature never worked — needed fixing: the level meter, sample-rate switching, and enable/disable/startup state. Four focused commits.

Review note for the meter: DAX-IQ is the radio's native int16-scale float32 (raw amplitude, ~32768 full-scale), not normalized [-1, 1] — so the meter is scaled accordingly (see commit 1). This is a radio data convention, not a wire-type guarantee.

Fixes

1. fix(dax-iq): scale the level meter in dBFS for raw int16 IQ — the meter did rms * 200 assuming normalized [0, 0.5] IQ, so it pegged at 100% on the noise floor. It now maps RMS to dBFS over a [-70, -10] window (a level/overload meter: noise sits low, the bar fills toward digital overload) with attack/decay ballistics matching the DAX-audio meter.

Before (pegged ×200) vs after (responsive dBFS):

Before — rms × 200 pegs on the noise floor	After — dBFS, tracking signal across rates

2. fix(dax-iq): apply and persist the selected sample rate across enable — picking 24/96/192 k reverted to 48 k: createStream sent no rate (radio defaults 48 k) and setSampleRate dropped the selection when no stream existed yet. The chosen rate is now remembered and re-applied (stream set … daxiq_rate=) once the stream exists; the combo retains the user's choice across disable; and the transient 48k UI flip on enable is suppressed.

3. fix(dax-iq): zero the level meter when a channel is disabled or unbound — a level update queued just before a channel was switched off (or unbound from its panadapter, pan=0x0) could re-freeze the bar at its last value. The meter now drops to 0 whenever a channel isn't actively bound and receiving.

4. fix(dax-iq): restore persisted-enabled IQ channels and rates on startup — enabled channels showed "On" at launch but had no stream (dead). On Linux/macOS the IQ↔model wiring is established lazily inside MainWindow::startDax(), so the applet's connect-time restore fired before the wiring existed and was dropped. The restore is now triggered from startDax() (idempotent), and saved rates restore too.

5. fix(dax-iq): auto-start DAX so a DAX-IQ channel works without first enabling DAX audio — on PipeWire/macOS the DAX-IQ enable → stream create wiring is established lazily inside startDax() (Windows wires it at construction). So enabling a DAX-IQ channel before DAX audio was started silently dropped the request — nothing reached the radio and the meter never moved. Enabling a DAX-IQ channel now auto-starts DAX and creates the triggering channel directly; once the bridge is up the guard is inert and startDax()'s own connection handles later enables (no double-create). (Open design note for the maintainer: this auto-starts DAX audio as a side effect — the small, additive fix. The alternative is to un-lazy the DAX-IQ connections so they need no DAX-audio bridge at all; happy to take that route if preferred.)

Verified

Live on a FLEX-6700:

• All four rates (24/48/96/192 k) switch and persist across enable → disable → enable.
• Meter tracks signal across the real dynamic range: noise floor ~9%, strong AM carrier ~19%, super-strong broadcast AM ~74% — no pegging. (Calibration: −66 dBFS noise, −25.6 dBFS broadcast, confirming int16 full-scale.)
• Mixed on/off state (e.g. ch1+ch3 on at 96k/24k, ch2+ch4 off) restores exactly on boot.

Scope

• 4 commits, src/gui/DaxIqApplet.{cpp,h} + one call added to src/gui/MainWindow.cpp::startDax(). All portable Qt/STL — no platform guards needed.

Test plan

• Each commit builds standalone; full build clean (Linux).
• Live A/B on a FLEX-6700: rate switching (24/48/96/192 k persist across enable), dBFS meter response (noise ~9% → strong AM ~19% → super-strong broadcast ~74%, no peg), freeze-on-disable/unbind, startup restore of mixed on/off state.
• CI green on all three platforms: Linux build · Windows (MSVC) · macOS (clang) · CodeQL · accessibility.
• Runtime-verified on Linux, Windows, and macOS native builds against the same FLEX-6700: meter, rate switching, and startup state all work. The auto-start fix (commit 5) was confirmed live on macOS — a DAX-IQ channel now brings the meter alive on the first enable with no prior DAX-audio step.

---

73, Ozy K6OZY
AI compute partnership: cloaked.agency — drafted with Don, our VP of Engineering agent, on Linux dev stack (nobara-dell), live-verified against a FLEX-6700.

[aethersdr-agent]

Thanks @Ozy311 — this is a well-documented series, and the meter rework is a clear improvement (the dBFS window with attack/decay ballistics is the right model for a wideband IQ level meter, and the int16-scale convention is well-evidenced). The FIFO/state work follows repo conventions (AppSettings, owner-only XDG runtime dir mirroring the DAX-audio hardening). I reviewed the 5 commits unique to this PR; the DaxIqModel plumbing commits are #3521's and should get their review there.

A few real issues to address, all in the new auto-start / restore paths:

1. Double stream create after a DAX stop → IQ enable (the !m_daxBridge guard is not equivalent to "wiring absent"). stopDax() (MainWindow.cpp:15568) tears down the bridge but does not disconnect the IQ connections startDax() wires (statusReceived→applyStreamStatus, iqEnableRequested→createStream, iqRateChanged→setSampleRate — they're connected to this/the model, not to m_daxBridge). So after a start→stop cycle, an IQ enable click fires the surviving iqEnableRequested→createStream connection and your new lambda (which sees m_daxBridge == nullptr, calls startDax() again — wiring a duplicate set of connections — then calls createStream(ch) directly): two stream create type=dax_iq commands for one click, and every subsequent enable double-creates via the duplicated connections. The connection accumulation across start/stop cycles is pre-existing, but this PR makes it user-visible. Options, best first:

• Take the alternative you offered in the description: un-lazy the DAX-IQ wiring so it's established once at construction on all platforms (the IQ path doesn't actually need the audio bridge). That deletes the auto-start guard entirely and fixes the pre-existing duplication too. I'd prefer this route.
• Or: disconnect the IQ connections in stopDax() and track "IQ wiring up" with a member flag instead of inferring it from m_daxBridge.

2. The first-enable-before-DAX-start path loses a non-default rate. In buildUI() the enable handler emits iqRateChanged then iqEnableRequested — but on PipeWire/macOS before startDax(), iqRateChanged isn't connected to anything yet, so the rate emit is dropped, m_desiredRate stays at default, and the stream your lambda creates comes up at 48 k (and the exists combo-sync then flips the combo back to 48 k, clobbering the visible selection). This is the exact flow commit 5 fixes for the meter, so the rate should survive it too: in the auto-start lambda, call daxIqModel().setSampleRate(ch, rate) (rate read from the applet) before createStream(ch) — or moot the whole thing via option 1 above.

3. Please confirm m_desiredRate is initialized to {48000, …} in DaxIqModel.h (the header hunk was cut off in my diff view). If it zero-initializes, the path in issue 2 — createStream with no prior setSampleRate call — makes applyStreamStatus see isNew && m_desiredRate(0) != 48000 and send stream set … daxiq_rate=0 to the radio.

4. Suppressed streamChanged can leave a restored channel stuck "Off". When reapplyPending suppresses the isNew emit, the On-button sync (which the startup restore deliberately relies on) only happens when the follow-up rate status arrives. If the radio rejects the stream set … daxiq_rate= (or never echoes it), the button stays "Off" while the stream exists — and since setDaxIqLevel now gates on the button text, the meter stays pinned at 0 even with IQ flowing; clicking the button then issues a second createStream. Consider emitting streamChanged unconditionally and suppressing only the combo sync for the transient 48 k state (a flag or skipping the combo update when reapplyPending), rather than suppressing the whole signal.

5. Minor: overlapping restore timers can double-create. restoreEnabledChannels() can be scheduled from both the connect handler and startDax() within the same 1.5 s window (e.g. user clicks DAX On right after connect). The exists idempotence guard lags the radio round-trip, so two timers firing close together both pass it. A simple "restore pending" flag (or a single reusable QTimer member) would close this.

None of these block the core value here — the meter, rate persistence, and unbind-zeroing logic are all sound, and the live verification across three platforms is appreciated. Issue 1 is the one I'd consider required before merge; if you take the un-lazy-wiring route it resolves 1 and 2 together. Agreed that #3521 should land first.

---

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

[Ozy311]

Thanks for the thorough review — addressed all five points (numbering below matches your review). Your preferred route (un-lazy the wiring) did collapse points 1 and 2 as you predicted.

What changed

Items 1 & 2 — un-lazy the DAX-IQ wiring. The IQ-side connections (stream-status routing, VITA-49 feed, level meter, and enable/disable/rate) are now wired once at construction on all platforms — the #if !defined(Q_OS_MAC) && !defined(HAVE_PIPEWIRE) guard is gone. They never depended on the audio bridge, so:

• startDax() no longer wires any IQ connections (it keeps only the audio-bridge wiring), and the auto-start lambda is deleted.
• A DAX-IQ channel works without first enabling DAX audio (the standalone case the lambda was papering over).
• The enable/rate connections survive a DAX-audio stop because they were never tied to the bridge's lifetime — so stopDax() can't leave a half-wired path, and the surviving-connection + lambda double-fire is structurally impossible. Connection accumulation across start/stop cycles is also gone (wired once, not per-start).

This does mean enabling DAX-IQ no longer spins up the DAX audio bridge on Mac/PipeWire (it goes straight to createStream) — intentional, since IQ rides PanadapterStream's VITA-49 path independently of the bridge (matching the Windows precedent).

Item 3 — confirmed safe, no change. m_desiredRate already inits to {48000, 48000, 48000, 48000} and IqStream::sampleRate to 48000, so the createStream-with-no-prior-setSampleRate path can't send daxiq_rate=0.

Item 4 — emit streamChanged unconditionally; suppress only the combo sync. applyStreamStatus now always emits streamChanged, so the On/Off button and meter gating sync the instant the stream exists — a radio that rejects or never echoes the daxiq_rate re-apply no longer leaves the channel stuck "Off" with the meter pinned at 0. A new IqStream::rateSettling flag suppresses only the rate-combo sync during the transient, so the user's selection never visibly flips to 48k. I tracked the flag against the actual rate gap (m_desiredRate != s.sampleRate) rather than isNew, so an interleaved non-rate status (e.g. a pan= bind arriving between the 48k create-status and the rate echo) can't prematurely clear it and flicker the combo — it self-clears exactly on the status that reaches the rate.

Item 5 — m_restorePending guard. Collapses overlapping restoreEnabledChannels() 1.5 s timers (cleared the moment the timer fires) so two scheduled within the settle window can't both pass the lagging exists guard and double-create.

Verification

• Builds clean on Linux + PipeWire (Nobara, Qt 6.10.3, gcc 15.2.1); the PipeWire path exercises the same #if defined(Q_OS_MAC) || defined(HAVE_PIPEWIRE) branch macOS compiles.
• Live A/B on a FLEX-6700 (item 1): with two DAX-audio on/off cycles before a single channel-enable, the pre-patch build sent 3 stream create type=dax_iq for that one click (one duplicate per stranded cycle); the patched build sends exactly 1, and stays at 1 regardless of how many times DAX is toggled.
• Items 4 and 5 verified by code review (their triggers — a radio rejecting a rate-set, two restore timers racing — aren't hand-reachable on the bench).

73, Ozy K6OZY
AI compute partnership: cloaked.agency — drafted with Don, our VP of Engineering agent, on the Linux dev stack (nobara-dell).