Request preparation
What would you like?
Summary
The current CW decoder works on the received signal (RX). This feature request
proposes adding independent toggles for RX and TX CW decoding, so operators
can enable each one separately.
Motivation
For operators who copy CW by ear, the RX decoder is often a distraction — it
invites mental laziness and is best left off. However, decoding what you
transmit is a completely different and very valuable use case:
- It lets you see your own sending errors in real time — mistimed dits,
dahs, spaces
- It works like instant feedback in the same way digital photography changed
how photographers learn: you see the result immediately and can adjust
- It's especially useful for operators learning or refining their keying
technique (straight key, bug, or paddle timing)
- It doesn't interfere with the "copy by ear" discipline, since TX decode
only activates when transmitting
Proposed Behaviour
Two independent toggles in the CW applet (or P/CW applet):
| Toggle |
Behaviour |
| RX decode |
Existing behaviour — decode incoming signal |
| TX decode |
Decode the transmitted signal (MOX/TUNE active), show in the same or a separate text panel |
Settings persisted independently via AppSettings (e.g. CwDecodeRxEnabled,
CwDecodeTxEnabled).
Implementation Notes
The TX audio path already flows through AudioEngine::onTxAudioReady().
The CW decoder (CwDecoder, using ggmorse) could be fed from that same audio
before it is sent to the radio — no additional VITA-49 stream needed.
A possible approach:
- In
AudioEngine::onTxAudioReady(), when TX is active and CwDecodeTxEnabled
is true, branch a copy of the audio buffer to CwDecoder::feedAudio()
CwDecoder already emits decoded text — the existing CW text panel in the
GUI can display it with a [TX] label or distinct colour- The two toggles map to separate
AppSettings keys and can live in the
existing CW/P/CW applet area
Why This Matters
This is a non-intrusive addition: operators who don't want it simply leave
both toggles as they are today. Those who do want TX monitoring gain a
powerful self-training tool with minimal UI footprint.
Related
- Existing
CwDecoder (ggmorse, confidence scoring, auto-show in CW mode)
AudioEngine::onTxAudioReady() — TX audio origin pointAppSettings — settings persistence
Request preparation
What would you like?
Summary
The current CW decoder works on the received signal (RX). This feature request
proposes adding independent toggles for RX and TX CW decoding, so operators
can enable each one separately.
Motivation
For operators who copy CW by ear, the RX decoder is often a distraction — it
invites mental laziness and is best left off. However, decoding what you
transmit is a completely different and very valuable use case:
dahs, spaces
how photographers learn: you see the result immediately and can adjust
technique (straight key, bug, or paddle timing)
only activates when transmitting
Proposed Behaviour
Two independent toggles in the CW applet (or P/CW applet):
Settings persisted independently via
AppSettings(e.g.CwDecodeRxEnabled,CwDecodeTxEnabled).Implementation Notes
The TX audio path already flows through
AudioEngine::onTxAudioReady().The CW decoder (
CwDecoder, using ggmorse) could be fed from that same audiobefore it is sent to the radio — no additional VITA-49 stream needed.
A possible approach:
AudioEngine::onTxAudioReady(), when TX is active andCwDecodeTxEnabledis true, branch a copy of the audio buffer to
CwDecoder::feedAudio()CwDecoderalready emits decoded text — the existing CW text panel in theGUI can display it with a
[TX]label or distinct colourAppSettingskeys and can live in theexisting CW/P/CW applet area
Why This Matters
This is a non-intrusive addition: operators who don't want it simply leave
both toggles as they are today. Those who do want TX monitoring gain a
powerful self-training tool with minimal UI footprint.
Related
CwDecoder(ggmorse, confidence scoring, auto-show in CW mode)AudioEngine::onTxAudioReady()— TX audio origin pointAppSettings— settings persistence