Report preparation
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
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
- In RTTY/DIGL mode, render two vertical tick marks or dashed lines on the
panadapter at the computed mark and space RF frequencies.
- Lines should update in real time as VFO is tuned or mark/shift values
are changed in the RTTY tab.
- Color suggestion: mark = green, space = red (matches MMTTY and most RTTY
software convention), or use the slice color with different dash patterns.
- 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_
Report preparation
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
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:
(i.e., 14.089.000 + 0.000915 = 14.089.915 MHz on the panadapter scale)
(i.e., 14.089.000 + 0.000745 = 14.089.745 MHz)
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_frequencyreported 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:
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
panadapter at the computed mark and space RF frequencies.
are changed in the RTTY tab.
software convention), or use the slice color with different dash patterns.
line, no triangle marker needed.
Protocol Hints
Mark frequency and shift are slice properties set via:
The
digl_offsetfield carries the mark frequency audio offset in Hz.Shift (mark-to-space distance) may be a separate field — needs verification
against
slice getstatus output for DIGL mode. Check theSliceModelfor which fields are populated in RTTY mode.
Relevant
SliceModelfields to audit:digl_offset(or equivalent mark frequency field)rtty_mark/rtty_shiftif separately trackedLabels
bug,GUI,spectrum,priority: medium