Claude here on Jeremy's behalf — wanted to share hardware test results before this lands.

To get a clean test, I cherry-picked just the spectrum-fix commit (74195f25) onto current main, dropping the already-merged commits (#2349 Spot Lines toggle and #2386 TCI crash fix) and the two unrelated spot-lines naming commits — should let us evaluate the spectrum fix in isolation. Built clean (m_decodeRangeInitialized and the "decode range locked" debug strings confirmed present in the binary), Jeremy tested on his FLEX-8600 fw 4.1.5.

Result: the symptom is unchanged. Dragging the amplitude scale by 10 dB still moves the noise floor reading by 10 dB, 1:1 — same drift the original reporters saw.

The mechanical implication, since the lock is verifiably in the binary:

• If the lock is being honored (which the debug log path says it is), then the decode range is staying at the initial radio-reported value while the radio's bin encoding is changing with the viewport.
• That means the radio does re-encode FFT bins when min_dbm/max_dbm changes — opposite of the PR's premise. Locking the decode then makes the decoder use a stale range vs. what the radio is sending, producing an offset that matches the viewport delta exactly. Which is what Jeremy observed.

So either:

1. The radio re-encodes on viewport change. In that case the original behavior (decode follows viewport) was correct, and the 30-40 dBm drift LU5DX and rnash2 reported has a different root cause. Maybe a math/units error in the decode formula in decodePanadapterTile, an off-by-one (yPix - 1 vs yPix), or a byte interpretation issue (signed vs unsigned, big- vs little-endian). Worth double-checking against a Wireshark capture of a known-amplitude signal.

2. The radio doesn't re-encode (PR's premise), but our display path is doing the bin → screen mapping using viewport-relative math somewhere that we'd want to leave viewport-relative. In that case the lock is correct in concept but a parallel path is still drifting.

Either way the lock alone doesn't close out #2384/#2310 in practice — at least on the FLEX-8600 setup Jeremy's testing against. Would be useful to know what radio model the original reporters tested on; if Aurora vs. 6000 vs. 8000 series differ in their encoding behavior, that'd narrow it down.

The two spot-lines naming commits on this branch (b3d5cb84, 6b0f38be) look like fine cleanup, and address triage feedback you got on #2349. Worth opening as their own PR titled around "fix(spots): align Spot Lines naming with project conventions" — they'd merge cleanly on current main.

Holding the cherry-pick for now (reverted locally) until we have a clearer picture of which of the two cases above is in play. Happy to help dig if you want a Wireshark capture from Jeremy's test bench, or pair on the decode formula vs. FlexLib's Panadapter::ProcessFFTPacket.

73, Jeremy KK7GWY & Claude (AI dev partner)

Thanks for the hardware test results — that's a clear outcome.

Dug into FlexLib (Panadapter.cs) to settle the re-encoding question. The design is unambiguous:

• AddData fires raw ushort[] bins with no dBm conversion — the consumer applies LowDbm/HighDbm at render time
• When the user sets LowDbm/HighDbm, FlexLib updates the local value immediately before sending the command — SetLowDbmReply returns early on success because the value was already applied
• The model is fully optimistic: local range updates instantly, radio re-encodes, UI renders with the current range

The radio re-encodes on viewport change. The lock forces the decoder to use a stale range against freshly re-encoded bins, producing the exact 1:1 offset Jeremy observed. The lock needs to come out.

Also looked at SpectrumWidget's render path — it cleanly maps absolute dBm values to screen Y using m_refLevel/m_dynamicRange. No double application of the range there.

That leaves the actual cause of #2384 still open. The most likely remaining candidate is a sync issue: PanadapterStream's decode range and SpectrumWidget's display range both need to track the radio's current encoding range in lockstep. If they diverge — for example if the decode range update from the status echo is delayed or arrives with different values than what AetherSDR sent — you'd get a permanent offset. The diagnostic logging approach outlined above would pin down whether that's happening.

Will rebase the branch to drop the lock change.