[tuning] Restore Flex band-stack selection keys by jensenpat · Pull Request #1887 · aethersdr/AetherSDR

jensenpat · 2026-04-24T01:06:25Z

Summary

This restores radio-authoritative Flex band-stack selection from the spectrum band menu. Native band buttons now send the Flex band-stack key the radio expects, transverter bands are mapped through the radio's XVTR setup order, and unsupported bands are refused instead of falling back to a direct slice tune.

The important behavior change is that AetherSDR again lets the radio own band-stack recall for frequency, mode, filters, pan center, bandwidth/zoom, and antenna state. We do not synthesize a local frequency/mode restore and we do not force a client-side recenter after the band switch.

Manual testing also confirmed that built-in Flex RX/TX antenna selections persist across band changes once Aether uses the correct radio-authoritative band= path. This does not add a separate Aether-side antenna memory layer; it restores the radio-owned behavior that was bypassed by the fallback tune path.

Root Cause

The band selector UI emits human-facing labels such as 20m, 40m, 630m, etc. The band-switching handler was checking those values against a native-band pass-through set containing bare Flex keys such as 20, 40, and 630.

That mismatch meant ordinary native bands missed the intended path:

display pan set <panId> band=20

and instead fell into the old unrecognized-band fallback. The fallback directly changed the slice mode and tuned to the static band-grid default, for example 14.225 USB on 20m. That bypassed the radio's band stack, so user state that should have been restored by the radio was replaced by Aether's hard-coded defaults.

This is why users saw symptoms like:

returning to 20m at 14.225 USB instead of their last CW frequency
returning to 40m at the band edge/default instead of the last used frequency
span/zoom and pan position appearing to reset across band changes
mode changing back to SSB when the previous per-band state was CW or another mode
built-in Flex RX/TX antenna selections appearing not to persist per band when the fallback path bypassed the radio's saved band-stack state

What Changed

Normalize native UI labels only when the stripped key is a known Flex native band:
- 20m -> band=20
- 630m -> band=630
- 2200m -> band=2200
Preserve the existing WWV/GEN behavior:
- WWV -> band=33
- GEN -> band=34
Parse the radio's XVTR order status field into RadioModel::XvtrInfo.
Map configured transverter display names to Flex XVTR band selectors using X<order>:
- configured 2m with order=0 -> band=X0
- configured 70cm with order=1 -> band=X1
Remove the unsafe fallback that did slice set mode=... plus direct slice tune ....
Restore radio-owned antenna recall for band changes by ensuring Aether uses the Flex band-stack selector instead of bypassing it with direct slice tune commands.
If Aether cannot form a spec-correct band= key, log a warning, show a short status-bar message, and leave the slice/panadapter untouched.

Flex API Notes

The public Flex display pan set API exposes band selection as a panadapter property:

display pan set <panId> band=<bandKey>

For native bands, the key is the radio band-stack name, not the UI label with the meter suffix. For transverters, the selector is the radio's XVTR setup slot in X<n> form. The name field is the user's display label; the order field is the value that determines the X<n> selector.

This distinction matters because the XVTR status index is not necessarily the correct selector. This PR uses order, not the xvtr <index> map key.

Behavior Matrix

User selection	Flex command behavior	Notes
`160m`	`display pan set <panId> band=160`	Native band stack
`80m`	`display pan set <panId> band=80`	Native band stack
`60m`	`display pan set <panId> band=60`	Native band stack
`40m`	`display pan set <panId> band=40`	Native band stack
`30m`	`display pan set <panId> band=30`	Native band stack
`20m`	`display pan set <panId> band=20`	Native band stack
`17m`	`display pan set <panId> band=17`	Native band stack
`15m`	`display pan set <panId> band=15`	Native band stack
`12m`	`display pan set <panId> band=12`	Native band stack
`10m`	`display pan set <panId> band=10`	Native band stack
`6m`	`display pan set <panId> band=6`	Native band stack
`630m`	`display pan set <panId> band=630`	Native band stack
`2200m`	`display pan set <panId> band=2200`	Native band stack
`WWV`	`display pan set <panId> band=33`	Existing numeric slot retained
`GEN`	`display pan set <panId> band=34`	Existing numeric slot retained
XVTR `2m`, `order=0`	`display pan set <panId> band=X0`	Uses XVTR setup order
XVTR `70cm`, `order=1`	`display pan set <panId> band=X1`	Uses XVTR setup order
XVTR with no `order`	Refuse; no tune fallback	Safer than tuning wrong band
Unknown band label	Refuse; no tune fallback	Safer than resetting mode/frequency

