Report preparation
What happened?
What happened
When a user switches away from a band and then returns to it, the slice frequency
is set to the upper edge of the band rather than the frequency that was active
when the band was left.
Reproduction example:
- Active slice is on 40 m at 7.126 MHz
- User switches to 20 m → radio tunes to 14.225 MHz (correct default)
- User switches back to 40 m → slice lands at 7.200 MHz (band upper limit)
instead of the expected 7.126 MHz
The last-used frequency per band is never saved to AppSettings, so on every
return visit the radio's band-change command targets a default or limit frequency.
Root cause analysis
BandSettings (src/models/BandSettings) is the intended home for per-band
persistent state, but it does not appear to save the last-used slice frequency
as one of its fields. When the band-change handler fires, it either:
- sends
slice set RF_frequency=<band_default> using a hardcoded default, or
- lets the radio's own band-edge default take effect (yielding the upper limit),
without first saving the outgoing frequency and without restoring a saved value
on the incoming band.
Relevant files and call chain:
src/models/BandSettings — needs a lastFrequency field per band
src/models/SliceModel — owns RF_frequency; its applyStatus / setter
should hook into BandSettings::saveLastFrequency() on band change
src/models/RadioModel / src/gui/MainWindow — the band-change handler
should call BandSettings::loadLastFrequency() and issue
slice set RF_frequency=<saved> after the new band is confirmed active
src/core/AppSettings — key should follow PascalCase convention, e.g.
Band/40m/LastFrequencyMHz
Suggested fix
// BandSettings — add per-band last-frequency persistence
void BandSettings::saveLastFrequency(const QString& band, double freqMhz) {
AppSettings::instance().setValue(
QStringLiteral("Band/%1/LastFrequencyMHz").arg(band),
QString::number(freqMhz, 'f', 6));
}
double BandSettings::loadLastFrequency(const QString& band, double defaultMhz) {
return AppSettings::instance()
.value(QStringLiteral("Band/%1/LastFrequencyMHz").arg(band),
QString::number(defaultMhz, 'f', 6))
.toDouble();
}
Hook saveLastFrequency() whenever SliceModel::setFrequency() is called and
the slice is on a known band. In the band-change handler, call
loadLastFrequency() after the band switch is confirmed and issue:
slice set RF_frequency=<saved_freq>
Note: the VFO frequency for the current session is also restored via client gui <GUIClientID> session persistence (see CLAUDE.md — VFO Frequency Sync), but
that mechanism only covers the active slice's frequency on reconnect. It does
not cover per-band stacking across band switches within a session, so an
explicit BandSettings round-trip is required here.
Acceptance criteria
What did you expect?
Returning to a band should restore the last frequency the user was on within
that band, identical to the "band stacking" behaviour in SmartSDR for Windows.
The restored frequency should be the one that was active immediately before
switching away — it should persist both within the same session and across
application restarts.
Steps to reproduce
- Connect to any FLEX radio with at least one slice active.
- Tune the slice to a non-default frequency within a band — e.g. 7.126 MHz
on 40 m (not the band default of 7.200 MHz).
- Switch to a different band (e.g. 20 m) using the band selector in the VFO
widget or spectrum overlay.
- Switch back to 40 m.
- Observed: slice frequency is 7.200 MHz (band upper limit) — not 7.126 MHz.
- (Optional) Repeat step 2, then quit and relaunch AetherSDR.
- Observed: same — 7.200 MHz on reconnect; the last-used frequency was
never persisted.
AetherSDR version
v0.8.19
Radio model & firmware
FLEX-6600 v4.1.15
Operating system
macOS
OS version and hardware
Tahoe 26.4.1
support-bundle-20260422-101819.tar.gz
Report preparation
What happened?
What happened
When a user switches away from a band and then returns to it, the slice frequency
is set to the upper edge of the band rather than the frequency that was active
when the band was left.
Reproduction example:
instead of the expected 7.126 MHz
The last-used frequency per band is never saved to
AppSettings, so on everyreturn visit the radio's band-change command targets a default or limit frequency.
Root cause analysis
BandSettings(src/models/BandSettings) is the intended home for per-bandpersistent state, but it does not appear to save the last-used slice frequency
as one of its fields. When the band-change handler fires, it either:
slice set RF_frequency=<band_default>using a hardcoded default, orwithout first saving the outgoing frequency and without restoring a saved value
on the incoming band.
Relevant files and call chain:
src/models/BandSettings— needs alastFrequencyfield per bandsrc/models/SliceModel— ownsRF_frequency; itsapplyStatus/ settershould hook into
BandSettings::saveLastFrequency()on band changesrc/models/RadioModel/src/gui/MainWindow— the band-change handlershould call
BandSettings::loadLastFrequency()and issueslice set RF_frequency=<saved>after the new band is confirmed activesrc/core/AppSettings— key should follow PascalCase convention, e.g.Band/40m/LastFrequencyMHzSuggested fix
Hook
saveLastFrequency()wheneverSliceModel::setFrequency()is called andthe slice is on a known band. In the band-change handler, call
loadLastFrequency()after the band switch is confirmed and issue:slice set RF_frequency=<saved_freq>
Note: the VFO frequency for the current session is also restored via
client gui <GUIClientID>session persistence (see CLAUDE.md — VFO Frequency Sync), butthat mechanism only covers the active slice's frequency on reconnect. It does
not cover per-band stacking across band switches within a session, so an
explicit
BandSettingsround-trip is required here.Acceptance criteria
7.126 MHz, not the band upper limit.
regardless of how many intermediate band switches occurred.
AppSettingsand survive anapplication restart + reconnect.
BandSettings+AppSettings(noQSettings), keyed asBand/<band>/LastFrequencyMHzin PascalCase per project convention.falls back gracefully to the existing hardcoded default — no regression for
new installs or first-ever band visit.
What did you expect?
Returning to a band should restore the last frequency the user was on within
that band, identical to the "band stacking" behaviour in SmartSDR for Windows.
The restored frequency should be the one that was active immediately before
switching away — it should persist both within the same session and across
application restarts.
Steps to reproduce
on 40 m (not the band default of 7.200 MHz).
widget or spectrum overlay.
never persisted.
AetherSDR version
v0.8.19
Radio model & firmware
FLEX-6600 v4.1.15
Operating system
macOS
OS version and hardware
Tahoe 26.4.1
support-bundle-20260422-101819.tar.gz