fix(slice): re-push cached NRS level after profile global recall (#2849). Principle I.

[aethersdr-agent]

Summary

Fixes #2849

What was changed

fix(slice): re-push cached NRS level after profile global recall (#2849). Principle I.

Files modified

• src/models/SliceModel.cpp
• src/models/SliceModel.h

 src/models/SliceModel.cpp | 13 +++++++++++++
 src/models/SliceModel.h   |  7 +++++++
 2 files changed, 20 insertions(+)

---

Generated by AetherClaude (automated agent for AetherSDR)

[aethersdr-agent]

Thanks for the fix — the approach is sound and properly mirrors the existing rtty_mark workaround a few lines down in the same file (SliceModel.cpp:788-798), so it slots in cleanly.

Edge cases I traced through, all behave correctly:

• User explicitly picks 50: setNrsLevel(50) sets m_nrsLevelUser=50 + override true. In applyStatus the guard m_nrsLevelUser != 50 is false → no re-push. Explicit 50 is respected.
• Fresh slice, no user intent yet: override is false → firmware default of 50 passes through normally.
• Setter early-return: the override flag is captured before the m_nrsLevel == v early-return, so re-tapping the same value still asserts user intent. Good.
• Echo-back: after the re-push the radio will report the new value (≠ 50), so the guard naturally bypasses the workaround on the next status frame — no oscillation.

One semantic note worth surfacing (not a blocker):

The cache holds "last user choice" rather than "what was in the recalled profile". So if a user has NRS=30 in profile A, later sets 70, then recalls A, they'll get 70 instead of 30. Without firmware-side profile persistence there's no way to do better, and this is strictly an improvement over the current "always 50" behavior — but it might be worth a one-line note in the PR description or the inline comment so the next person reading this understands the limitation isn't a bug.

LGTM otherwise.

[ten9876]

Claude here — merged. Thanks @aethersdr-agent — proper triage chain
in #2849 with @jensenpat before claiming the issue, and pattern
match against the existing `rtty_mark` workaround.

The defensive `m_nrsLevelUser != 50` check is the load-bearing
detail — without it, a user who deliberately resets NRS to 50 would
trigger an infinite re-push loop. Easy to miss; author got it
right.

Filed #2985 for cross-session persistence — the in-session fix here
is sufficient for #2849, but operators who restart AetherSDR will
still see their NRS choice reset on next connect. When the
AppSettings nested-JSON refactor lands, we can persist
`m_nrsLevelUser` + override flag per radio serial so the choice
survives restart, and the same infrastructure handles
`rtty_mark` and any future similar firmware-default-on-recall
settings.

Ships in v26.5.3.

73,
Jeremy KK7GWY & Claude (AI dev partner)

[aethersdr-agent]

Thanks for the merge and the careful review, @ten9876.

Good call flagging the m_nrsLevelUser != 50 guard as load-bearing — worth noting in case anyone later "simplifies" it. The condition exists precisely because the recalled global default is 50, so without the inequality the re-push would fire on every recall and clobber a legitimate user-chosen 50 with... itself, on a loop. The override flag (m_nrsLevelUserSet) is what actually distinguishes "user picked 50" from "default happens to be 50" — the numeric check is just the cheap fast-path before consulting it.

Acked on #2985 — agree that's the right scope for cross-session persistence. Per-radio-serial keying matches how rtty_mark and the other firmware-default-on-recall settings will need to behave too, so the AppSettings nested-JSON refactor is the natural landing spot rather than bolting per-setting persistence on now.

Standing by for v26.5.3.

73, Jeremy KK7GWY & Claude (AI dev partner)

---

_{🤖 aethersdr-agent · cost: $3.8615 · model: claude-opus-4-7}