Issue History

This PR directly fixes the failure proven in #1876: native band changes were not using the radio band stack and instead reset VFO/span state to Aether's defaults.

It also appears to address the same regression pattern reported in:

Span and VFO freeze when u change band, the most important one, has not been regularized #1852: span and VFO freeze / reset when changing bands; reporter confirmed it was the same as The problem doesn't seem to be resolved. Span and VFO freeze when changing bands. #1876
The last band settings are not saved #1856: last band settings not saved; returning to 20m lands on 14.300 SSB instead of the previous CW QRG
Band return resets slice frequency to band upper limit instead of restoring last-used frequency #1849: returning to a band lands at the band upper edge/default instead of the last used frequency
unusable if the VFO switches to SSB mode at every band change #1800: VFO switches to SSB mode at every band change
v0818 does not retain mode nor does it in v0819 #1761: mode and frequency not retained in v0.8.18/v0.8.19
v.0.8.18 at each band change the VFO does not memorize and switches to SSB center band #1743: VFO/span not memorized; returns to SSB center band
Pan does not memorize. Change default band to SSB #1662: v0.8.16 no longer memorizes slices; returns to SSB and pan center
Why not solve this problem of the VFO being positioned at the center of the Pan? #1093: older report describing pan/VFO position not remaining where the user left it
memory in the selection of Tx Rx antennas according to the band #1886: built-in Flex TX/RX antenna selection not remembered per band; testing confirmed this PR restores antenna persistence when the radio band stack owns the saved antenna state
antenas #1758: antenna 1 / antenna 2 state not memorized across band changes

Related prior history:

