NRS setting value not persistent goes to 50 each time.

[marknewbill15-wq]

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?

NRS setting value not persistent goes to 50 each time.

What did you expect?

Nrs value to stay at last use value

Steps to reproduce

set NRS to value of 30
save global profile
recall global profile
NRS is now set to 50 again. default.

AetherSDR version

26.5.2.1

Radio model & firmware

flex 8400 4.2

Operating system

Windows

OS version and hardware

windows 11

[aethersdr-agent]

Triage analysis

What I see in the client code

Client-side NRS plumbing looks correct:

• SliceModel::setNrsLevel(int) (src/models/SliceModel.cpp:223-230) clamps to 0–100 and sends slice set <id> speex_nr_level=<v> — matches FlexLib's Slice.cs:1226 exactly.
• Incoming radio status is parsed at SliceModel.cpp:745-748 and writes through to m_nrsLevel.
• The literal 50 is only the in-memory default for a freshly constructed SliceModel (SliceModel.h:297). All other DSP levels default to 50 too (lines 292–299).

profile global load is a bare passthrough — RadioModel::loadGlobalProfile (RadioModel.cpp:4747) just sends profile global load "<name>" and lets the radio firmware do the rest. As MainWindow.cpp:9149 notes, slices get destroyed and recreated by the firmware as part of that load. The newly constructed SliceModel starts at 50, then we update from whatever the radio reports.

Most likely root cause

The Flex firmware's profile global snapshot does not persist speex_nr_level. On recall, the radio restores its other slice state but resets NRS Level to the firmware default of 50, and that's what we receive in the slice status burst (or the firmware never sends speex_nr_level= at all, leaving our client-side default of 50). Either way, the reset originates on the radio.

This matches the symptom precisely: deterministic reset to exactly 50 (the firmware default, which happens to coincide with our client default), affecting only NRS — no other DSP level is reported.

This is a known pattern for SmartSDR firmware persistence gaps. Compare SliceModel.cpp:788-797, where the firmware resets rtty_mark to 2125 on band change and we work around it client-side by re-pushing the user's chosen value.

Proposed fix

Two options, in order of preference:

1. Upstream fix (preferred). Report to Flex so a future firmware persists speex_nr_level in profile global snapshots. AetherSDR can't fix this server-side.
2. Client-side workaround (if upstream isn't viable). Mirror the rtty_mark precedent: cache the user's last-set NRS Level per slice, and after a profile global load completes (slice re-creation finishes), re-send slice set <id> speex_nr_level=<cached> if the radio reports back the firmware default of 50. Caveat: this would override any intentional per-profile NRS Level differences the user wants — the rtty_mark workaround sidesteps this with an explicit "user override" flag (SliceModel.h:314); we'd need the same.

Handoff summary

• Known: client send/parse paths are correct; defaults of 50 are by-design. Reset originates on the radio during profile global round-trip.
• To fix: either file upstream against Flex firmware (Flex 8400 / fw 4.2), or add a client-side re-push workaround in SliceModel modeled on the rtty_mark pattern.
• Open question for maintainer: is this confirmed on other DSP levels (NR, NB, ANF, NRL, NRF, ANFL) on the same firmware? If only NRS is affected, that's strong evidence of a firmware-specific persistence bug worth filing upstream rather than papering over in the client.

Suggesting the upstream label be added if the maintainer agrees this is firmware-side; leaving it off for now pending confirmation.

---

_{📍 Citation health check (Foundry Constitution Principle I): 2 resolved, 6 unresolved against /Users/aetherclaude/workspace/AetherSDR at origin/main.}

Unresolved citations (6)

Citation	Reason
MainWindow.cpp:9149	file not found in workspace
RadioModel.cpp:4747	file not found in workspace
SliceModel.cpp:745-748	file not found in workspace
SliceModel.cpp:788-797	file not found in workspace
SliceModel.h:297	file not found in workspace
SliceModel.h:314	file not found in workspace

[jensenpat]

@AetherClaude is this a client persistence issue or are we sending NRS state to radio?

[aethersdr-agent]

@jensenpat Good question — short answer: neither. We send NRS to the radio when you change it, but we don't separately persist it client-side. The radio itself owns persistence via profile global.

What the client does:

• When you move the NRS slider, SliceModel::setNrsLevel() immediately sends to the radio (src/models/SliceModel.cpp:223-230):

  sendCommand(QString("slice set %1 speex_nr_level=%2").arg(m_id).arg(v));

• When the radio reports slice state back, we parse speex_nr_level= and update our copy (src/models/SliceModel.cpp:745-748). That's the full plumbing — no client-side save/restore.
• RadioModel::loadGlobalProfile() is a bare passthrough (src/models/RadioModel.cpp:4762-4765) — it just sends profile global load "<name>" and trusts the radio's snapshot.

So what's resetting to 50? Either (a) the Flex firmware's profile global snapshot doesn't include speex_nr_level, so on recall the radio restores other slice fields but NRS reverts to the firmware default of 50, or (b) the firmware never reports speex_nr_level= after the recall so our freshly-constructed SliceModel keeps its in-memory default of 50 (src/models/SliceModel.h:297). Either way the value is being lost on the radio side of the round-trip, not in our client.

Quickest way to confirm which it is: capture the TCP traffic to the radio during a recall and grep for speex_nr_level in the slice status burst that follows profile global load. If it's absent or =50, that's firmware. We can also tell by setting NRS to 30, saving the profile, then immediately recalling (no client restart) — if it still goes to 50, the profile snapshot is definitely missing the field.

Likely path forward:

1. Preferred: report to Flex so a future firmware persists speex_nr_level in profile global snapshots.
2. Client workaround (if upstream isn't viable): mirror the existing rtty_mark precedent (src/models/SliceModel.cpp:788-797) — cache the user's last-set NRS Level per slice with an explicit user-override flag, and after a profile load completes, re-push it if the radio comes back at the firmware default. Sketch:

   // header: add alongside m_rttyMarkUserOverride
   int  m_nrsLevelUser{50};
   bool m_nrsLevelUserOverride{false};
   
   // setNrsLevel(): mark as user-chosen
   m_nrsLevelUser = v;
   m_nrsLevelUserOverride = true;
   
   // status parser (replacing lines 745-748):
   if (kvs.contains("speex_nr_level")) {
       int v = kvs["speex_nr_level"].toInt();
       if (v == 50 && m_nrsLevelUserOverride && m_nrsLevelUser != 50) {
           v = m_nrsLevelUser;
           sendCommand(QString("slice set %1 speex_nr_level=%2").arg(m_id).arg(v));
       }
       if (m_nrsLevel != v) { m_nrsLevel = v; emit nrsLevelChanged(v); }
   }

   Caveat: this would also override an intentional per-profile NRS=50, which is why the override flag matters.

One thing worth checking first: does the same reset happen for NR, NB, ANF, NRL, NRF, ANFL on this firmware? If only NRS resets, that's strong evidence of a firmware-specific persistence gap and worth filing upstream. If they all reset, it's a broader profile-snapshot gap and the client workaround pattern would need to cover all of them.

A maintainer can authorize the orchestrator to land the client-side workaround by adding the aetherclaude-eligible label.

73, Jeremy KK7GWY & Claude (AI dev partner)