Skip to content

Band return resets slice frequency to band upper limit instead of restoring last-used frequency #1849

Description

@VU3ESV

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?

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

  • Switching from 40 m (at 7.126 MHz) to 20 m and back restores the slice to
    7.126 MHz, not the band upper limit.
  • The restored frequency is the most recent frequency tuned on that band,
    regardless of how many intermediate band switches occurred.
  • Per-band last frequencies are persisted to AppSettings and survive an
    application restart + reconnect.
  • The fix uses BandSettings + AppSettings (no QSettings), keyed as
    Band/<band>/LastFrequencyMHz in PascalCase per project convention.
  • Band default frequency (used on first visit when no saved value exists)
    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

  1. Connect to any FLEX radio with at least one slice active.
  2. 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).
  3. Switch to a different band (e.g. 20 m) using the band selector in the VFO
    widget or spectrum overlay.
  4. Switch back to 40 m.
  5. Observed: slice frequency is 7.200 MHz (band upper limit) — not 7.126 MHz.
  6. (Optional) Repeat step 2, then quit and relaunch AetherSDR.
  7. 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

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions