Report preparation
What happened?
When adjusting the vertical scale (offset/range) of the spectrum/waterfall display, the noise floor level changes in absolute dBm terms. For example, with the noise floor at the bottom of the scale it reads approximately -110 dBm, but moving the scale up causes it to read approximately -70 dBm. The spectral line position changes with the scale setting, which should not happen — the absolute level should remain constant.
What did you expect?
Adjusting the vertical display scale should only change the viewport (which portion of the dBm range is visible), like zooming in/out of a fixed reference. The noise floor and all signals should retain their true dBm values regardless of scale position.
Steps to reproduce
- Connect to a radio with an antenna attached (or terminated)
- Note the noise floor level on the spectrum display at default scale settings
- Move the vertical scale up (using the arrow buttons or dragging the dBm strip)
- Observe that the noise floor now reads at a different absolute level
AetherSDR version
(please fill in)
Radio model & firmware
FLEX-8600, firmware 4.1.5
Operating system
Linux
OS version and hardware
(please fill in)
Technical analysis
The root cause is in the interaction between PanadapterStream::decodeFFT() and SpectrumWidget's display window controls.
PanadapterStream::decodeFFT() (src/core/PanadapterStream.cpp:727) converts raw pixel Y positions from the radio to dBm using a per-stream minDbm/maxDbm range:
bins[i] = maxDbm - (frame.buf[i] / (yPix - 1.0f)) * (maxDbm - minDbm)
When the user adjusts the vertical scale, SpectrumWidget emits dbmRangeChangeRequested, which sends display pan set min_dbm/ max_dbm to the radio. The radio echoes these back, and RadioModel::handlePanStatus() (RadioModel.cpp:3782-3788) feeds the new min/max into both the display window and the FFT decode range:
if (kvs.contains("min_dbm") || kvs.contains("max_dbm")) {
m_panStream->setDbmRange(pan->panStreamId(), minDbm, maxDbm); // changes decode
emit panadapterLevelChanged(minDbm, maxDbm); // changes display
}
The display range (a viewport preference) overwrites the decode range, causing subsequent FFT frames to be decoded with wrong absolute dBm values.
Proposed fix: Remove the m_panStream->setDbmRange() call from the radio echo path. The decode range should remain fixed at the radio's initial values (or track actual hardware changes like rfgain/pre). The SpectrumWidget's m_refLevel/m_dynamicRange independently handle viewport changes via setDbmRange(), so the display still works correctly.
Report preparation
What happened?
When adjusting the vertical scale (offset/range) of the spectrum/waterfall display, the noise floor level changes in absolute dBm terms. For example, with the noise floor at the bottom of the scale it reads approximately -110 dBm, but moving the scale up causes it to read approximately -70 dBm. The spectral line position changes with the scale setting, which should not happen — the absolute level should remain constant.
What did you expect?
Adjusting the vertical display scale should only change the viewport (which portion of the dBm range is visible), like zooming in/out of a fixed reference. The noise floor and all signals should retain their true dBm values regardless of scale position.
Steps to reproduce
AetherSDR version
(please fill in)
Radio model & firmware
FLEX-8600, firmware 4.1.5
Operating system
Linux
OS version and hardware
(please fill in)
Technical analysis
The root cause is in the interaction between PanadapterStream::decodeFFT() and SpectrumWidget's display window controls.
PanadapterStream::decodeFFT() (src/core/PanadapterStream.cpp:727) converts raw pixel Y positions from the radio to dBm using a per-stream minDbm/maxDbm range:
When the user adjusts the vertical scale, SpectrumWidget emits dbmRangeChangeRequested, which sends display pan set min_dbm/ max_dbm to the radio. The radio echoes these back, and RadioModel::handlePanStatus() (RadioModel.cpp:3782-3788) feeds the new min/max into both the display window and the FFT decode range:
The display range (a viewport preference) overwrites the decode range, causing subsequent FFT frames to be decoded with wrong absolute dBm values.
Proposed fix: Remove the m_panStream->setDbmRange() call from the radio echo path. The decode range should remain fixed at the radio's initial values (or track actual hardware changes like rfgain/pre). The SpectrumWidget's m_refLevel/m_dynamicRange independently handle viewport changes via setDbmRange(), so the display still works correctly.