fix(cat): don't cap running CAT ports by receiver count (#3693)#3697
Conversation
…3693) applyCatPortCount() gated each port's shouldRun on `(i < target)` where target is the radio's slice-receiver count — so a 5th+ configured CAT port on a 4-RX radio silently never started, with no error or feedback. A CAT port is a control channel, not a 1:1 mapping to a slice; receiver capacity should bound the VFO-letter choices per port (which catPortTargetCount() still feeds to the applet at setMaxSlices), not whether a configured port runs. Drop the gate so all enabled ports up to kCatPorts start. Closes #3693. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This branch's port-count decoupling (drop the `(i < target)` cap so CAT ports aren't limited by the radio's slice-receiver capacity) inherited a subtle gap: the old gate was doing double duty. catPortTargetCount() returns 1 when disconnected, so `(i < target)` also trimmed running ports back to channel A on disconnect — apps on channel A stay connected through brief reconnects, higher channels stop cleanly (see the applyCatPortCount() disconnect call site). Dropping the gate outright loses that trim (all enabled ports would stay up while disconnected). Preserve it explicitly: when connected, any enabled port (>=1024) up to kCatPorts runs; when disconnected, only port 0. setMaxSlices() keeps bounding VFO-letter choices to the radio's receiver count when connected, kCatPorts when not. (The standalone port-count PR — upstream aethersdr#3697 — omits this trim; folding the fix here so the comprehensive branch is correct.) Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
There was a problem hiding this comment.
Thanks for this, @ten9876 — the diagnosis is correct and well-explained. A CAT port is a control channel, and gating whether a configured port runs on the radio's receiver count is the wrong axis. setMaxSlices() (which still gets catPortTargetCount()) is the right place to bound VFO-letter choices. Clean, minimal, well-commented change, and CI is green across all six checks.
One interaction I'd ask you to confirm before merge, because (i < target) was quietly doing double duty:
The disconnect path relied on this same cap to trim ports back to 1. In the radio-disconnected branch (MainWindow.cpp:5033-5036):
} else {
// Radio disconnected: trim CAT ports back to 1 so apps on channel A
// stay connected through brief reconnects, higher channels stop cleanly.
applyCatPortCount(); // catPortTargetCount() returns 1 when !connectedThat "trim back to 1" was implemented entirely by (i < target), because catPortTargetCount() returns 1 when not connected. With (i < target) removed, shouldRun = masterOn && portEnabled && (portNum >= 1024) no longer has any connection dependency — so on disconnect, all enabled ports 0–7 now keep running instead of higher channels stopping cleanly. That contradicts the documented intent at line 5034 and is a behavior change beyond the PR's stated scope.
Two ways forward, your call:
- If keeping all ports up across disconnect is intended (arguably fine — clients stay parked and commands resume on reconnect), then please update the now-stale comment at
MainWindow.cpp:5034-5036so the next reader isn't misled into thinking ports still trim to 1. - If the disconnect-trim should be preserved, decouple the two concerns — e.g. keep the run decision off receiver count but re-introduce a connection guard for channels beyond 0, something like
&& (i == 0 || m_radioModel.isConnected()).
Either is reasonable; I just want the disconnect behavior to be deliberate rather than an incidental side effect of dropping the term. Nice fix otherwise.
🤖 aethersdr-agent · cost: $2.1905 · model: claude-opus-4-8
Closes #3693.
applyCatPortCount()gated each port'sshouldRunon(i < target), wheretarget= the radio's slice-receiver count. So a 5th+ configured CAT port on a 4-RX radio (most 6600/8600) silently never started — no error, no feedback.A CAT port is a control channel, not a 1:1 mapping to a slice. Receiver capacity should bound the VFO-letter choices per port — which
catPortTargetCount()still feeds to the applet viasetMaxSlices()(unchanged) — not whether a configured port runs. Dropped the(i < target)term so all enabled ports up tokCatPorts(8) start.Model-independent shared GUI code; no RFC (correctness fix). Full app builds clean.
🤖 Generated with Claude Code