MEM button paints optimistically while the model waits for the radio echo

[Ozy311]

Summary

The MEM button in the TX applet is a checkable QPushButton, so Qt paints it checked the
instant it is clicked, while the model waits for the radio to echo the change back. If
that echo never arrives, MEM reads lit while memoriesEnabled() is still false.

src/gui/TxApplet.cpp:447-450:

connect(m_memBtn, &QPushButton::toggled, this, [this](bool on) {
    if (!m_updatingFromModel && m_model)
        m_model->setAtuMemories(on);
});

TransmitModel::setAtuMemories() (:440) only emits atu set memories_enabled=N and
latches nothing, which is correct under Principle II. The one thing that re-syncs the
button is syncAtuIndicators() (:679-684), and that runs on atuStateChanged(), i.e.
only when the radio actually reports back.

Why it matters

This is the same optimistic-paint shape #5292 corrected for the sibling ATU button. Its
summary says so directly:

Makes ATU checked state authoritative from model readback rather than the button's
optimistic click toggle.

That change landed for ATU and left MEM as it was.

The practical consequence showed up in #5510: the natural diagnostic question is "is the
MEM button lit?", and on a radio that does not echo, the answer is a misleading yes. The
operator sees a lit MEM and a dead Pre-tune entry, which is unexplainable from the UI.

Status

Latent, not currently biting. Verified on a FLEX-6700 running 26.9.2: the radio
echoes atu status both on sub atu all and on change, so the button and the model
agree there. It would bite on any radio or firmware that does not echo.

Filing it because it is cheap to fix, there is an in-repo precedent to copy, and its
main cost today is making a diagnostic question untrustworthy.

---

73, Ozy K6OZY - model: claude-opus-5

[aethersdr-agent]

Confirmed the defect by reading the code, with two corrections to the framing — one that makes it less latent than filed, and one about the cited precedent.

The core report is accurate

src/gui/TxApplet.cpp:309-311 makes MEM a checkable QPushButton, so QAbstractButton flips checked itself on click and repaints before the handler at :447-450 runs. That handler only forwards:

connect(m_memBtn, &QPushButton::toggled, this, [this](bool on) {
    if (!m_updatingFromModel && m_model)
        m_model->setAtuMemories(on);
});

TransmitModel::setAtuMemories() (src/models/TransmitModel.cpp:440-442) emits atu set memories_enabled=N and latches nothing — correct under Principle II. The only writer of m_memoriesEnabled is the status path (TransmitModel.cpp:175), and the only re-sync of the button is syncAtuIndicators() (TxApplet.cpp:679-684), wired to atuStateChanged at :509. No echo, no correction. So the button's paint and memoriesEnabled() can disagree indefinitely.

FlexLib agrees on the wire shape: Radio.cs:11024 sends the identical command, and :11118-11128 parses memories_enabled out of atu status. (FlexLib does latch locally at :11023 before sending — that's exactly the optimistic behavior our Principle II declines, which is why we need the readback discipline on the paint side instead.)

It is reachable today, not only on non-echoing firmware

RadioModel.cpp:4292 deliberately restores the capability when disconnected:

m_transmitModel.setHasTunerMemories(!connected || caps.hasTunerMemories);

so updateAtuAvailability() (TxApplet.cpp:561-566) leaves MEM enabled with no radio connected. Click it there and it lights permanently — no radio, no atu status, no atuStateChanged.

Worse, TransmitModel::resetState() (TransmitModel.cpp:13-37) clears m_memoriesEnabled = false at :27 but emits only apdStateChanged, transmittingChanged, moxChanged, tuneChanged, micStateChanged — not atuStateChanged. So a MEM button that was legitimately lit on a connected Flex stays lit across disconnect while the model has already gone false.

Both paths produce precisely the #5510 symptom: lit MEM, and "Pre-tune bands…" greyed with "Enable MEM before running the pre-tune sweep", since showAtuContextMenu() (:787) and openPreTuneDialog() (:842) both gate on memoriesEnabled(). On a live FLEX-6700 the echo papers over it, which matches your 26.9.2 observation.

Correction on the #5292 precedent

There is no ATU-button code to copy. m_atuBtn is not checkable — it's wired to clicked (:434) and has no setChecked() call anywhere in the file. Reading the diff of 13a315f, the only MEM/ATU button change in TxApplet.cpp was the comment above the existing sync block:

-    // MEM button — sync checked state
+    // ATU / MEM buttons — active styling follows radio readback only.

The PR bullet "Makes ATU checked state authoritative from model readback rather than the button's optimistic click toggle" refers to the indicator labels (Success/Byp/Mem via the new indicatorState() helper), not to a button toggle fix. So the precedent is a stated principle, not reusable code — worth knowing before someone goes looking for it.

Proposed fix

Single file, src/gui/TxApplet.cpp:

1. Replace the toggled connection at :447-450 with a clicked connection that immediately reverts the optimistic paint, leaving readback as the sole authority:

// MEM button — toggle ATU memories.  Checkable for appearance only; the
// checked state is authoritative from radio readback (syncAtuIndicators),
// never from the click.  Principle II: the model latches nothing, so we
// undo Qt's optimistic toggle and wait for the atu status echo.
connect(m_memBtn, &QPushButton::clicked, this, [this](bool on) {
    if (!m_model) return;
    {
        const QSignalBlocker blocker(m_memBtn);
        m_memBtn->setChecked(m_model->memoriesEnabled());
    }
    m_model->setAtuMemories(on);
});

2. Add emit atuStateChanged(); to TransmitModel::resetState() in src/models/TransmitModel.cpp so the button (and the Success/Byp/Mem indicators, which also read stale ATU state there) clear on disconnect.

Optional but consistent with RadioModel.cpp:4292's stated rationale: consider whether MEM should be clickable while disconnected at all. Leaving it enabled-but-inert is defensible under the "nothing to be honest about" comment; with fix (1) it at least no longer lies.

Coverage: tests/tx_applet_power_reconciliation_test.cpp is the existing applet-level harness — a case asserting m_memBtn->isChecked() == false after a click with no status echo, and false after resetState(), would pin both halves.

Handoff

Root cause identified and localized; fix is ~10 lines across two files with no protocol change. Reachable today via the disconnected-radio and disconnect-transition paths, so it's a real bug rather than purely latent hardening — though the user-visible cost is still confined to a misleading diagnostic surface, hence priority: low. Tagging good first issue.

---

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

---

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

Unresolved citations (5)

Citation	Reason
RadioModel.cpp:4292	file not found in workspace
TransmitModel.cpp:13-37	file not found in workspace
TransmitModel.cpp:175	file not found in workspace
TxApplet.cpp:561-566	file not found in workspace
TxApplet.cpp:679-684	file not found in workspace