What happened?

The transmit (TX) waterfall refresh/update rate is not synchronized with the receive (RX) waterfall rate.

During operation, the RX waterfall scrolls and updates at a normal/smooth rate, while the TX waterfall updates at a visibly different speed. The TX waterfall appears to refresh either slower or with inconsistent timing compared to RX, resulting in an obvious visual mismatch between receive and transmit spectral display behavior.

This creates inconsistent UI behavior and makes TX monitoring less intuitive, especially when observing transmitted modulation characteristics, tuning signals, CW shaping, or digital mode activity.

The issue was observed using a FLEX-8400 running SmartSDR/Flex firmware 4.1.3.39644 on Windows with AetherSDR 26.5.1 (Qt 6.8.3).

What did you expect?

The TX waterfall should use the same (or synchronized) frame/update rate as the RX waterfall so that both displays scroll smoothly and consistently.

Expected behavior:

RX and TX waterfalls should update using identical or harmonized timing
TX waterfall speed should visually match RX waterfall speed
Waterfall scroll timing should remain stable when switching between RX and TX
No visible lag, throttling, or inconsistent frame pacing between RX/TX display pipelines
Steps to reproduce
Start AetherSDR
Connect to a FLEX-8400 running firmware 4.1.3.39644
Open a panadapter/waterfall
Begin transmitting (CW, SSB, or digital mode)
Observe the TX waterfall behavior compared to the RX waterfall
Notice that the TX waterfall refresh/scroll rate differs from the RX waterfall rate
Radio model & firmware
Radio: FLEX-8400
Firmware: 4.1.3.39644
OS & version
OS: Windows
AetherSDR version: 26.5.1
Qt version: 6.8.3
Developer Notes

This issue appears likely related to separate timing/render scheduling between RX and TX waterfall pipelines.

Potential areas to inspect:

Waterfall rendering timer cadence
TX FFT frame scheduling
Separate RX/TX throttling logic
UI repaint synchronization
Different buffering or decimation rates between RX and TX spectral sources

Likely relevant source areas based on project architecture:

src/gui/panadapter/
src/gui/waterfall/
src/radio/flex/
src/dsp/fft/
src/rendering/

Potential classes/functions to inspect:

RX/TX spectrum frame producers
Waterfall line enqueue/dequeue timing
QTimer/QElapsedTimer driven repaint logic
OpenGL/QRhi frame pacing
TX-specific FFT generation path
Any independent FPS limiting for TX visualization

Particular attention should be paid to:

Separate timer intervals for RX vs TX waterfall updates
Different FFT accumulation windows
Thread affinity differences between RX and TX processing
UI-side frame dropping under TX load
Conditional throttling during transmit state transitions

Recommended diagnostic logging to enable from:

Help → Support

Suggested categories:

Waterfall
Rendering
FFT
Panadapter
Radio/Protocol
Performance/Timing
GPU/OpenGL/QRhi

Useful diagnostics to capture:

RX waterfall FPS
TX waterfall FPS
FFT production intervals
UI repaint intervals
Queue depth/backpressure during TX
TX state transition timing
GPU render timing and skipped frames

Potential root causes:

TX waterfall using a different refresh timer than RX
TX FFT stream produced at a different cadence
TX rendering path unintentionally rate-limited
UI thread contention during TX state changes
Separate buffering logic between RX and TX waterfall pipelines
TX spectral frames being decimated or dropped before rendering
Frame pacing mismatch introduced by Qt 6.8 rendering backend on Windows

The issue appears cosmetic/UI-timing related, but it affects usability and accurate visual interpretation of transmitted signals.