RTTY decoder

[e72xgordan-lgtm]

Add Built-in RTTY (FSK/AFSK) Decoder with Text Output Panel

Labels: enhancement, audio, GUI

---

## What

A built-in RTTY (radioteletype) decoder that listens to the demodulated audio
from the active slice in DIGL/RTTY mode and decodes incoming 5-bit Baudot/ITA2
characters in real time, displaying the decoded text in a panel inside
AetherSDR — no external software required.

The decoder should support:
- Standard RTTY parameters: 45.45 baud (standard HF), 50 baud, 75 baud, 110 baud
- Mark/space shift: 170 Hz (standard), 200 Hz, 425 Hz, 850 Hz
- Baudot/ITA2 character set with LTRS/FIGS shift tracking
- USB and LSB carrier polarity (normal and reverse)

## Why

RTTY remains one of the most active HF digital modes, especially during
contesting (ARRL RTTY Roundup, CQ WW RTTY, EA RTTY Contest, etc.). Today,
AetherSDR users must run a separate application — MMTTY, fldigi, WSJT-X, or
Digi65 — alongside AetherSDR via DAX audio to decode RTTY. This adds latency,
complexity, and requires DAX to be enabled and routed correctly.

AetherSDR already ships a built-in CW decoder (`CwDecoder` via ggmorse). RTTY
decode is a natural complement for the second most common legacy digital mode
on HF. Keeping decode inside the client means zero-latency access to the same
audio pipeline already flowing through `AudioEngine`.

## How Other Clients Do It

**SmartSDR for Windows** does not include a built-in RTTY decoder. Users run
MMTTY or N1MM+ Logger with DAX audio routing.

**GQRX** does not include RTTY decode natively; users pipe audio to fldigi via
a virtual audio device.

**SDR++** has a community plugin (`rtty_decoder`) that accepts audio from the
demodulated output and renders decoded text in a dockable panel.

**fldigi** is the de-facto standard RTTY decoder on Linux: mark/space tone
detection via two narrow bandpass filters, zero-crossing timing, Baudot decode.
It is well-understood and its algorithm is well-documented.

The opportunity for AetherSDR is to be the **first FlexRadio client** to
include a native, zero-configuration RTTY decoder — matching or exceeding the
SmartSDR + MMTTY workflow without any external programs.

## Suggested Behavior

1. **Auto-activation:** When the active slice's mode is set to `RTTY`, `DIGL`,
   or `DIGU`, a **RTTY decode panel** appears automatically below the waterfall
   or as a togglable section in the `RxApplet` — similar to how the CW decode
   overlay appears automatically in CW mode.

2. **RTTY tab in VfoWidget / RxApplet:** A new **RTTY** tab (alongside existing
   DSP tabs) exposes:
   - Baud rate selector: `45.45` (default) / `50` / `75` / `110`
   - Shift selector: `170 Hz` (default) / `200 Hz` / `425 Hz` / `850 Hz`
   - Polarity toggle: `Normal` / `Reverse`
   - Mark frequency display (read from `digl_offset` via `SliceModel`)

3. **Decode text area:** A fixed-height (3–5 lines) scrolling text widget with:
   - Dark background, monospace font (Courier or similar)
   - Color-coded confidence (green = locked, yellow = marginal, red = no lock)
   - Auto-scroll with a "Pause scroll" button
   - "Clear" button to wipe the buffer
   - Copy-to-clipboard button

