Title: CW local sidetone audible but radio fails to transmit RF (macOS)
What happened?
When using an iambic paddle connected to the system, AetherSDR correctly generates a local sidetone, indicating that the client-side iambic logic and audio routing are functioning. However, the FLEX-6400 does not enter transmit mode, and no RF signal is produced. The issue appears to be a breakdown in the command signaling between the client's CW keying logic and the radio's VITA-44 or TCP control stream.
What did you expect?
When the iambic paddle is engaged and sidetone is heard, the radio should key the transmitter (PTT) and emit a CW RF signal corresponding to the paddle input.
Steps to reproduce
- Launch AetherSDR v0.9.1 on macOS.
- Connect to a FLEX-6400 (Firmware v4.1.5.39794).
- Connect an iambic paddle to the local interface.
- Enable CW mode on a slice.
- Manipulate the paddle; observe that local sidetone is audible through the client audio output.
- Observe the radio hardware/Panadapter: No RF output is generated and the radio remains in RX mode.
Radio model & firmware
- Model: FLEX-6400
- Firmware: 4.1.5.39794
OS & version
- OS: macOS
- Qt Version: 6.11.0
Developer Notes
Based on the architecture described in CLAUDE.md, the local sidetone is generated by the client to minimize latency, while the actual keying command must be sent to the radio via the API.
Potential Root Causes:
- Command Serialization: The issue likely resides in
src/radio/flexradio.cpp or the specific CW handling logic in src/radio/cw_keyer.cpp (or similar). If the sidetone is audible, the CWKeyer is successfully processing the paddle input, but the transmit command or cw key API string may not be reaching the radio's command parser.
- TCP Control Stream: Check
src/network/tcp_command_client.cpp. There may be a regression in how cw key 1 and cw key 0 commands are formatted for firmware 4.x.
- VITA Protocol: If AetherSDR uses VITA-44 for low-latency keying, there may be an MTU or packet alignment issue specific to the macOS network stack in Qt 6.11.
Suspected Files/Functions:
src/radio/flexradio.cpp: Check the sendCWKey() or equivalent PTT/Keying functions.
src/gui/widgets/cw_panel.cpp: Verify if the GUI state is correctly passing the "Break-in" (VOX/Full QSK) settings to the radio object.
src/core/application.cpp: Look for the signal-slot connection between the Keyer logic and the Radio control logic.
Diagnostic Logging:
To capture the necessary data, please enable the following categories in Help → Support:
Radio Command (To see if cw key or ptt commands are being sent over TCP)
Network (To check for socket write errors)
CW/Keyer (To verify the timing and state transitions of the internal keyer)
Please inspect the console output for any "Sequence mismatch" or "Command failed" responses from the FlexRadio during CW attempts.
Title: CW local sidetone audible but radio fails to transmit RF (macOS)
What happened?
When using an iambic paddle connected to the system, AetherSDR correctly generates a local sidetone, indicating that the client-side iambic logic and audio routing are functioning. However, the FLEX-6400 does not enter transmit mode, and no RF signal is produced. The issue appears to be a breakdown in the command signaling between the client's CW keying logic and the radio's VITA-44 or TCP control stream.
What did you expect?
When the iambic paddle is engaged and sidetone is heard, the radio should key the transmitter (PTT) and emit a CW RF signal corresponding to the paddle input.
Steps to reproduce
Radio model & firmware
OS & version
Developer Notes
Based on the architecture described in
CLAUDE.md, the local sidetone is generated by the client to minimize latency, while the actual keying command must be sent to the radio via the API.Potential Root Causes:
src/radio/flexradio.cppor the specific CW handling logic insrc/radio/cw_keyer.cpp(or similar). If the sidetone is audible, theCWKeyeris successfully processing the paddle input, but thetransmitcommand orcw keyAPI string may not be reaching the radio's command parser.src/network/tcp_command_client.cpp. There may be a regression in howcw key 1andcw key 0commands are formatted for firmware 4.x.Suspected Files/Functions:
src/radio/flexradio.cpp: Check thesendCWKey()or equivalent PTT/Keying functions.src/gui/widgets/cw_panel.cpp: Verify if the GUI state is correctly passing the "Break-in" (VOX/Full QSK) settings to the radio object.src/core/application.cpp: Look for the signal-slot connection between the Keyer logic and the Radio control logic.Diagnostic Logging:
To capture the necessary data, please enable the following categories in Help → Support:
Radio Command(To see ifcw keyorpttcommands are being sent over TCP)Network(To check for socket write errors)CW/Keyer(To verify the timing and state transitions of the internal keyer)Please inspect the console output for any "Sequence mismatch" or "Command failed" responses from the FlexRadio during CW attempts.