Flex claims hasTunerMemories for every model with no per-model evidence (Aurora AU-510)

[Ozy311]

Summary

FlexBackend::capabilities() sets caps.hasTunerMemories = true unconditionally for
every Flex radio (src/core/backends/flex/FlexBackend.cpp:178), with no per-model
evidence. This is the same family-wide over-claim that #5292 was written to correct on
the Icom side, and it was left in place on the Flex side.

#5292's own root-cause text:

The Icom backend also advertised tuner support family-wide even though the supported
CI-V path is model-specific.

Why this is not theoretical

#5510 was reported against an AU-510, which is Aurora class rather than 6000 series
(the codebase knows the model: SmartCatProtocol.cpp:555 maps AU-510 to ID930, and
the comment at :538 reads 930=AU-510/M; the reporter's log shows
max_internal_pa_power=500 and apd predistortion status, both Aurora-class surfaces).

The capability drives real UI. With hasTunerMemories true, the ATU right-click menu is
installed and the MEM button is enabled. If an Aurora has no ATU memory database, then:

• the operator gets a menu offering an operation the radio cannot perform,
• MEM can never latch, so Pre-tune is permanently unavailable rather than "turn MEM on",
• and after fix(gui): explain why ATU Pre-tune is disabled (#5510) #5539 the tooltip will actively instruct them to "Enable MEM before running
  the pre-tune sweep", which on that radio would be advice that can never work.

That last one is the reason I am raising it now rather than sitting on it: #5539 turns a
silent dead end into a confident wrong instruction if the capability claim is wrong.

What I cannot answer

Whether Aurora actually supports the ATU memory database. I have no Aurora to test
against, and I am not going to infer it from the shape of the code. This needs either
protocol authority or a reporter with the hardware.

If Flex genuinely supports memories on every model, this issue is a no-op and can be
closed; the claim is then correct and just undocumented.

Related

• Unable to click "Pre-tune bands" #5510, fix(gui): explain why ATU Pre-tune is disabled (#5510) #5539 (the reported symptom and its fix)
• fix(icom): dim unavailable tuner controls #5292 (fixed the identical shape for Icom)

---

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

[aethersdr-agent]

Checked this against FlexLib. The premise is wrong, but the conclusion lands on a real defect — just not the one in the title. Details, because the difference matters for what gets fixed.

The family-wide claim is not the Icom shape

There is no per-model gating of ATU memories anywhere in FlexLib. atu set memories_enabled=<0|1> and the atu … memories_enabled= status key are base SmartSDR command surface, parsed unconditionally in Radio.cs:11118 (ParseATUStatus) and sent unconditionally from the ATUMemoriesEnabled setter at Radio.cs:11024. Nothing consults _model. For contrast, FlexLib does keep a model table right next to this code — DiversityIsAllowed (Radio.cs:10947-10970, the 6600/6700/6700R/8600/AU-520 list) — and even that one is documented as a legacy fallback for firmware too old to report diversity_allowed in the info response. So when Flex wants a model-specific capability, it says so, and it prefers to have the radio report it. It does neither for ATU memories.

AU-510 mapping to ID930 in SmartCatProtocol.cpp:555 is a CAT identity table for the ID; command. It carries no capability meaning.

So #5292's root-cause text does not transfer. The Icom problem was that the CI-V tuner path is model-specific. The Flex ATU-memory path is not.

What is actually broken

FlexLib gates the ATU on two runtime signals, and AetherSDR mirrors exactly one of them.

Gate 1 — external tuner. ATUMemoriesEnabled's setter forces the value false when ShouldUseExternalTuner (Radio.cs:13998) — a TGXL in Operate on the TX antenna. We already mirror this: TxApplet::updateAtuAvailability (src/gui/TxApplet.cpp:559-572) folds in !m_tgxlOperate. Fine.

Gate 2 — is an ATU physically fitted. Radio.ATUPresent (Radio.cs:10977-10985), backed by _atuPresent, parsed from the atu_present key in the info reply at Radio.cs:7229-7243. FlexLib treats this as the authority on whether the box has a tuner at all — UpdateExternalTunerState at Radio.cs:14012 gates its ATU re-enable on _atuPresent specifically.

We drop that key on the floor. grep -rn atu_present src/ returns nothing. And we are already parsing the very reply that carries it: RadioModel.cpp:6964-6992 handles callsign, name, region, options, model, chassis_serial, software_ver, ip, netmask, gateway, mac — and stops there. atu_present arrives on the wire on every connect and is discarded.

That is the honest version of the concern. Not "Aurora may not support memories" — that needs no answer, because a radio without an internal ATU reports atu_present=0 and the same fix covers it, no AU-510 required. This equally covers a 6700R, or any unit whose ATU isn't fitted.

Proposed fix

1. src/models/RadioModel.cpp:6964 — parse atu_present in the existing info lambda, present-only (an absent key must mean unknown, not false, or older firmware silently loses its ATU UI). Hand it to the backend.
2. src/core/backends/flex/FlexBackend.cpp:177-178 — keep hasTuner / hasTunerMemories defaulting true, and narrow both to false once a live atu_present=0 has been seen. This is what line 144's own comment already promises: "FlexBackend refines these from live radio status as touchpoints convert."
3. Republish through RadioModel::publishCapabilities (RadioModel.cpp:4270), which is explicitly built for this — "the connect edge and a mid-session revision by the backend take identical paths." No new wiring.

TxApplet needs no change; it already renders both flags and has the right tooltips (TxApplet.cpp:576-587).

One design note for the maintainer, since it cuts against the obvious reading. The GPS comment at FlexBackend.cpp:262-280 argues capabilities should stay coarse — "can a radio of this family have X at all" — with per-unit narrowing done by a combiner like hasGpsHardware(). By that rule hasTunerMemories = true is correct as written and the narrowing belongs outside the seam. I'm recommending refinement inside FlexBackend anyway because, unlike GPS, hasTuner/hasTunerMemories are consumed directly by TxApplet with no combiner in between, and because the ATU flags' own comment at line 144 already claims live-status refinement as their model. If you'd rather preserve the GPS rule strictly, the alternative is a hasAtuHardware() combiner on RadioModel — same wire parse, different seam. Worth picking deliberately, because whichever way it goes is the precedent for the next capability that has a per-unit firmware flag.

Re: #5539

The tooltip concern is real but is not blocked on this. Once atu_present=0 narrows the capability, MEM is disabled and #5539's "Enable MEM before running the pre-tune sweep" string is unreachable on that radio — the button it points at is greyed with "ATU memory controls are unavailable for this radio". No change needed in #5539 itself.

Handoff

• Known: ATU memories are not model-gated in Flex firmware; the family-wide claim is defensible. The genuine gap is that atu_present, present in the info reply we already parse, is ignored, so a Flex with no internal ATU still gets full tuner UI.
• Fix: parse atu_present at RadioModel.cpp:6964 (present-only), narrow hasTuner/hasTunerMemories in FlexBackend::capabilities(), republish via publishCapabilities.
• Open call for the maintainer: refine inside the backend seam, or add a hasAtuHardware() combiner to honor the GPS precedent.
• No hardware needed to verify — a synthetic info reply with atu_present=0 exercises the whole path.

73, AetherClaude

---

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

---

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

Unresolved citations (6)

Citation	Reason
FlexBackend.cpp:262-280	file not found in workspace
RadioModel.cpp:4270	file not found in workspace
RadioModel.cpp:6964	file not found in workspace
RadioModel.cpp:6964-6992	file not found in workspace
SmartCatProtocol.cpp:555	file not found in workspace
TxApplet.cpp:576-587	file not found in workspace