Background
Per-band settings persistence (band memory) was implemented in v0.2.0 but had a critical bug where the band-crossing detection fired during initial connection, saving incorrect state (e.g., 20m frequency saved under 80m/40m bands). The fix in v0.2.3 guarded with m_updatingFromModel but this didn't work because the flag was reset before the band-crossing code ran in the same lambda.
Band memory is currently deprecated — band switching always uses BandDef defaults, and any stale QSettings band data is cleared on launch.
What Needs to Be Redesigned
The core problem: automatically detecting band crossings from frequencyChanged signals is unreliable because:
- The signal fires for both user-initiated and radio-status-driven frequency changes
- During connect, the radio sends multiple frequency updates as slices are initialized
- There's no reliable way to distinguish "user tuned across a band edge" from "radio reported its current frequency"
Proposed Approaches
Option A: Save only on explicit band button clicks
- Only save state when the user clicks a band button in the overlay menu
- Simple, no false triggers, but doesn't save state when user tunes manually across bands
Option B: Timer-based debounce
- After a frequency change, wait N seconds before saving band state
- Avoids saving during rapid status updates on connect
- Still risky during reconnect/auto-connect
Option C: Radio-side band stacking
- The radio may have its own band stacking registers (
band_persistence_enabled=1 seen in radio status)
- Investigate if the radio handles per-band settings natively and we just need to read them
Settings to Persist Per Band
When redesigned, each band should save:
- Frequency, mode, RX antenna
- Filter width, AGC mode/threshold
- RF gain, WNB on/off + level
- Pan center, bandwidth, dBm range, FFT/waterfall split
Related Code
src/models/BandSettings.h/.cpp — BandSnapshot struct, save/load/lookup (currently unused)
src/models/BandDefs.h — shared band table with defaults
src/gui/MainWindow.cpp — captureCurrentBandState(), restoreBandState() (currently unused)
References
🤖 Generated with Claude Code
Background
Per-band settings persistence (band memory) was implemented in v0.2.0 but had a critical bug where the band-crossing detection fired during initial connection, saving incorrect state (e.g., 20m frequency saved under 80m/40m bands). The fix in v0.2.3 guarded with
m_updatingFromModelbut this didn't work because the flag was reset before the band-crossing code ran in the same lambda.Band memory is currently deprecated — band switching always uses BandDef defaults, and any stale QSettings band data is cleared on launch.
What Needs to Be Redesigned
The core problem: automatically detecting band crossings from
frequencyChangedsignals is unreliable because:Proposed Approaches
Option A: Save only on explicit band button clicks
Option B: Timer-based debounce
Option C: Radio-side band stacking
band_persistence_enabled=1seen in radio status)Settings to Persist Per Band
When redesigned, each band should save:
Related Code
src/models/BandSettings.h/.cpp— BandSnapshot struct, save/load/lookup (currently unused)src/models/BandDefs.h— shared band table with defaultssrc/gui/MainWindow.cpp—captureCurrentBandState(),restoreBandState()(currently unused)References
🤖 Generated with Claude Code