SPE floating LCD mirror appears and disappears in seconds-long cycles on a ser2net telnet link (v26.9.2)

[opalito]

Describe the bug
On v26.9.2, the SPE Expert applet's floating LCD mirror (merged in #5393) visibly appears and disappears in cycles of a few seconds on a real 1.5K-FA reached over a ser2net telnet link: the mirror shows the live screen for ~5–10 s, then blanks to the idle "waiting for display…" glass with the FRONT PANEL keys disabled for a couple of seconds, then comes back — repeating indefinitely. Status telemetry (gauges, pill, readouts) stays live throughout; only the display channel drops.

To Reproduce

1. Connect the SPE applet to an SPE Expert via ser2net in telnet mode (accepter: telnet,<port>), amp on.
2. Pop the applet out to its floating presentation so the LCD mirror starts polling.
3. Leave it idle and watch: the mirror cycles between live and "waiting for display…" every handful of seconds. Captured on video against a real 1.5K-FA.

Expected behavior
The mirror stays continuously live, and an occasional lost display frame on a lossy proxy link reads as a hiccup at worst — not as the whole display blinking out of existence and the menu keys flapping.

Analysis (root cause)
Two compounding causes, both client-side — the amplifier behaves fine:

1. Harmonic phase-lock between the two poll loops. The LCD request free-runs at 600 ms — an exact multiple of the 100 ms Status poll. Two free-running QTimers with evenly-dividing periods phase-lock (Qt's coarse timers actively coalesce timeouts into shared wakeups), and when the locked phase lands where each 371-byte display reply straddles a status poll on the wire, display frames are corrupted/lost in consecutive bursts that persist until clock drift walks the alignment out — seconds later. Hence the cyclic pattern.
2. A freshness gate with no loss tolerance made the bursts maximally visible. Two missed refreshes (1.2 s) hard-clear the glass to the idle hint and disable the keys, so every burst becomes a full appear/disappear blink. (The pre-SPE applet: floating presentation with live LCD mirror and full front-panel keys #5393 validation builds never blanked the mirror at all, which is why hardware validation didn't catch it: the same frame losses were happening, but a lost frame just meant one late refresh.)

Environment

• AetherSDR v26.9.2 (Windows), SPE Expert 1.5K-FA, ser2net 4.3.11 accepter: telnet on a Debian host, LAN.

Fix direction (PR to follow from fix/spe-lcd-staleness-flicker)

• Re-arm the LCD cadence from each display reply instead of free-running — the amp's variable response latency folds into the period, so no stable phase relationship with the status poll can form. This also makes the interval an idle gap, never queuing a second request before the previous reply fully arrived, which lets the gap drop to 250 ms for a visibly smoother mirror while degrading gracefully on slow proxy serial sides.
• Absolute 1.8 s staleness window (covers a lost frame plus retry even at 9600 baud) instead of two missed periods.
• On staleness, dim the last image in place instead of blanking; the keys still gate on freshness exactly as before, and hard clears remain where the image is truly obsolete (disconnect, presentation switch).

73 de Miguel, EC5W

[aethersdr-agent]

Triaged — confirmed against the tree. Both causes in the report are real and both are in code that shipped in v26.9.2 (bc801774, #5393, which git tag --contains puts inside v26.9.2). Labelled maintainer-review.

Root cause

1. The LCD cadence is re-armed at send time, not reply time — and 600 ms is an exact 6× of the status poll.

src/core/SpeConnection.cpp:75-84:

void SpeConnection::requestLcdFrame()
{
    if (!m_lcdWanted || !m_connected) { return; }
    sendRaw(Spe::Lcd::buildRequest());
    m_lcdTimer.start();   // re-armed on SEND
}

with kLcdPollIntervalMs = 600 and kPollIntervalMs = 100 (SpeConnection.h:169,178). Because the re-arm happens at send, the request cadence is a clean 600 ms send-to-send with no amp-latency jitter folded in, so it holds a fixed phase against the free-running 100 ms m_pollTimer. Neither timer sets a timer type, so both are Qt::CoarseTimer (Qt's default for intervals ≥ 20 ms), which actively coalesces near-coincident timeouts into shared wakeups — that pulls the two into alignment rather than letting them drift apart.

The amplifier is a single-threaded serial device. When the locked phase puts a status request on the wire in the middle of the amp's 371-byte display reply (Lcd::kFrameLength, ~32 ms of wire time at 115200 and much longer on a slow ser2net serial side), the reply gets truncated or has status bytes spliced into it. FrameParser::feed then fails isValidDisplayFrame's 16-bit payload checksum (SpeProtocol.cpp:55-71) and falls through to resyncToNextSync() (SpeProtocol.cpp:204) — the frame is silently dropped. Because the phase is stable, this repeats on consecutive polls until crystal drift walks the alignment out. That is exactly the seconds-long cycle in the video. Status telemetry stays live throughout because the collision only costs the display frame; the next 100 ms status poll succeeds normally.

Note the only thing that currently perturbs the phase is the ACK-triggered requestLcdFrame() at SpeConnection.cpp:365 — i.e. pressing a key. That's why this reproduces specifically when the applet is left idle.

2. The freshness gate has zero loss tolerance and hard-clears.

kLcdStaleTimeoutMs = kLcdPollIntervalMs * 2 (SpeConnection.h:179), and m_lcdStaleTimer is restarted only inside the display callback on a successful decode (SpeConnection.cpp:20-24). So two lost frames → setLcdFresh(false) → SpeApplet::setLcdFresh (src/gui/SpeApplet.cpp:395-402) calls m_lcd->clear(), which drops m_hasFrame (SpeLcdWidget.cpp:61-70) and repaints the "waiting for display…" glass (SpeLcdWidget.cpp:132-138), plus updateCommandsEnabled() gates the FRONT PANEL keys off via m_lcdFresh (SpeApplet.cpp:646). Recovery then needs a full fresh frame, so the blink is total in both directions. The report's explanation for why hardware validation missed it is right: the pre-#5393 builds had no blanking path, so the same frame losses only ever showed as one late refresh.

Proposed fix

The direction in the report is sound and correctly scoped client-side (the amp is behaving):

• src/core/SpeConnection.cpp / .h — re-arm m_lcdTimer from the display reply (in the setDisplayCallback lambda) instead of inside requestLcdFrame(), and make it single-shot. The amp's variable response latency then folds into the period, so no stable phase relationship with the 100 ms status poll can form; losses become uncorrelated hiccups instead of bursts. This also makes the interval an idle gap — never a second request queued before the previous reply has fully arrived — which is what makes it safe to shorten to 250 ms while still degrading gracefully on a slow proxy serial side. Needs a fallback re-arm on the timeout path too, otherwise a single lost reply stops the poll loop permanently (that path doesn't exist today because the timer free-runs).
• SpeConnection.h — replace kLcdStaleTimeoutMs = kLcdPollIntervalMs * 2 with an absolute window (~1.8 s) so it stays a real-time budget independent of the gap constant.
• src/gui/SpeApplet.cpp / SpeLcdWidget — on staleness, dim the last image in place rather than clear()ing it; keep the key gating on m_lcdFresh exactly as-is, and keep the hard clear where the image is genuinely obsolete (setConnected(false) / clearTelemetry() at SpeApplet.cpp:656, and the presentation switch at setFloating SpeApplet.cpp:383).

For the maintainer — two things worth a decision at review

1. Reply-driven scheduling decorrelates the collision; it does not eliminate it. Dropping the gap 600 → 250 ms raises display traffic ~2.4× and therefore raises the per-status-poll collision probability, even though no burst can form. The combination with dim-instead-blank still gets you the "hiccup at worst" behaviour asked for, but if you want the collision actually removed, the complementary change is to have pollTick() skip a status request while a display reply is outstanding. That touches the silence detector (m_statusSeenSinceTick / m_silentPolls, SpeConnection.cpp:333-352), so a skipped tick must not count as a silent poll — worth deciding before implementation rather than after.
2. Test coverage. tests/spe_protocol_test.cpp covers frame/checksum/IAC decoding but nothing about cadence. The re-arm change is the kind of thing that regresses invisibly; a QSignalSpy-style test that a lost reply still re-arms the request loop, and that staleness no longer drops m_hasFrame, would be cheap.

Happy to implement once aetherclaude-eligible is added.

---

_{🤖 aethersdr-agent · cost: $1.4234 · model: claude-opus-5}

---

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

Unresolved citations (12)

Citation	Reason
SpeApplet.cpp:383	file not found in workspace
SpeApplet.cpp:646	file not found in workspace
SpeApplet.cpp:656	file not found in workspace
SpeConnection.cpp:20-24	file not found in workspace
SpeConnection.cpp:333-352	file not found in workspace
SpeConnection.cpp:365	file not found in workspace
SpeConnection.h:169	file not found in workspace
SpeConnection.h:179	file not found in workspace
SpeLcdWidget.cpp:132-138	file not found in workspace
SpeLcdWidget.cpp:61-70	file not found in workspace
SpeProtocol.cpp:204	file not found in workspace
SpeProtocol.cpp:55-71	file not found in workspace

[aethersdr-agent]

Antares Detector — candidate vulnerable file(s)

• src/core/SpeProtocol.cpp
• src/gui/SpeLcdWidget.h

The SPE protocol parser reads AM radio sync marker bytes and expands a QByteArray up to Lcd::kFrameLength without validating the incoming buffer length, allowing malformed or oversized packets to trigger out-of-bounds memory expansion (CWE-190). The same FrameParser trusts frame lengths from network input. The SpeConnection header references this implementation but does not itself validate packet sizes before feeding bytes into parsers.

_{Localized by Cisco Foundation AI Antares-1B running locally in the AetherClaude sandbox, seeded by the Cartographer security map. Advisory only — please verify before acting.}

---

_{🤖 aethersdr-agent · cost: $1.5803 · model: claude-opus-5}