2m/4m Button now here in F6700 - but with out function => TRX not jump to this band

[DL5NAM]

Report preparation

• I used the AI-assisted bug report tool (Help → Support → File an Issue)
• I have attached a support bundle or log file

What happened?

4 m / 2 m bands on FLEX-6700

What did you expect?

No response

Steps to reproduce

click on band bottom - no function

AetherSDR version

26.5.2

Radio model & firmware

Flex 6700 - 4.1.5

Operating system

Windows

OS version and hardware

WIN11 - actual version

[aethersdr-agent]

Triage — root cause is clear; needs maintainer call on the exact key string

Confirmed bug. PR #2757 (commit 98008a0, "surface 4m/2m on FLEX-6500/6700 via ModelCapabilities") added the 4m and 2m buttons to the Spectrum-Overlay band panel for radios advertising has4Meters / has2Meters, but did not teach XvtrPolicy::resolveBandStackKey() to map those UI labels to a Flex band-stack key. The button is wired and emits bandSelected, but the handler then refuses the change because no key can be formed.

Trace

1. src/gui/SpectrumOverlayMenu.cpp:1390-1396 — when has4Meters / has2Meters is true, builds the buttons that emit bandSelected("4m", 70.200, "USB") / bandSelected("2m", 144.200, "USB") (see BAND_GRID[kBandIdx4m] / [kBandIdx2m] at lines 114-115).
2. src/gui/MainWindow.cpp:11092-11150 — handler calls XvtrPolicy::resolveBandStackKey("4m", xvtrs). The xvtrs list only contains user-configured transverters; the FLEX-6700's built-in 4m/2m hardware is not in that list (per the PR feat(bands): surface 4m/2m on FLEX-6500/6700 via ModelCapabilities (#695) #2757 design — these are native, not XVTRs).
3. src/models/XvtrPolicy.cpp:14-22 — kNativeBandKeys contains {160, 80, 60, 40, 30, 20, 17, 15, 12, 10, 6, 2200, 630}. "4" and "2" are missing. So normalizedNativeBandKey("4m") returns "4m" unchanged (the suffix-strip only fires if the stripped value is in the native set), no XVTR matches, and resolveBandStackKey returns an empty key with reason "Band 4m has no Flex display pan band= mapping".
4. MainWindow.cpp:11127-11133 — empty key → log a warning, show the status-bar message for 5 s, return without sending any command. From the user's perspective the button does nothing.

Proposed fix

Add 4m/2m to the native-band passthrough in src/models/XvtrPolicy.cpp so the existing suffix-strip path produces the right key:

static const QSet<QString> kNativeBandKeys = {
    QStringLiteral("160"), QStringLiteral("80"), QStringLiteral("60"),
    QStringLiteral("40"),  QStringLiteral("30"), QStringLiteral("20"),
    QStringLiteral("17"),  QStringLiteral("15"), QStringLiteral("12"),
    QStringLiteral("10"),  QStringLiteral("6"),
    QStringLiteral("4"),   QStringLiteral("2"),     // ← new
    QStringLiteral("2200"), QStringLiteral("630")
};

That would make "4m" → band=4 and "2m" → band=2, matching the HF convention (e.g. "6m" → band=6). Also add the corresponding cases to tests/xvtr_policy_test.cpp::testBandStackKeysUseFlexIndex().

One open question for the maintainer

The exact string SmartSDR uses for display pan set <pan> band=… on FLEX-6700's built-in 4m/2m was not determined empirically here. Three plausible conventions, in order of likelihood:

1. band=4 / band=2 — matches the HF native pattern (most likely, and what the patch above implements).
2. band=4m / band=2m — pass the suffix through (unusual; would diverge from "6m" → band=6).
3. Numeric slot indexes — e.g. band=35 / band=36, by analogy with the WWV=33 / GEN=34 slots Flex uses for non-interlock bands (per commit f74cd52, derived from pcap of SmartSDR).

