What happened?
When the amplitude (dBm) scale on the right side of the spectrum is dragged upward, the displayed noise floor and signal levels appear to shift upward at a different rate than the scale markings. For example, with a noise floor visually sitting at approximately −130 dBm, dragging the scale upward causes the noise floor indicator to drift toward the top of the display while the scale labels read as high as −100 dBm — implying the noise floor has risen ~30 dB when it has not.
A second symptom is visible when the spectrum trace is near the bottom of the display window: signal variation appears asymmetric, with excursions in the positive direction (upward) being noticeably larger than excursions in the negative direction (downward). As the scale is dragged upward and the trace moves toward the middle or upper portion of the display, this asymmetry reduces and the spectrum begins to behave more symmetrically, as expected.
SmartSDR (SSDR) does not exhibit either of these behaviors — its spectrum behaves like a conventional spectrum analyzer where the scale and the trace remain tightly coupled during amplitude range adjustments.
What did you expect?
Dragging the amplitude scale should uniformly re-map the dB-per-pixel axis without shifting the apparent power level of any signal or the noise floor. The noise floor should remain at its true dBm value (e.g. −130 dBm) regardless of the vertical scale position or zoom level. Signal variation (FFT frame-to-frame noise) should appear symmetric around the mean noise floor at all scale positions and vertical positions within the display.
Steps to reproduce
Connect to a FLEX-6600 running firmware 4.2.18.41174.
Open the spectrum/panadapter display and observe the noise floor — note the approximate dBm reading (e.g. −130 dBm).
On the right-hand amplitude scale, click and drag upward to shift the displayed dBm range.
Observe that as the scale is dragged, the noise floor trace moves upward at a different rate than the scale markings — the noise floor eventually reads ~−100 dBm on the scale even though no RF conditions have changed.
Before dragging (trace near bottom of display), observe that frame-to-frame fluctuations in the noise floor appear asymmetric — more positive (upward) variation than negative (downward).
After dragging the scale so the trace is near the middle or top of the display, observe that the same fluctuations appear more symmetric.
Compare the same band/conditions in SmartSDR — note that the noise floor remains anchored to its true dBm value regardless of scale dragging, and variation is symmetric throughout.
Radio model & firmware
Radio: FLEX-6600
Firmware: 4.2.18.41174
OS & version
OS: Windows 11
AetherSDR version: 0.9.5.1
Qt version: 6.7.3
Developer Notes
Relevant source files and functions:
The bug most likely originates in src/gui/SpectrumWidget — specifically the functions responsible for:
FFT bin → pixel Y-coordinate mapping — The CLAUDE.md documents the bin-to-dBm conversion as:
dBm = min_dbm + (sample / 65535.0) × (max_dbm − min_dbm)
where min_dbm / max_dbm come from display pan status messages. The conversion produces a linear floating-point dBm value per bin. The subsequent step that maps this dBm value to a pixel Y-position within the widget must account for the current displayed dBm range (the draggable scale). If the pixel-mapping function applies any non-linear transform (e.g. a log or power function on the already-linear dBm value, or integer truncation before the range normalization), this would produce the observed asymmetric clipping near the bottom of the display and apparent level drift when the scale is moved.
Scale drag handler — The function that handles mouse drag on the right-side amplitude axis. If this handler modifies min_dbm / max_dbm state that is also used in the bin conversion formula (rather than only affecting the display viewport mapping), it would cause the displayed noise floor to move in dBm space rather than just in pixel space — explaining the scale/trace rate mismatch.
Exponential smoothing — CLAUDE.md notes that the FFT display uses exponential smoothing with α=0.35 (SpectrumWidget). If smoothing is applied to pixel Y-values rather than to the underlying dBm values, the effective smoothing range would be asymmetric near the bottom of the widget (pixel values cannot go below 0, so the distribution is clipped/skewed downward), explaining the asymmetric variation observed when the trace is near the bottom of the display.
Likely root causes to investigate:
Smoothing domain: Check whether the α=0.35 exponential moving average is applied to raw dBm values or to computed pixel Y-coordinates. It must be applied in dBm space before pixel mapping; applying it in pixel space introduces the observed floor-proximity asymmetry.
Scale drag vs. display range vs. conversion range: Verify that the amplitude scale drag updates only the display viewport (the Y-axis rendering range) and does not write back into min_dbm/max_dbm fields used by the VITA-49 bin conversion. These should be independent: min_dbm/max_dbm are radio-reported calibration constants; the displayed dBm window is a GUI-only view parameter.
Integer/float precision: Check for any int cast of dBm or pixel values before the range normalization step. Truncation before division would introduce systematic positive bias.
Logging to enable (Help → Support):
Enable the following diagnostic logging categories to capture useful data:
Panadapter / FFT — to log raw min_dbm, max_dbm values from display pan status messages and confirm they are stable during scale dragging.
VITA-49 / Stream — to confirm raw uint16 bin samples are arriving correctly and that PanadapterStream::FrameAssembler is not introducing artifacts.
GUI / Spectrum — if present, to log the computed dBm values and pixel Y coordinates per frame.
A useful diagnostic is to log 10–20 consecutive noise-floor dBm values (post-conversion, pre-smoothing) at two scale positions (trace at bottom vs. trace at middle) to confirm whether the asymmetry exists in the dBm domain or only appears after pixel mapping/smoothing.
Reference: SmartSDR (C#/Windows) does not exhibit this behavior, suggesting the FFT bin conversion itself is correct and the issue is in AetherSDR's display-layer mapping or smoothing pipeline in src/gui/SpectrumWidget.
What happened?
When the amplitude (dBm) scale on the right side of the spectrum is dragged upward, the displayed noise floor and signal levels appear to shift upward at a different rate than the scale markings. For example, with a noise floor visually sitting at approximately −130 dBm, dragging the scale upward causes the noise floor indicator to drift toward the top of the display while the scale labels read as high as −100 dBm — implying the noise floor has risen ~30 dB when it has not.
A second symptom is visible when the spectrum trace is near the bottom of the display window: signal variation appears asymmetric, with excursions in the positive direction (upward) being noticeably larger than excursions in the negative direction (downward). As the scale is dragged upward and the trace moves toward the middle or upper portion of the display, this asymmetry reduces and the spectrum begins to behave more symmetrically, as expected.
SmartSDR (SSDR) does not exhibit either of these behaviors — its spectrum behaves like a conventional spectrum analyzer where the scale and the trace remain tightly coupled during amplitude range adjustments.
What did you expect?
Dragging the amplitude scale should uniformly re-map the dB-per-pixel axis without shifting the apparent power level of any signal or the noise floor. The noise floor should remain at its true dBm value (e.g. −130 dBm) regardless of the vertical scale position or zoom level. Signal variation (FFT frame-to-frame noise) should appear symmetric around the mean noise floor at all scale positions and vertical positions within the display.
Steps to reproduce
Connect to a FLEX-6600 running firmware 4.2.18.41174.
Open the spectrum/panadapter display and observe the noise floor — note the approximate dBm reading (e.g. −130 dBm).
On the right-hand amplitude scale, click and drag upward to shift the displayed dBm range.
Observe that as the scale is dragged, the noise floor trace moves upward at a different rate than the scale markings — the noise floor eventually reads ~−100 dBm on the scale even though no RF conditions have changed.
Before dragging (trace near bottom of display), observe that frame-to-frame fluctuations in the noise floor appear asymmetric — more positive (upward) variation than negative (downward).
After dragging the scale so the trace is near the middle or top of the display, observe that the same fluctuations appear more symmetric.
Compare the same band/conditions in SmartSDR — note that the noise floor remains anchored to its true dBm value regardless of scale dragging, and variation is symmetric throughout.
Radio model & firmware
Radio: FLEX-6600
Firmware: 4.2.18.41174
OS & version
OS: Windows 11
AetherSDR version: 0.9.5.1
Qt version: 6.7.3
Developer Notes
Relevant source files and functions:
The bug most likely originates in src/gui/SpectrumWidget — specifically the functions responsible for:
FFT bin → pixel Y-coordinate mapping — The CLAUDE.md documents the bin-to-dBm conversion as:
dBm = min_dbm + (sample / 65535.0) × (max_dbm − min_dbm)
where min_dbm / max_dbm come from display pan status messages. The conversion produces a linear floating-point dBm value per bin. The subsequent step that maps this dBm value to a pixel Y-position within the widget must account for the current displayed dBm range (the draggable scale). If the pixel-mapping function applies any non-linear transform (e.g. a log or power function on the already-linear dBm value, or integer truncation before the range normalization), this would produce the observed asymmetric clipping near the bottom of the display and apparent level drift when the scale is moved.
Scale drag handler — The function that handles mouse drag on the right-side amplitude axis. If this handler modifies min_dbm / max_dbm state that is also used in the bin conversion formula (rather than only affecting the display viewport mapping), it would cause the displayed noise floor to move in dBm space rather than just in pixel space — explaining the scale/trace rate mismatch.
Exponential smoothing — CLAUDE.md notes that the FFT display uses exponential smoothing with α=0.35 (SpectrumWidget). If smoothing is applied to pixel Y-values rather than to the underlying dBm values, the effective smoothing range would be asymmetric near the bottom of the widget (pixel values cannot go below 0, so the distribution is clipped/skewed downward), explaining the asymmetric variation observed when the trace is near the bottom of the display.
Likely root causes to investigate:
Smoothing domain: Check whether the α=0.35 exponential moving average is applied to raw dBm values or to computed pixel Y-coordinates. It must be applied in dBm space before pixel mapping; applying it in pixel space introduces the observed floor-proximity asymmetry.
Scale drag vs. display range vs. conversion range: Verify that the amplitude scale drag updates only the display viewport (the Y-axis rendering range) and does not write back into min_dbm/max_dbm fields used by the VITA-49 bin conversion. These should be independent: min_dbm/max_dbm are radio-reported calibration constants; the displayed dBm window is a GUI-only view parameter.
Integer/float precision: Check for any int cast of dBm or pixel values before the range normalization step. Truncation before division would introduce systematic positive bias.
Logging to enable (Help → Support):
Enable the following diagnostic logging categories to capture useful data:
Panadapter / FFT — to log raw min_dbm, max_dbm values from display pan status messages and confirm they are stable during scale dragging.
VITA-49 / Stream — to confirm raw uint16 bin samples are arriving correctly and that PanadapterStream::FrameAssembler is not introducing artifacts.
GUI / Spectrum — if present, to log the computed dBm values and pixel Y coordinates per frame.
A useful diagnostic is to log 10–20 consecutive noise-floor dBm values (post-conversion, pre-smoothing) at two scale positions (trace at bottom vs. trace at middle) to confirm whether the asymmetry exists in the dBm domain or only appears after pixel mapping/smoothing.
Reference: SmartSDR (C#/Windows) does not exhibit this behavior, suggesting the FFT bin conversion itself is correct and the issue is in AetherSDR's display-layer mapping or smoothing pipeline in src/gui/SpectrumWidget.