What happened?
The speech processor (PROC) in the P/CW applet appears completely non-functional when using the microphone and headphone jacks directly on the FLEX-6600 (PC Audio disabled, DAX TX disabled). Toggling PROC on and off produces no observable effect in any of the three processor modes (NOR, DX, DX+):
The compression gauge shows zero deflection at all times, regardless of PROC state or mode.
Monitor audio (MON) sounds identical with PROC on or off — no audible change in density, level, or character.
Switching between NOR, DX, and DX+ produces no change in the compression gauge or monitor audio.
Because PC Audio is disabled and the mic/headphone are connected directly to the radio hardware, the entire TX audio path — including the speech processor DSP — lives on the radio itself. AetherSDR is only responsible for sending the correct transmit set commands to enable and configure the processor. The fact that MON is unaffected strongly indicates the radio is never receiving a valid enable command, or the command is being sent with incorrect parameters for this audio path configuration.
What did you expect?
With the mic connected directly to the radio and PROC enabled, the FlexRadio's on-board speech processor should engage, audibly increasing TX audio density and average level as heard via MON.
The compression gauge in the P/CW applet should deflect (reversed red fill from the right) proportional to gain reduction while speaking.
DX and DX+ should produce progressively more aggressive compression than NOR.
Behavior should be equivalent to SmartSDR with the same radio mic/headphone configuration.
Steps to reproduce
Connect FLEX-6600 with microphone and headphones plugged directly into the radio front panel.
In AetherSDR, confirm PC Audio is disabled (DAX TX off, PC audio input not selected).
Select USB or LSB mode on a slice.
Open the P/CW applet.
Enable MON so TX audio is audible through the radio headphone output.
Speak into the radio microphone and note the monitor audio character and compression gauge reading.
Click PROC to enable the speech processor (NOR mode).
Speak again — observe compression gauge and monitor audio.
Expected: Gauge deflects; monitor audio increases in density.
Actual: Gauge reads zero; monitor audio sounds identical to step 6.
Switch PROC mode to DX, repeat.
Switch PROC mode to DX+, repeat.
Toggle PROC off and on repeatedly — no difference detectable in any state.
Radio model & firmware
Radio: FLEX-6600
Firmware: 4.1.5.39794
OS & version
OS: Windows
AetherSDR version: 0.7.18.3
Qt version: 6.7.3
Developer Notes
Why this audio path matters for diagnosis:
When the mic and headphones are connected directly to the radio and PC Audio is disabled, AetherSDR is not involved in the TX audio signal chain at all. The audio never touches the PC. The speech processor DSP runs entirely on the radio hardware. AetherSDR's only responsibility is to send the correct SmartSDR protocol commands to enable and configure the processor. The monitor output reflects the radio's own DSP output. Therefore:
If MON sounds unprocessed, the radio is not applying processing — the enable command is not being received or is being rejected.
This is purely a command/protocol bug, not an audio pipeline or meter wiring bug.
The compression gauge being dead is a secondary symptom — if the processor is never enabled, the radio will report zero compression via VITA-49 meters, which is correct behavior from the radio's perspective.
Primary suspect — transmit set command not sent or malformed:
src/gui/PhoneCwApplet.cpp — Locate the PROC toggle button's signal handler. The critical question is whether clicking PROC actually calls through to emit a transmit set proc=1 (or equivalent) command on the wire. A common bug in AetherSDR applets is that QSignalBlocker guards used during syncFromModel() / model-to-UI refresh inadvertently suppress the user's click signal if a model update and the user interaction overlap. Check whether the PROC button connection is made before or after any initial sync, and whether the m_updatingFromModel guard pattern from MainWindow is applied here.
src/models/TransmitModel.cpp — Verify the setter for processor enable emits commandReady(cmd) unconditionally when called from user interaction. Also confirm the exact command string being constructed. For the FLEX-6600 on fw 4.1.5 the expected commands are likely:
transmit set proc=1
transmit set compander=1
transmit set compander_level=0 # 0=NOR, 1=DX, 2=DX+
The key names proc, compander, and compander_level should be verified against a Wireshark or TCP log capture of SmartSDR performing the same operation on the same radio. The CLAUDE.md notes that RF_frequency differs from freq between firmware versions — similar naming discrepancies may exist for TX processor parameters between the fw 1.4.0.0 reference and fw 4.1.5.
src/core/RadioConnection.cpp — Confirm that commandReady signals from TransmitModel are connected through to the TCP send path and that no command is being dropped or queued behind a connection-state gate.
Secondary suspect — mic source not set for direct radio mic:
SmartSDR requires the mic source to be explicitly set to the radio's front-panel or rear-panel mic input (e.g. transmit set mic_selection=MIC or mic_level commands) when PC Audio is disabled. If AetherSDR is defaulting to a PC mic source in the background — even though PC Audio appears disabled in the UI — the processor may be enabled but acting on a silent or wrong input, producing no audible effect and no compression meter activity. Check that the mic source selector in PhoneCwApplet sends the correct source command for the direct-radio-mic configuration.
Compression meter — why it reads zero in this case:
The compression value arrives via VITA-49 UDP (PCC 0x8002). If the processor is genuinely disabled on the radio because the enable command never arrived, the radio will correctly report zero compression — the gauge reading zero is expected in that scenario and is not itself a bug. Fixing the command path should restore both the audible processing and the gauge deflection simultaneously. If after fixing the command path the gauge still reads zero, then investigate:
src/models/MeterModel.cpp — Confirm a meter with nam=COMP (or PROC) from source TX is being registered from the TCP #-separated meter definition messages.
src/gui/PhoneCwApplet.cpp — Confirm the HGauge update slot is connected to the correct meter ID signal.
Recommended logging to enable (Help → Support):
Protocol — most important: logs every raw TCP line in both directions. After enabling this, click PROC on and search for transmit set proc= in the log. If the line is absent, the command is never being sent. If present, check the radio's R response line for a non-zero error code indicating rejection.
TX — captures all transmit state commands and S|tx status responses from the radio, confirming whether the radio acknowledges the processor state change.
Meters — confirms whether a non-zero compression meter value ever arrives from the radio once the command issue is resolved.
Definitive test: With Protocol logging active, click PROC on and immediately search the captured log for:
Cx|transmit set proc=1
support-bundle-20260404-093507.zip
If this line does not appear, the signal-to-command path in PhoneCwApplet → TransmitModel → RadioConnection is broken and that is the root cause.
What happened?
The speech processor (PROC) in the P/CW applet appears completely non-functional when using the microphone and headphone jacks directly on the FLEX-6600 (PC Audio disabled, DAX TX disabled). Toggling PROC on and off produces no observable effect in any of the three processor modes (NOR, DX, DX+):
The compression gauge shows zero deflection at all times, regardless of PROC state or mode.
Monitor audio (MON) sounds identical with PROC on or off — no audible change in density, level, or character.
Switching between NOR, DX, and DX+ produces no change in the compression gauge or monitor audio.
Because PC Audio is disabled and the mic/headphone are connected directly to the radio hardware, the entire TX audio path — including the speech processor DSP — lives on the radio itself. AetherSDR is only responsible for sending the correct transmit set commands to enable and configure the processor. The fact that MON is unaffected strongly indicates the radio is never receiving a valid enable command, or the command is being sent with incorrect parameters for this audio path configuration.
What did you expect?
With the mic connected directly to the radio and PROC enabled, the FlexRadio's on-board speech processor should engage, audibly increasing TX audio density and average level as heard via MON.
The compression gauge in the P/CW applet should deflect (reversed red fill from the right) proportional to gain reduction while speaking.
DX and DX+ should produce progressively more aggressive compression than NOR.
Behavior should be equivalent to SmartSDR with the same radio mic/headphone configuration.
Steps to reproduce
Connect FLEX-6600 with microphone and headphones plugged directly into the radio front panel.
In AetherSDR, confirm PC Audio is disabled (DAX TX off, PC audio input not selected).
Select USB or LSB mode on a slice.
Open the P/CW applet.
Enable MON so TX audio is audible through the radio headphone output.
Speak into the radio microphone and note the monitor audio character and compression gauge reading.
Click PROC to enable the speech processor (NOR mode).
Speak again — observe compression gauge and monitor audio.
Expected: Gauge deflects; monitor audio increases in density.
Actual: Gauge reads zero; monitor audio sounds identical to step 6.
Switch PROC mode to DX, repeat.
Switch PROC mode to DX+, repeat.
Toggle PROC off and on repeatedly — no difference detectable in any state.
Radio model & firmware
Radio: FLEX-6600
Firmware: 4.1.5.39794
OS & version
OS: Windows
AetherSDR version: 0.7.18.3
Qt version: 6.7.3
Developer Notes
Why this audio path matters for diagnosis:
When the mic and headphones are connected directly to the radio and PC Audio is disabled, AetherSDR is not involved in the TX audio signal chain at all. The audio never touches the PC. The speech processor DSP runs entirely on the radio hardware. AetherSDR's only responsibility is to send the correct SmartSDR protocol commands to enable and configure the processor. The monitor output reflects the radio's own DSP output. Therefore:
If MON sounds unprocessed, the radio is not applying processing — the enable command is not being received or is being rejected.
This is purely a command/protocol bug, not an audio pipeline or meter wiring bug.
The compression gauge being dead is a secondary symptom — if the processor is never enabled, the radio will report zero compression via VITA-49 meters, which is correct behavior from the radio's perspective.
Primary suspect — transmit set command not sent or malformed:
src/gui/PhoneCwApplet.cpp — Locate the PROC toggle button's signal handler. The critical question is whether clicking PROC actually calls through to emit a transmit set proc=1 (or equivalent) command on the wire. A common bug in AetherSDR applets is that QSignalBlocker guards used during syncFromModel() / model-to-UI refresh inadvertently suppress the user's click signal if a model update and the user interaction overlap. Check whether the PROC button connection is made before or after any initial sync, and whether the m_updatingFromModel guard pattern from MainWindow is applied here.
src/models/TransmitModel.cpp — Verify the setter for processor enable emits commandReady(cmd) unconditionally when called from user interaction. Also confirm the exact command string being constructed. For the FLEX-6600 on fw 4.1.5 the expected commands are likely:
transmit set proc=1
transmit set compander=1
transmit set compander_level=0 # 0=NOR, 1=DX, 2=DX+
The key names proc, compander, and compander_level should be verified against a Wireshark or TCP log capture of SmartSDR performing the same operation on the same radio. The CLAUDE.md notes that RF_frequency differs from freq between firmware versions — similar naming discrepancies may exist for TX processor parameters between the fw 1.4.0.0 reference and fw 4.1.5.
src/core/RadioConnection.cpp — Confirm that commandReady signals from TransmitModel are connected through to the TCP send path and that no command is being dropped or queued behind a connection-state gate.
Secondary suspect — mic source not set for direct radio mic:
SmartSDR requires the mic source to be explicitly set to the radio's front-panel or rear-panel mic input (e.g. transmit set mic_selection=MIC or mic_level commands) when PC Audio is disabled. If AetherSDR is defaulting to a PC mic source in the background — even though PC Audio appears disabled in the UI — the processor may be enabled but acting on a silent or wrong input, producing no audible effect and no compression meter activity. Check that the mic source selector in PhoneCwApplet sends the correct source command for the direct-radio-mic configuration.
Compression meter — why it reads zero in this case:
The compression value arrives via VITA-49 UDP (PCC 0x8002). If the processor is genuinely disabled on the radio because the enable command never arrived, the radio will correctly report zero compression — the gauge reading zero is expected in that scenario and is not itself a bug. Fixing the command path should restore both the audible processing and the gauge deflection simultaneously. If after fixing the command path the gauge still reads zero, then investigate:
src/models/MeterModel.cpp — Confirm a meter with nam=COMP (or PROC) from source TX is being registered from the TCP #-separated meter definition messages.
src/gui/PhoneCwApplet.cpp — Confirm the HGauge update slot is connected to the correct meter ID signal.
Recommended logging to enable (Help → Support):
Protocol — most important: logs every raw TCP line in both directions. After enabling this, click PROC on and search for transmit set proc= in the log. If the line is absent, the command is never being sent. If present, check the radio's R response line for a non-zero error code indicating rejection.
TX — captures all transmit state commands and S|tx status responses from the radio, confirming whether the radio acknowledges the processor state change.
Meters — confirms whether a non-zero compression meter value ever arrives from the radio once the command issue is resolved.
Definitive test: With Protocol logging active, click PROC on and immediately search the captured log for:
Cx|transmit set proc=1
support-bundle-20260404-093507.zip
If this line does not appear, the signal-to-command path in PhoneCwApplet → TransmitModel → RadioConnection is broken and that is the root cause.