The #1540/#1211 follow-up established the pcap-of-SmartSDR methodology for resolving exactly this ambiguity. A 30-second SmartSDR capture against the user's FLEX-6700 firmware 4.1.5 selecting 4m and 2m would settle it definitively. Without that, option (1) is the highest-probability guess but I'd recommend the maintainer confirm before merging — sending the wrong key silently corrupts the user's band-stack state (which is exactly the failure mode the MainWindow comment at line 11097 warns against).

Handoff summary

• What's known: band buttons appear correctly on FLEX-6700 (PR feat(bands): surface 4m/2m on FLEX-6500/6700 via ModelCapabilities (#695) #2757 capability gating works as designed). The click handler refuses because resolveBandStackKey doesn't know "4m"/"2m".
• What to fix: add "4" and "2" to kNativeBandKeys in src/models/XvtrPolicy.cpp; add unit-test coverage in tests/xvtr_policy_test.cpp.
• Why: completes PR feat(bands): surface 4m/2m on FLEX-6500/6700 via ModelCapabilities (#695) #2757 — the UI half landed without the protocol-key half.
• Decision needed: confirm the band-stack key string Flex expects (4/2 vs 4m/2m vs a numeric slot) via SmartSDR pcap or upstream FlexLib docs before implementation.

---

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

Unresolved citations (1)

Citation	Reason
MainWindow.cpp:11127-11133	file not found in workspace

[aethersdr-agent]

This looks similar to #695 — is this the same issue, or something different? If it is the same, we can track it there. Note that #695 is closed/fixed, so it would also be helpful to confirm whether this still happens on the latest version. — AetherClaude (automated agent for AetherSDR)

[DL5NAM]

it' a "long time" error, #695 is only 50% fixed in 26.5.2 but still useless if not 100% - see video !
A click on button = no reaction

[jensenpat]

@AetherClaude please double check if this is fixed in #2831

[aethersdr-agent]

@jensenpat — Yes, PR #2831 fixes this exact bug and is the right thing to wait on. I checked both the current main (still broken) and the PR diff against the path I traced in my triage above:

How #2831 addresses the root cause I identified

1. src/models/XvtrPolicy.cpp — isNativeBandKey() now accepts "4" and "2" as native keys, but gated on ModelCapabilities::has4Meters / has2Meters. So the FLEX-6700 click that previously fell through resolveBandStackKey() now correctly returns band=4 / band=2. The capability gate is what my triage didn't think to suggest — without it, a user-configured XVTR literally named "4m" on a 6500/6700 would be shadowed by the native path. Better than my proposed fix.

2. band=4 / band=2 is empirically confirmed, not guessed — the PR description cites the FLEX-6700 SmartSDR wire capture from Flexradio 6700 missing 144 and 70Mhz #695 as the source. This resolves the "one open question for the maintainer" I flagged about which key string Flex actually expects. So option (1) from my triage was correct.

3. XVTR shadow-protection — SpectrumOverlayMenu::XvtrBand now also carries an explicit stackKey ("X<n>"), and bandSelected plumbs it through as a stackKeyHint to MainWindow::wirePanadapter(). That means a user XVTR named "4m" on a 6700 will still resolve via its X<n> key instead of being silently replaced by the native one. Important correctness detail.

4. Bonus scope: PR fix: route native 4m/2m band selection #2831 also fixes direct frequency entry above 54 MHz in VfoWidget and RxApplet via the new FrequencyEntryParser, and routes RX-applet direct entry through applyTuneRequest() so the band-stack pre-select fires for typed-in 2m/70cm frequencies too. Same root cause family — well-scoped to bundle.

To @DL5NAM

This is not yet released. PR #2831 is open and tagged priority: high but has not merged to main as of today (2026-05-21). Once it merges and ships in the next nightly/release, your 4m/2m buttons on the FLEX-6700 will tune properly. Thanks for the video — it made the failure mode unambiguous.

To the maintainer

The aetherclaude-eligible label is already on this issue, but since PR #2831 already implements the fix (and goes beyond what I would have proposed), the orchestrator should not open a duplicate PR. I'd suggest either:

• Removing aetherclaude-eligible and letting fix: route native 4m/2m band selection #2831 land, or
• Closing this issue as "fixed by fix: route native 4m/2m band selection #2831" once that PR merges.

73, Jeremy KK7GWY & Claude (AI dev partner)