Summary

This PR narrows the waterfall tile remapping introduced for transverter support so it only applies to real XVTR-style IF/RF translations. Normal HF panadapter scrolling now leaves the radio-provided waterfall tile range intact, even if the panadapter center has temporarily moved away from the latest tile center while the waterfall stream catches up.

In practical terms: the post-release black-waterfall regression reproduced by dragging/scrolling a panadapter roughly 0.500 MHz away from its starting point should stop happening, while the original XVTR protection from PR #1845 remains gated behind evidence that the pan is actually in a transverter path.

Root Cause

The regression was introduced by PR #1845 / commit 9bc1026 ("Fix waterfall always black when using transverter (XVTR) input").

That change solved an XVTR case by detecting when a waterfall tile's center frequency did not overlap the current panadapter center, then shifting the row's low / high range by the center delta. The assumption was that a large tile-vs-pan center mismatch meant the waterfall data was being reported in IF space while the panadapter was in RF space.

That assumption is valid for some XVTR paths, but it is too broad for ordinary HF panning.

During manual panadapter scrolling, especially with trackpad/drag movement, the client can move the pan center faster than fresh waterfall rows arrive from the radio. In the observed repro, the waterfall disappeared after about 0.500 MHz of movement, which lines up with one waterfall tile/span worth of stale data. The tile was not wrong XVTR data; it was ordinary waterfall data that had not yet caught up to the newly requested pan center.

Because PR #1845 treated any non-overlapping tile/pan center as an XVTR translation, it opportunistically rewrote the row frequency range on normal HF bands. That corrupted the waterfall geometry and made the display go blank until another action, such as zoom, forced the client/radio waterfall state back into alignment.

Investigation Notes

We initially suspected the newer panadapter recentering and margin policy because the symptom appeared while scrolling off the current pan view.

The local testing ruled that out:

• Reverting the centering refactor from PR [core] Unify recenter policy across tuning and pan/zoom workflows #1861 did not fix the issue.
• Reverting the follow-up margin adjustment commit 9e4ec0c did not fix the issue.
• Reverting the spectrum-click margin change from PR Reduce spectrum-click edge margin to stop unwanted pan jumps (#1906) #1907 / c6646d5 did not fix the issue.
• Reverting 9bc1026 did fix the issue.

That sequence isolated the regression to the waterfall tile reinterpretation logic from PR #1845, not the recentering policy.

What Changed

The waterfall row handler still detects the same "tile center and pan center do not overlap" situation, but it no longer shifts the tile range just because that condition is true.

It now requires XVTR evidence before applying the shift:

• The observed tile-to-pan center offset must match a configured transverter rfFreq - ifFreq offset within a tolerance based on the tile width, or
• A slice on the same panadapter must be using an XVT* antenna.

If neither condition is true, the row's original low / high frequency range is left unchanged.

Why This Shape

This keeps the original PR #1845 intent, which was to prevent waterfall rows from being invisible when the radio reports XVTR waterfall data in a translated coordinate space.

It also restores the safer default for normal bands: waterfall row coordinates come from the radio, and ordinary panning should wait for new rows rather than opportunistically re-center stale rows on the client side.

The important learning is that "tile and pan are far apart" is not enough information to infer "this is transverter IF/RF mismatch." It can also mean "the pan moved and waterfall data is one tile behind."

Non-Goals

This PR does not attempt to address the separate post-release investigations around hung slices or garbled AetherSDR audio when a SmartSDR Windows client connects. Those were part of the same troubleshooting window, but this branch only changes the isolated waterfall root cause.

Risk

The main risk is XVTR coverage: this fix intentionally keeps the tile shift for known transverter offsets and XVT* slice antennas, but unusual transverter configurations may need additional validation or a broader signal from the radio/client model.

Normal HF behavior should be lower risk because it returns to trusting the original waterfall row range unless there is specific XVTR evidence.

Validation

• Built successfully with cmake --build build --parallel 10.
• Local repro established that the black-waterfall symptom survived reverting the recenter/margin commits.
• Local repro established that reverting 9bc1026 removed the black-waterfall symptom.
• This patch applies the smallest targeted correction to the isolated root cause instead of reverting unrelated recentering work.

Manual validation still requested:

• Re-test the original HF panadapter scroll repro around the one-tile / ~0.500 MHz boundary.
• Re-test an actual XVTR panadapter, if available, to confirm PR Fix waterfall always black when using transverter (XVTR) input (#1843) #1845's intended behavior remains intact.

👨🏼‍💻 Generated with OpenAI Codex (GPT-5.5 Pro 4/23) and tested by @jensenpat