4. **Spectrum integration:** Two thin vertical lines on `SpectrumWidget` mark
   the mark and space frequencies (this already exists in partial form per
   issue #660 — this feature depends on that being correct).

5. **Settings persistence:** Baud/shift/polarity saved per-band in
   `AppSettings` under keys such as `RttyBaud_40m`, `RttyShift_40m`.

## Protocol Hints

Mark frequency and shift are controlled via slice properties in the
SmartSDR protocol:

C|slice set digl_offset=

`digl_offset` carries the mark audio offset in Hz. The shift (mark-to-space
distance) may be exposed as a separate field — verify against
`slice get <id>` output in DIGL mode.

Audio for decoding is already available in `AudioEngine::feedAudioData()` at
24 kHz (PCC 0x03E3) before the NR2/RN2 pipeline. The RTTY decoder should tap
the **pre-NR** audio (same tap point as `CwDecoder::feedAudio()`), as noise
reduction can distort FSK timing.

**Recommended decoder library:** [librtty](https://github.com/df9ry/librtty)
or a self-contained implementation based on the fldigi RTTY modem source
(`rtty.cxx`). Alternatively, a simple mark/space bandpass-filter + envelope
detector approach (similar to `CwDecoder`'s envelope approach) can be written
from scratch in ~300 lines.

No special FlexLib/protocol command is needed for decoding — it is entirely
client-side audio processing, identical in architecture to `CwDecoder`.

## Acceptance Criteria

- [ ] In DIGL/RTTY mode, a decode text panel appears automatically and
      scrolls decoded Baudot text in real time at 45.45 baud / 170 Hz shift
      with the radio tuned to an active RTTY signal.
- [ ] Baud rate, shift, and polarity are user-configurable via a RTTY tab
      in `RxApplet` or `VfoWidget`, and settings persist across restarts via
      `AppSettings`.
- [ ] The decoder taps audio before NR2/RN2 processing (same pipeline as
      `CwDecoder`) and does not affect audio output in any way.
- [ ] The decode panel is hidden in non-RTTY modes and shown automatically
      when mode switches to DIGL/RTTY (mirrors CW decoder auto-show behavior).
- [ ] No external processes, DAX routing, or virtual audio devices are
      required for basic RTTY decode to function.

---

Suggested labels: enhancement, audio, GUI

Note: Issue #660 ("RTTY Mark/Space Overlay Lines Drawn at Wrong Frequency") is related but distinct — it's a positioning bug for the existing visual overlay. This request is for the decode pipeline itself. Resolving #660 is a prerequisite for the spectrum overlay part of this feature (acceptance criterion bullet 4 implicitly depends on it), so it would be worth referencing #660 in the issue body when you file it.

[aethersdr-agent]

Triage Analysis

This is a well-researched feature request for a built-in RTTY decoder. I've reviewed the codebase to assess feasibility and map out the implementation path.

Existing Infrastructure

The request is accurate that AetherSDR already has strong architectural precedent via the CW decoder (CwDecoder class using ggmorse). The RTTY decoder would follow an almost identical pattern:

• Audio tap point: PanadapterStream::audioDataReady() is already connected to CwDecoder::feedAudio() in MainWindow.cpp:1167. An RTTY decoder would connect to the same signal — 24 kHz stereo float32 PCM, pre-NR processing. This is correct.
• Worker thread pattern: CwDecoder runs a decode loop on a dedicated QThread with a ring buffer fed from the audio thread. The RTTY decoder should use the same architecture.
• UI panel pattern: PanadapterApplet already has a m_cwPanel (80px fixed-height widget with scrolling text, stats bar, close button). An RTTY panel would be structurally identical.
• Mode-gated auto-show: MainWindow already gates CW decoder start/stop and panel visibility on mode == "CW" || mode == "CWL" (lines ~3689, ~4700, ~5010). The RTTY equivalent would gate on mode == "RTTY" || mode == "DIGL".
• Slice model: SliceModel already tracks rttyMark (default 2125 Hz), rttyShift (default 170 Hz), diglOffset, and diguOffset — all the parameters needed for decoder configuration.
• Spectrum overlay: Mark/space lines are already drawn in SpectrumWidget.cpp:3731–3746 for RTTY/DIGL modes (this is the code related to RTTY Mark/Space Overlay Lines Drawn at Wrong Frequency on Panadapter #660).

Proposed Implementation Plan

New files:

• src/core/RttyDecoder.h / src/core/RttyDecoder.cpp — FSK decoder class following the CwDecoder pattern. Self-contained mark/space bandpass filter + envelope detector + Baudot/ITA2 state machine. No external library dependency needed — this is ~300-400 lines of straightforward DSP (two narrow bandpass filters at mark/space frequencies, envelope comparison, bit clock recovery via zero-crossing, and a Baudot lookup table with LTRS/FIGS shift tracking).

Modified files:

• src/gui/PanadapterApplet.h/.cpp — Add m_rttyPanel (parallel to m_cwPanel) with decode text area, stats bar (baud rate, shift, lock status), and clear/copy/close buttons. Add appendRttyText(), setRttyPanelVisible(), setRttyStats() slots.
• src/gui/MainWindow.h/.cpp — Add m_rttyDecoder member, wire audioDataReady → RttyDecoder::feedAudio, add mode-gated start/stop logic for RTTY/DIGL modes (mirroring the CW decoder wiring at lines 1166, 3689-3692, 4700-4707, 5010-5013), add routeRttyDecoderOutput() mirroring routeCwDecoderOutput().
• src/gui/RxApplet.cpp — Add RTTY settings controls (baud rate combo, shift combo, polarity toggle) visible only in RTTY/DIGL mode, reading defaults from SliceModel::rttyMark()/rttyShift().
• src/core/AppSettings.cpp — Persist per-band RTTY baud/shift/polarity preferences.
• CMakeLists.txt — Add RttyDecoder.cpp to build.

Questions / Notes

1. Baud rate source: The SmartSDR protocol doesn't expose baud rate as a slice property — it's purely a client-side decode parameter. Should we default to 45.45 baud and let the user override, or attempt auto-detection (more complex, less reliable)?

2. Relationship to RTTY Mark/Space Overlay Lines Drawn at Wrong Frequency on Panadapter #660: The mark/space overlay lines in SpectrumWidget are already implemented. Issue RTTY Mark/Space Overlay Lines Drawn at Wrong Frequency on Panadapter #660 reports they're drawn at the wrong frequency. The RTTY decoder itself doesn't depend on the overlay being correct (it uses audio frequencies, not pixel positions), but the visual experience would benefit from RTTY Mark/Space Overlay Lines Drawn at Wrong Frequency on Panadapter #660 being resolved first or concurrently.

3. Scope check: The request mentions color-coded confidence (green/yellow/red). The CW decoder does this via cost values from ggmorse. For RTTY, confidence could be derived from mark/space SNR ratio — is this a must-have for v1, or could we ship with a simpler "locked/unlocked" indicator initially?

4. DIGU mode: The request mentions DIGL and RTTY but not DIGU. Should the decoder also activate in DIGU mode (which uses upper sideband for digital), or is RTTY decoding only meaningful in DIGL/RTTY?

Verdict

Valid enhancement request, no duplicate. The architecture is well-suited for this — the CW decoder provides a complete template for the audio tap, threading, UI panel, and mode-gated lifecycle. Estimated scope is moderate: a new decoder class plus wiring into existing patterns across ~5 files.

[aethersdr-agent]

Claude here — fix applied in PR #1393: #1393

What was changed: Add built-in RTTY (Baudot/ITA2) decoder with text output panel (#1392)

Files touched:

• CMakeLists.txt
• src/core/RttyDecoder.cpp
• src/core/RttyDecoder.h
• src/gui/MainWindow.cpp
• src/gui/MainWindow.h
• src/gui/PanadapterApplet.cpp
• src/gui/PanadapterApplet.h

— AetherClaude (automated agent for AetherSDR)

[va2px]

RTTY decoder auto-activation should remain optional.

Seasoned RTTY contesters will continue to use their preferred contest logging software together with external decoding tools (such as MMTTY, 2Tone, fldigi, etc.) that integrate tightly with their logger. Forcing automatic activation could interfere with these established workflows.

[motoham88]

I have PR #3336 opened for this. Have it working using MMTTY on another radio sending both 2125 and 915Hz standard RTTY messages to a 6500 on 4.1.5 doing the decoding. The trick is to use "REV" which doesn't exactly make sense to me as I'm used to Mark being lower than Space, but after fighting with this for about 5 hours and scrapping it once, got it working correctly. It continues to be a work in progress and automatically tracks the selectable tone frequency pair.