Fix RADE selecting DIGU on 40m from RxApplet mode combo

[NF0T]

Summary

• RxApplet's mode combo handler called m_slice->setMode("RADE") after emitting radeActivated(true, ...), sending the unknown mode string "RADE" to the radio and immediately triggering onRadeSliceModeChanged("RADE") → deactivateRADE().
• Depending on how radio firmware handles the unknown mode, the slice could land in DIGU instead of the DIGL correctly computed by activateRADE()'s kBands lookup, producing the user-reported symptom of RADE selecting DIGU on 40m.
• Fixes alignment with VfoWidget, which has always correctly returned after emitting radeActivated without calling setMode. RADE is client-side only; the actual DIGL/DIGU assignment happens inside activateRADE() before the watchdog connection is made.

Root Cause

RxApplet.cpp:430 (removed):

if (m_slice) m_slice->setMode(mode);  // mode == "RADE" — sent to radio, triggers deactivation

The comment at line 433 already stated "RADE is client-side only — the radio echoes back the real mode (DIGL/DIGU) immediately, so mode() == 'RADE' is never true in steady state" — the removed line was directly contradicting that invariant.

Test Plan

• Select "RADE" from the RxApplet mode combo on 40m → verify radio mode = DIGL, RADE engine active
• Select "RADE" from the RxApplet mode combo on 20m → verify radio mode = DIGU, RADE engine active
• RADE watchdog still fires: force slice to USB while RADE active → verify clean deactivation
• Selecting a non-RADE mode from RxApplet combo still deactivates RADE correctly
• VfoWidget quick-mode button and FreeDV spot click paths unaffected (no regression)

🤖 Generated with Claude Code

[aethersdr-agent]

Verified the fix against the codebase — looks good.

Confirmed:

• VfoWidget.cpp:1624-1627 returns after emit radeActivated(true, ...) without calling setMode("RADE") — RxApplet now matches that pattern exactly.
• The quick-mode button path in VfoWidget.cpp:1667-1670 follows the same convention.
• The existing comment at RxApplet.cpp:433-437 already documented the invariant the removed line was violating ("RADE is client-side only — the radio echoes back the real mode (DIGL/DIGU) immediately"). The PR description's root-cause analysis is accurate.
• The DIGU-on-40m symptom is plausible: shipping the unknown string "RADE" to the radio, followed immediately by the radio's echo-back of whatever it actually selected, would deactivate RADE after activateRADE()'s kBands DIGL/DIGU computation, and any radio-side fallback to DIGU would then stick.

Minimal, surgical, no convention concerns. Thanks @NF0T — nice catch on the cross-widget consistency bug.

[ten9876]

Claude here — merged. Tack Ryan! Surgical −1/+0 fix that brings the code back into alignment with the comment one line below it. The diagnosis nails the watchdog race: setMode("RADE") triggers onRadeSliceModeChanged("RADE") which sees an out-of-family mode and immediately deactivates RADE, while the radio falls back to whatever it considers reasonable for the band — DIGU on 40m, leaving the slice in DIGU instead of the DIGL activateRADE() had just correctly set.

Sibling VfoWidget has had the correct "emit → return" pattern since RADE shipped, so this is a real parity restoration, not a behavior change.

73, Jeremy KK7GWY & Claude (AI dev partner)

[scott-mss]

Bug Report – SmartSDR 4.2.18.41174
Version
SmartSDR v4.2.18.41174

Issue 1: Incorrect Sideband Display/Behavior in DIGL Mode
Steps to Reproduce

Open SmartSDR
Go to the Frequency Selector
Open the Mode dropdown (LSB, USB, AM, etc.)
Select a band/mode preset RADE:

75/80 meters (e.g., digital/raid entry) / 40 meters (same behavior observed)

Expected Behavior

When selecting a digital mode for lower HF bands (e.g., 75m, 40m), the radio should:

Switch to DIGL, show Rade in the Frequency Flag, Operate using LSB characteristics (as expected for these bands)

Actual Behavior

The slice flag indicates DIGL, Shows Rade active; however, on the panadapter, the radio appears to be using USB instead of LSB. This creates confusion about which sideband is actually in use

Issue 2: No Transmit Audio from Microphone
Steps to Reproduce

Key the radio (PTT): Speak into the microphone

Expected Behavior: RF output with audible modulation from the microphone input

Actual Behavior

Radio successfully enters TX mode, but No transmit audio is produced, No RF modulation observed

DAX Behavior Observed
While troubleshooting, the following DAX TX Stream behavior was observed:
When toggling DAX:

With DAX OFF:

TX Stream shows: "DAX TX Off"

When turning DAX ON:

TX Stream changes to: "Off – Busy"

Pressing OFF in TX Stream panel:

Changes status to: "Ready"

Turning DAX OFF again:

TX Stream returns to: "Off – DAX TX Off"

Turning DAX ON again:

Reverts to: "Off – Busy"

Notes

No transmit audio is present regardless of:

DAX being enabled or disabled

Behavior suggests the possibility:

TX audio source routing issue
DAX TX stream conflict or lock condition

support-bundle-20260517-132943.zip

Rig conditions: All Flex equipment is running the latest Firmware. All devices have a static IP address. All radio equipment is on a flat network, on its own Cisco Catalyst switch with no other devices on that network segment.
Windows 11 Pro 25h2
Flex 8600 4.2.18.4
TGXL 1.2.17
PGXL 3.8.9
AG8x2 4.1.16
Maestro
StreamDeck 32 button running with Stacks4 - both on the latest version
Sound Device - Connect6 USB sound mixer - Connected Devices Heil PR40 / Head Phones