Fix band-switch VFO/span reset by stripping "m" suffix from band key (#1876) #1880: draft minimal fix that stripped the m suffix for native bands. This PR keeps that core idea, but also removes the unsafe fallback and fixes XVTR selection against the Flex API shape.
Band change resets zoom level — per-band zoom not persisted or restored #649: earlier zoom/bandwidth persistence report. This PR relies on the radio band stack to restore the bandwidth/zoom state rather than adding a separate Aether-side zoom override.
Band Stack #1540: WWV, GEN, and XVTR band stack failures / blank waterfall history. This PR preserves WWV/GEN numeric slots and hardens XVTR key generation.
Loss of Transverter operation after 8.7 #1211: loss of transverter operation after 8.7.
When switching Bands will not set the memorized Antenna on AG8x2 #1213: Antenna Genius band-to-antenna recall race. This is a separate external AG path, but useful history because it shows the same user expectation: band changes should recall the appropriate antenna.
XVTR bands not appearing in main GUI band selector when transverters are configured #571: XVTR bands not appearing in the main selector after configuration.
Flexradio 6700 missing 144 and 70Mhz #695: 6700 native VHF band visibility history; adjacent to band listing behavior but not directly changed here.

Validation

Automated/local checks:

git diff --check
cmake --build build -j10

Build succeeded. The compiler still reports unrelated pre-existing lambda-capture warnings in MainWindow.cpp.

Manual validation performed:

Native band switching restores last-used frequency and zoom/span instead of resetting to hard-coded defaults.
No client-side recenter override is applied after band switch; this matches SmartSDR behavior where the radio restores the band stack's pan center.
Built-in Flex RX/TX antenna selections persist across band changes when set per band and recalled through the restored display pan set ... band= path.
XVTR entries can be configured without physical transverter hardware and selected from the band menu.
Test XVTR profile:
- 2m: RF 144.200, IF 28.200, LO 116.000, RX Only enabled, Max Power 0.0
- 70cm: RF 432.100, IF 28.100, LO 404.000, RX Only enabled, Max Power 0.0
Switching across 2m, 70cm, and native HF bands preserves frequency and zoom/span state.

Suggested Test Plan

Native Band Stack

Start on 20m.
Tune to a non-default frequency, for example 14.360.000.
Set a distinctive mode, for example CW.
Adjust pan position so the VFO is visible but not necessarily centered.
Set a distinctive panadapter bandwidth/zoom.
Switch to 40m.
Tune 40m to a different non-default frequency and use a different zoom/span.
Switch back to 20m.
Verify frequency, mode, pan center, and bandwidth/zoom match the prior 20m state.
Repeat across several native bands, including 630m or 2200m if available.

Two Slice Regression

Create Slice A and Slice B on different bands.
Give each slice a different frequency, mode, pan position, and zoom/span.
Change bands from each slice's panadapter.
Return to the original bands.
Verify each slice/panadapter returns to its own band-stack state and does not inherit the other slice's defaults.

WWV / GEN

Select WWV.
Verify the radio changes via the band stack and does not use direct slice tuning fallback.
Select GEN.
Verify the same.
Confirm there are no status-bar warnings for these selections.

Built-in Flex Antenna Persistence

Start on 20m.
Select a distinctive built-in RX/TX antenna, for example ANT2.
Switch to 40m.
Select a different built-in RX/TX antenna, for example ANT1.
Switch back to 20m.
Verify the radio/Aether restore the prior 20m antenna selection.
Switch back to 40m.
Verify the prior 40m antenna selection is restored.
Repeat with the opposite direction and, where available, with separate RX and TX antenna choices.

XVTR Without Physical Hardware

Open Radio Setup -> XVTR.
Add a 2m XVTR:
- Name: 2m
- RF Freq: 144.200
- IF Freq: 28.200
- LO Freq: 116.000
- LO Error: 0
- RX Gain: 0.0
- RX Only: enabled
- Max Power: 0.0
Add a 70cm XVTR:
- Name: 70cm
- RF Freq: 432.100
- IF Freq: 28.100
- LO Freq: 404.000
- LO Error: 0
- RX Gain: 0.0
- RX Only: enabled
- Max Power: 0.0
Close Radio Setup and open the band selector.
Select 2m; verify the panadapter tunes to the XVTR band.
Set a distinctive zoom/span and tune within the XVTR band.
Switch to a native HF band, then back to 2m; verify frequency and zoom/span persist.
Repeat with 70cm.

XVTR Order Regression

With two XVTR entries configured, verify the debug log reports XVTR match: "2m" -> "X0" and XVTR match: "70cm" -> "X1" or the corresponding order values reported by the radio.
If the radio UI allows reordering, reorder the XVTR entries.
Reconnect or force status refresh.
Verify Aether follows the radio's updated order value rather than the status object index.

Negative / Safety Behavior

Attempt to select an invalid or unsupported band mapping, if one can be produced from a test build or malformed radio status.
Verify Aether shows a status-bar warning and logs a warning.
Verify Aether does not send a direct slice tune fallback and does not change the slice mode/frequency.

Risk Notes

This intentionally removes the direct-tune fallback. That is safer for preserving radio state, but it means a malformed or unsupported band entry now fails visibly instead of trying to guess a frequency/mode.
XVTR selection now depends on the radio reporting order. That matches the Flex API behavior we need for X<n> selectors; if a radio/firmware does not provide order, Aether refuses the XVTR selection rather than risking the wrong transverter.
No Aether-side recentering is applied after band switches. This is intentional because SmartSDR preserves the band stack's pan center when returning to a band.
Built-in Flex antenna persistence still relies on the radio band stack. This PR does not add a separate client-side rxant / txant memory layer in Aether. If a future radio/firmware path does not save antenna changes into the band stack, that would need a separate memory in the selection of Tx Rx antennas according to the band #1886-style follow-up.

Files Changed

src/gui/MainWindow.cpp
src/models/RadioModel.cpp
src/models/RadioModel.h

👨🏼‍💻 Generated with OpenAI Codex (GPT-5.5 Pro 4/23) and tested by @jensenpat

aethersdr-agent

Thanks for this thorough PR, @jensenpat — the write-up, behavior matrix, and test plan are all excellent. The root cause analysis (UI labels carrying the m suffix while the pass-through set uses bare numbers) is spot-on, and this is clearly the right fix for the long-running band-stack regression.

I read through the diff carefully and have a few observations:

Looks Good

Label stripping logic is well-guarded: only strips m when the bare result is a known native band, so XVTR names like "2m" correctly fall through to the XVTR lookup. Clean approach.
Removing the direct-tune fallback is the right call. The old fallback silently overwrote radio state and was the source of the regression symptoms reported across many issues.
order vs map index for XVTR — using the Flex order field for X<n> selectors matches the API spec and is an important correctness fix over the prior it.key() approach.
m_bandSettings.setCurrentBand() moved inside the success branch — good, this avoids updating Aether's band tracking when the command is refused.
XvtrInfo::order defaults to -1 — clean sentinel for "radio didn't report this field."

Minor Points (non-blocking)

order parse without validation: In RadioModel.cpp, kvs["order"].toInt() will silently return 0 for non-numeric strings, which is a valid order value. This could cause an XVTR entry to appear valid (order >= 0) when the radio sent garbage. A toInt(&ok) check would be slightly more defensive at this system boundary, though in practice the radio firmware is unlikely to send non-numeric order values.
XVTR name collision: If two XVTR entries have the same name, the break after the first match means we always pick the first one. That's the existing behavior and is fine, but worth noting that the Flex API doesn't enforce unique XVTR names — an edge case that probably doesn't matter in practice.
Status bar message lifetime: The 5-second showMessage timeout for refused bands is reasonable. Just flagging that if other status messages are being posted rapidly (e.g., during reconnect), this could get overwritten before the user sees it. The qWarning log is the durable record, so this is fine.

Relationship to #1880

This PR supersedes the draft #1880 (which only stripped the m suffix without removing the fallback or fixing XVTR selection). If this merges, #1880 can be closed.

Overall this is a clean, well-scoped fix. The changes stay within the stated scope (MainWindow band handler + RadioModel XVTR parsing), no new resource management concerns, no null pointer risks I can see. Nice work — and thank you for the detailed manual testing across native bands, XVTR, and the negative cases.

ten9876 · 2026-04-24T05:41:58Z

Claude here on behalf of Jeremy — merged via `gh pr merge --squash` as `41c1699` (you preserved as git author on the squashed commit).

Nice writeup on the root cause and fallback-removal reasoning. The XVTR `order`-vs-index distinction and the pcap references made the protocol correctness easy to confirm. Looking forward to hearing how the band stack feels after this lands.

Thanks Pat!

73, Jeremy KK7GWY & Claude (AI dev partner)

…#2511) Flex's `display pan set band=X<n>` expects the xvtr status-object index (the number from `xvtr <n>` messages, 0-based), not the radio's 1-based `order` field. Using `order` produced a +1 shift: pressing the 144 MHz button sent `band=X1` instead of `band=X0`, tuning to 432 MHz instead. Reverts the index→order swap from PR #1887 back to the pcap-verified `X<index>` form from PR #1615. Updates the test assertions and renames the test function to reflect the correct semantics. Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>

Restore Flex band-stack selection keys

a78f66b

jensenpat changed the title ~~Restore Flex band-stack selection keys~~ [tuning] Restore Flex band-stack selection keys Apr 24, 2026

jensenpat marked this pull request as ready for review April 24, 2026 01:14

jensenpat requested a review from ten9876 as a code owner April 24, 2026 01:14

aethersdr-agent Bot reviewed Apr 24, 2026

View reviewed changes

Document Flex band selection decisions

337986d

ten9876 merged commit 41c1699 into aethersdr:main Apr 24, 2026
5 checks passed

ten9876 mentioned this pull request Apr 24, 2026

Fix band-stack recall: match band names with "m" suffix (#1761) #1763

Closed

This was referenced Apr 30, 2026

v0818 does not retain mode nor does it in v0819 #1761

Closed

Span and VFO freeze when u change band, the most important one, has not been regularized #1852

Closed

memory in the selection of Tx Rx antennas according to the band #1886

Closed

aethersdr-agent Bot mentioned this pull request May 4, 2026

Transverter #2342

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

[tuning] Restore Flex band-stack selection keys#1887

[tuning] Restore Flex band-stack selection keys#1887
ten9876 merged 2 commits into
aethersdr:mainfrom
jensenpat:aether/issue-1876-band-stack-restore

jensenpat commented Apr 24, 2026 •

edited

Loading

Uh oh!

aethersdr-agent Bot left a comment

Uh oh!

Uh oh!

ten9876 commented Apr 24, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

jensenpat commented Apr 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Root Cause

What Changed

Flex API Notes

Behavior Matrix

Issue History

Validation

Suggested Test Plan

Native Band Stack

Two Slice Regression

WWV / GEN

Built-in Flex Antenna Persistence

XVTR Without Physical Hardware

XVTR Order Regression

Negative / Safety Behavior

Risk Notes

Files Changed

Uh oh!

aethersdr-agent Bot left a comment

Choose a reason for hiding this comment

Looks Good

Minor Points (non-blocking)

Relationship to #1880

Uh oh!

Uh oh!

ten9876 commented Apr 24, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

jensenpat commented Apr 24, 2026 •

edited

Loading