support-bundle-20260617-190053.zip

What happened?

While connected to a FLEX-8400 (fw 4.2.20.41343) on AetherSDR 26.6.3 (Windows, Qt 6.8.3), the waterfall scrolls at a visibly different speed during TX than during RX — the two states do not match.

This is notable because it's the same symptom class as a previously-fixed bug: in the v0.9.x era, the TX-derived waterfall row path was throttled to a fixed line_duration cadence (~10 rows/sec) while RX native tiles arrived at the full FFT rate (~30 rows/sec), making TX appear roughly 3× slower than RX. That was fixed by dropping the row throttle and emitting one row per FFT frame. The v26.5.3 release also explicitly listed "TX waterfall scroll rate" as part of its spectrum reliability sweep. Given that, seeing RX/TX speed mismatch again on 26.6.3 looks like either a regression of one of those fixes, or a new code path with the same class of bug.

What did you expect?

The waterfall to scroll at the same cadence in both RX and TX — driven by the same underlying FFT frame rate — with no perceptible slowdown or speed-up when transmitting.

Steps to reproduce

1. Launch AetherSDR 26.6.3 on Windows and connect to a FLEX-8400 running firmware 4.2.20.41343.
2. Open a panadapter/waterfall for an active slice and observe scroll speed during normal reception.
3. Key the transmitter (PTT/MOX, voice or CW) and observe the waterfall scroll speed while transmitting.
4. Compare the two — TX scrolls at a noticeably different rate than RX.

Radio model & firmware

FLEX-8400, firmware 4.2.20.41343

OS & version

Windows, AetherSDR 26.6.3, Qt 6.8.3

Developer Notes

Likely-involved files/areas (inferred from the documented architecture and release history, not a direct line-by-line source read — treat as starting points):

• src/gui/SpectrumWidget — owns the waterfall row-push/render logic (QRhiWidget GPU path). This is exactly where the original line_duration-based throttle lived before it was removed in favor of one row per FFT frame — check whether a similar throttle (or a new per-stream-type delay) has been reintroduced on the TX-derived path specifically.
• src/core/PanadapterStream — VITA-49 routing by stream ID (FFT pan 0x40xx, waterfall 0x42xx). If TX-monitor waterfall data arrives via a distinct code path from RX native tiles (rather than a unified one), any rate difference between those two ingestion paths would reproduce this exact symptom.
• RadioModel / interlock (isTransmitting()) — worth checking whether the FFT frame rate or row-emission timer itself changes value when TX state flips (e.g., a reduced rate intentionally requested from the radio during TX that isn't being reverted correctly, or two different timers driving RX vs TX rows).
• Worth a git-blame / diff check around the PR that closed the original 3×-slower issue and around whatever landed the v26.5.3 "TX waterfall scroll rate" fix, to see if a later commit reintroduced a throttle on one side only.

Suggested diagnostic capture (Help → Support → File an Issue):

• Enable logging categories covering spectrum/waterfall rendering and VITA-49/panadapter stream parsing (exact category names weren't available to me without the live source tree — enable anything listed under "spectrum," "panadapter," or "vita49").
• Reproduce with the footer FPS readout visible (added in v26.5.1) and record the actual FPS value during RX vs during TX — this turns "looks different" into a hard number (e.g., RX ~30 fps vs TX ~10 fps) and will immediately tell the maintainers whether this is the same 3:1 ratio as the original bug or something new.
• Attach the resulting support bundle/log file as the in-app tool recommends.

Root cause hypotheses:

1. A throttle/delay was reintroduced on the TX-derived waterfall row path (regression of the original [waterfall] Stabilize TX waterfall rendering across slices #3019-area fix).
2. The v26.5.3 fix addressed a different aspect of TX waterfall reliability and didn't fully unify the cadence with RX in all configurations (e.g., works for the primary slice/pan but not for others, or only under certain bandwidth/zoom settings).
3. A radio-side firmware behavior on 4.2.20.41343 sends VITA-49 waterfall packets at a different rate during TX than during RX, and the client isn't compensating/normalizing for it (worth a Wireshark/VITA-49 capture to rule the radio in or out).