Noise floor trace?

[Bill6000]

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?

I have noticed the noise floor _ signal trace in the panadaptor resolution to have changed. If I set the trace to it's thinnest setting, it is pixelated and not as smooth as it has been.

What did you expect?

The noise floor trace should be smoother. It is very easy to notice on signals.

Steps to reproduce

start Aether
Look at the signal trace

AetherSDR version

v26.6.3

Radio model & firmware

Flex 6500

Operating system

Linux

OS version and hardware

Linux Mint

[aethersdr-agent]

Triage: confirmed cosmetic regression in the software (QPainter) spectrum path

Root cause — integer-quantized trace vertices on the non-GPU render path.

On Linux this widget runs the software QPainter path, not the GPU one. GPU spectrum rendering requires Qt 6.7+ (CMakeLists.txt:276, AETHER_GPU_SPECTRUM is forced OFF below that), and our Linux builds are on the Qt 6.4.2 floor — so on Linux Mint v26.6.3 you are always rendering through SpectrumWidget::drawSpectrum().

In that path the trace geometry is computed as integers:

// src/gui/SpectrumWidget.cpp:6913-6921
struct Pt { int x, y; float t; };
...
pts[i].x = r.left() + static_cast<int>(static_cast<float>(i) / n * w);
pts[i].y = r.top()  + qMin(static_cast<int>(norm * h), h - 1);   // <-- snapped to whole pixels

The Y coordinate is truncated to a whole pixel row, so every trace vertex sits on the integer grid. Antialiasing is enabled (:6923), but AA can only smooth sub-pixel geometry — when the vertices themselves are integer-snapped, a near-flat noise floor steps abruptly between adjacent pixel rows, giving the stair-stepped / pixelated look. The GPU path doesn't have this problem because it builds the same trace with float positions (struct Pt { float x, y; }; at :6163).

Why it "changed." Before #2722 (commit 4d5b4d7a, "Honor FFT Line slider on QPainter render path"), the software path drew the trace with a fixed QPen(m_fftFillColor, 1.5). A 1.5px pen plus AA visually masked the integer stair-stepping. That PR switched to a cosmetic pen that honors the line-width slider down to sub-pixel widths:

// :6929-6931
QPen linePen;
linePen.setCosmetic(true);
linePen.setWidthF(m_fftLineWidth);   // slider min is now <1px

At the thinnest setting there is no pen width left to hide the underlying integer-grid steps — so the long-standing quantization that was previously masked is now exposed. That matches your report exactly: smooth before, pixelated at the thinnest setting now.

---

Proposed fix

In SpectrumWidget::drawSpectrum() (src/gui/SpectrumWidget.cpp), make the trace geometry sub-pixel like the GPU path:

1. Change struct Pt { int x, y; float t; } → struct Pt { float x, y; float t; } and drop the static_cast<int> truncation when computing pts[i].x / pts[i].y (keep the <= h-1 clamp as a float qMin(norm * h, static_cast<float>(h - 1))).
2. Build the polyline/heat-map segments and the fill path with QPointF instead of integer int x, y, so drawPath / drawLine receive float coordinates and AA can render a smooth sub-pixel trace.

This is local to one function, mirrors logic the GPU path already proves correct, and should not affect the GPU build at all.

Handoff

• Known: software path only (Linux/Qt<6.7); integer vertex quantization in drawSpectrum; regression surfaced by FFT line slider has no effect on Windows 11 #2722's thin cosmetic pen.
• Fix: int→float trace vertices + QPointF drawing in drawSpectrum (SpectrumWidget.cpp:6913-6994).
• Scope: small, self-contained, good first issue. No protocol/firmware involvement.

Flagging for maintainer review before implementation.

---

_{🤖 aethersdr-agent · cost: $2.4151 · model: claude-opus-4-8}

---

_{📍 Citation health check (Foundry Constitution Principle I): 2 resolved, 1 unresolved against /Users/aetherclaude/workspace/AetherSDR at origin/main.}

Unresolved citations (1)

Citation	Reason
SpectrumWidget.cpp:6913-6994	file not found in workspace