Title: CW Sidetone and Keyer Active in SSB Mode Without RF Output
What happened?
While the transceiver is set to SSB mode, operating an iambic paddle connected to the radio (or through the client) triggers local CW sidetone generation. Additionally, the CW keyer speed (WPM) observed during this state is significantly faster than the speed previously configured in CW mode. Crucially, despite the sidetone and keyer activity, the radio does not generate any RF output, and the transmitter does not engage.
What did you expect?
When the radio is in a voice mode (SSB), the CW keyer logic and sidetone should be inhibited. Operating the paddles should have no effect, or at most, should only trigger CW keying if the radio is specifically in a mode that supports "Break-in" or "CW-in-SSB" (which is not standard for this configuration). The keyer speed should also remain consistent with the user-defined WPM setting.
Steps to reproduce
- Connect to a FLEX-6400 using AetherSDR 0.9.1.
- Set the radio mode to CW and set a specific keyer speed (e.g., 18 WPM).
- Switch the slice mode to USB or LSB.
- Close/Key the iambic paddle.
- Observe that sidetone is audible and the keying speed is higher than the 18 WPM previously set.
- Observe that the MOX/TX indicator does not activate and no power is indicated on the meters.
Radio model & firmware
- Radio: FLEX-6400
- Firmware: 4.1.5.39794
OS & version
- OS: macOS
- AetherSDR Version: 0.9.1
- Qt Version: 6.11.0
Developer Notes
Based on the AetherSDR architecture, this issue likely stems from a logic leak in the command handling between the client and the FlexRadio Vita-49/TCP/IP protocol layers.
Potential Root Causes:
- Mode Validation in Keyer Logic: The client-side CW keying logic (likely in
src/Radio/Cwwiz.cpp or a similar Keyer class) may be monitoring paddle inputs without checking the current slice mode (active_slice->get_mode()).
- Uninitialized Speed Variable: The "faster than set" WPM suggests that when the mode is not CW, the speed parameter might be falling back to a default value or an uninitialized variable in the
Radio or Transmit classes, rather than using the cw_speed value from the radio's state.
- Command Flow: In
src/Network/FlexTcpClient.cpp, the command to toggle sidetone or keying (cw key... or cwx...) might be being sent to the radio regardless of the slice's operational mode.
Suggested Files for Investigation:
src/Radio/Radio.cpp: Check how mode changes affect subsystem states.
src/Model/Slice.cpp: Verify if mode-specific constraints are applied to the keyer.
src/Radio/Cwwiz.cpp (or equivalent): Examine the iambic timing logic and speed calculation.
Recommended Logging Categories:
To diagnose the state of the radio when this occurs, please enable the following in Help → Support:
TCP_TX: To see if CW commands are being sent while in SSB.
RADIO_STATE: To verify the client's perception of the current mode and keyer settings.
CWX: To monitor the internal keyer's timing and speed calculations.
[How to use CW on FlexRadio](https://www.youtube.com/watch?v=ZcuaRwFyThE)
This video provides a walkthrough of the radio's native CW settings and keyer configuration, which helps in identifying if the behavior is a client-side bug or a radio configuration conflict.
Title: CW Sidetone and Keyer Active in SSB Mode Without RF Output
What happened?
While the transceiver is set to SSB mode, operating an iambic paddle connected to the radio (or through the client) triggers local CW sidetone generation. Additionally, the CW keyer speed (WPM) observed during this state is significantly faster than the speed previously configured in CW mode. Crucially, despite the sidetone and keyer activity, the radio does not generate any RF output, and the transmitter does not engage.
What did you expect?
When the radio is in a voice mode (SSB), the CW keyer logic and sidetone should be inhibited. Operating the paddles should have no effect, or at most, should only trigger CW keying if the radio is specifically in a mode that supports "Break-in" or "CW-in-SSB" (which is not standard for this configuration). The keyer speed should also remain consistent with the user-defined WPM setting.
Steps to reproduce
Radio model & firmware
OS & version
Developer Notes
Based on the AetherSDR architecture, this issue likely stems from a logic leak in the command handling between the client and the FlexRadio Vita-49/TCP/IP protocol layers.
Potential Root Causes:
src/Radio/Cwwiz.cppor a similarKeyerclass) may be monitoring paddle inputs without checking the current slice mode (active_slice->get_mode()).RadioorTransmitclasses, rather than using thecw_speedvalue from the radio's state.src/Network/FlexTcpClient.cpp, the command to toggle sidetone or keying (cw key...orcwx...) might be being sent to the radio regardless of the slice's operational mode.Suggested Files for Investigation:
src/Radio/Radio.cpp: Check how mode changes affect subsystem states.src/Model/Slice.cpp: Verify if mode-specific constraints are applied to the keyer.src/Radio/Cwwiz.cpp(or equivalent): Examine the iambic timing logic and speed calculation.Recommended Logging Categories:
To diagnose the state of the radio when this occurs, please enable the following in Help → Support:
TCP_TX: To see if CW commands are being sent while in SSB.RADIO_STATE: To verify the client's perception of the current mode and keyer settings.CWX: To monitor the internal keyer's timing and speed calculations.[How to use CW on FlexRadio](https://www.youtube.com/watch?v=ZcuaRwFyThE)
This video provides a walkthrough of the radio's native CW settings and keyer configuration, which helps in identifying if the behavior is a client-side bug or a radio configuration conflict.