Skip to content

RTTY Mark/Space Overlay Lines Drawn at Wrong Frequency on Panadapter #660

Description

@chibondking

Report preparation

  • I used the AI-assisted bug report tool (Help → Support → File an Issue)
  • I have attached a support bundle or log file

What happened?

RTTY Mark/Space Overlay Lines Drawn at Wrong Frequency on Panadapter

This is taken live from the EA RTTY Contest. OS Windows 11. Aether SDR version 0.7.18.3

What

In RTTY/DIGL mode, the mark and space frequency indicator lines displayed on
the panadapter spectrum are rendered at incorrect positions. The visual
overlay does not match the configured mark frequency.

Observed: Mark set to 915 Hz. Standard shift 170 Hz (space = 745 Hz).
The overlay lines do not align with the actual signal peaks visible in the
FFT at those audio offsets from the VFO.

Platform: Windows 11
AetherSDR version: 0.5.2
Radio: FLEX-8600, firmware v1.4.0.0
Mode: RTTY / DIGL
VFO at time of observation: 14.089.000 MHz

Screenshot

Image

Why

RTTY operators rely on the mark/space overlay to visually center the signal
in the passband for correct copy. If the lines are drawn in the wrong
position, operators cannot use them for tuning and must rely entirely on
"eyeballing" the FFT peaks — defeating the purpose of the overlay entirely.

This is especially critical during contesting where fast, accurate RTTY
tuning is required.

Expected Behavior

With VFO at 14.089.000 MHz, mark = 915 Hz, shift = 170 Hz:

  • Mark line should appear at +915 Hz from the LSB carrier reference
    (i.e., 14.089.000 + 0.000915 = 14.089.915 MHz on the panadapter scale)
  • Space line should appear at +745 Hz from the same reference
    (i.e., 14.089.000 + 0.000745 = 14.089.745 MHz)
  • Both lines should sit directly on top of the two visible FFT peaks of the
    RTTY signal when the station is correctly tuned

Likely Root Cause

The overlay is probably being drawn relative to the slice center frequency
rather than the LSB audio carrier offset. In DIGL/RTTY mode, the
RF_frequency reported by the radio is the carrier (suppressed carrier)
reference, not the center of the audio passband. Mark and space are audio
tones above this reference.

The correct pixel position for the mark line is:

pixel_x = freqToPixel(slice.RF_frequency + (mark_hz / 1,000,000.0))

A secondary candidate: the mark frequency offset may be applied but the
sign is wrong, placing the lines below the carrier instead of above
(relevant in LSB vs. USB carrier inversion).

How SmartSDR Does It

SmartSDR for Windows draws two vertical lines on the panadapter in RTTY mode:
one for mark and one for space. These lines track with the slice overlay and
move correctly when the VFO is tuned. They sit exactly on the FFT peaks of a
correctly-tuned RTTY signal.

Suggested Behavior in AetherSDR

  1. In RTTY/DIGL mode, render two vertical tick marks or dashed lines on the
    panadapter at the computed mark and space RF frequencies.
  2. Lines should update in real time as VFO is tuned or mark/shift values
    are changed in the RTTY tab.
  3. Color suggestion: mark = green, space = red (matches MMTTY and most RTTY
    software convention), or use the slice color with different dash patterns.
  4. Lines should be visible but unobtrusive — thinner than the slice center
    line, no triangle marker needed.

Protocol Hints

Mark frequency and shift are slice properties set via:

C<seq>|slice set <id> digl_offset=<hz>

The digl_offset field carries the mark frequency audio offset in Hz.
Shift (mark-to-space distance) may be a separate field — needs verification
against slice get status output for DIGL mode. Check the SliceModel
for which fields are populated in RTTY mode.

Relevant SliceModel fields to audit:

  • digl_offset (or equivalent mark frequency field)
  • rtty_mark / rtty_shift if separately tracked
  • Filter low/high cut (to confirm passband reference point)

Labels

bug, GUI, spectrum, priority: medium


### What did you expect?

_No response_

### Steps to reproduce

_No response_

### Radio model & firmware

_No response_

### Linux distro & Qt version

_No response_

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions