Multi-panadapter: 2nd panadapter loses FFT spectrum (waterfall continues), cannot be closed — persistent across reboot and sole-client reconnect

[chibondking]

Multi-panadapter: 2nd panadapter loses FFT spectrum (waterfall continues), cannot be closed — persistent across reboot and sole-client reconnect

Labels: bug, spectrum, priority: high
Related: #152 (multi-panadapter support)

Edit: This is a pretty complicated issue

What

In a specific Multi-Flex scenario involving three slices across two clients,
AetherSDR's second panadapter enters a broken state where:

1. The FFT spectrum display is blank — no signal trace, no noise floor,
   nothing.
2. The waterfall continues to scroll and display signals normally.
3. The broken state persists across radio reboot and across
   AetherSDR-only reconnect (disconnecting SSDR entirely does not
   recover it).
4. The second panadapter cannot be closed from within AetherSDR while
   in this state.

---

Scenario That Triggers the Bug

SSDR connects first  → gets Slice A (Pan 1)
AetherSDR connects   → gets Slice B (Pan 1) + Slice C (Pan 2)  [Multi-Flex]

Radio glitches.

Result: Slice C / Pan 2 in AetherSDR shows waterfall only — no FFT spectrum.
        Pan 2 close button is non-functional.
        Rebooting radio does not recover.
        Disconnecting SSDR, reconnecting AetherSDR alone does not recover.

Note: a separate but related bug exists where connecting AetherSDR without
SSDR also results in unexpected slice assignment (should get A & B, gets
different assignments) — see "Related Bugs" section below.

---

Steps to Reproduce

1. Connect SSDR to the radio. Confirm it holds Slice A on Pan 1.
2. Connect AetherSDR in Multi-Flex. Confirm it gets Slice B on Pan 1 and
   Slice C on Pan 2.
3. Allow or induce a radio glitch (power fluctuation, network hiccup,
   firmware watchdog reset, or rapid connect/disconnect cycling).
4. After the glitch, observe AetherSDR's Pan 2:
   • Expected: FFT spectrum and waterfall both display normally on Pan 2.
   • Actual: FFT spectrum is blank. Waterfall scrolls normally.
5. Attempt to close Pan 2 via its close button.
   • Expected: Pan 2 closes and AetherSDR returns to single-pan layout.
   • Actual: close button has no effect. Pan 2 cannot be dismissed.
6. Reboot the radio. Reconnect AetherSDR.
   • Expected: recovered state — Pan 2 FFT works normally.
   • Actual: blank FFT on Pan 2 persists. State survived the reboot.
7. Disconnect SSDR entirely. Reconnect AetherSDR as sole client.
   • Expected: recovered state.
   • Actual: blank FFT on Pan 2 still persists.

---

Why This Is Non-Trivial

The waterfall continuing while the FFT is blank is the critical diagnostic
clue. Both displays are fed from VITA-49 UDP packets but via different
PCCs:

• FFT spectrum bins → PCC 0x8003
• Waterfall tiles → PCC 0x8004

The fact that 0x8004 (waterfall) is arriving and being rendered while
0x8003 (FFT) is not means the VITA-49 stream for Pan 2 is partially
alive. This points to one of:

1. The radio is sending PCC 0x8004 but not 0x8003 for Pan 2's
   stream ID after the glitch — the radio-side FFT stream for that
   panadapter stalled or was not restarted.
2. PanadapterStream is receiving 0x8003 packets for Pan 2 but
   routing them to the wrong SpectrumWidget — a stream ID mismatch
   after the glitch caused setOwnedStreamIds() to associate Pan 2's
   FFT stream ID with a stale or incorrect value.
3. SpectrumWidget for Pan 2 is receiving FFT data but not rendering
   it — a paint path failure specific to the second widget instance,
   possibly a QWidget::update() call that stopped being invoked after
   the glitch.

The persistence across radio reboot eliminates hypothesis (1) as the sole
cause — if the radio were simply not sending the FFT stream, a reboot
would reset it. The persistence across sole-client reconnect strongly
implicates a corrupt client-side state in AetherSDR that survives
disconnect/reconnect: specifically, a stale stream ID, a broken signal
connection between PanadapterStream and the second SpectrumWidget, or
a PanadapterStack layout state that does not fully reinitialise on
reconnect.

The inability to close Pan 2 is a separate but related symptom: the close
button's handler likely checks a state flag (stream active, model valid,
etc.) that is stuck in an inconsistent value after the glitch, causing the
guard condition to block the close action.

---

Suggested Debugging Steps

1. Capture a diagnostic log during the broken state with the
   PanadapterStream logging category enabled. Confirm whether PCC
   0x8003 packets for Pan 2's stream ID are arriving at
   PanadapterStream. If they are arriving but not reaching
   SpectrumWidget, the routing is broken. If they are not arriving, the
   radio stopped sending the FFT stream.

2. Check setOwnedStreamIds() — after the glitch, confirm that
   PanadapterStream still has the correct Pan 2 FFT stream ID
   (0x8003) registered. If the stream ID changed after the glitch (the
   radio may assign a new stream ID on reconnect) and
   setOwnedStreamIds() was not called with the updated value, all Pan 2
   FFT packets would be silently dropped.

3. Check PanadapterStack reinitialisation on reconnect — confirm
   that wirePanadapter() is called for Pan 2 on every reconnect, not
   just on initial creation. If the signal connections between
   PanadapterStream and SpectrumWidget for Pan 2 are established once
   at creation and then broken by a disconnect/reconnect cycle without
   being rewired, FFT updates would stop arriving at the widget.

4. Check the Pan 2 close button handler — identify what condition is
   blocking the close action and why it is stuck after the glitch.

---

Related Bugs

Separate bug: wrong slice assignment when connecting without SSDR

When connecting AetherSDR as the sole client (SSDR not connected),
AetherSDR should receive Slices A and B. Instead it receives unexpected
slice assignments. This suggests RadioModel's SmartConnect logic
(which calls slice get <id> for existing slices rather than creating
new ones) may be interacting incorrectly with the radio's slice allocation
when no other client session is present. This warrants its own issue but
shares the slice/panadapter assignment code path with the primary bug.

---

Protocol Hints

VITA-49 stream IDs for Pan 2 (observed values from CLAUDE.md)

• FFT stream: same as panadapter object ID (e.g. 0x40000001 for Pan 2)
• Waterfall stream: 0x42000001 for Pan 2

Re-requesting the FFT stream (if radio stopped sending)

// The panadapter create command that established Pan 2's FFT stream:
display panafall create x=100 y=100
// On reconnect, if stream ID changed, AetherSDR must call:
client udpport <port>   // re-register UDP port
// and re-subscribe to the new stream ID

Checking stream registration

Add a log entry in PanadapterStream::setOwnedStreamIds() to capture the
exact FFT and waterfall stream IDs registered for each pan at connect time
and after any reconnect. Compare these against the stream IDs seen in
arriving VITA-49 packets during the broken state.

Relevant source locations

• src/core/PanadapterStream — setOwnedStreamIds(), PCC 0x8003
  dispatch path; add logging to confirm Pan 2 FFT packets are arriving
  and being routed
• src/gui/SpectrumWidget — updateSpectrum(): confirm it is being
  called for the Pan 2 instance and that QWidget::update() is invoked
• src/gui/PanadapterStack — pan creation, wirePanadapter() call on
  reconnect, close button handler and its guard condition
• src/models/RadioModel — SmartConnect slice get logic; pan stream
  ID capture and setOwnedStreamIds() call on reconnect

[ten9876]

Thanks CJ — great write-up as always.

Most likely root cause: xpixels/ypixels not pushed for Pan 2 on session restore

We confirmed in our multi-pan debugging that the radio defaults to xpixels=50 ypixels=20 for each pan. Without pushing actual widget dimensions via display pan set <panId> xpixels=<W> ypixels=<H>, the radio sends essentially empty FFT bins. Waterfall tiles are unaffected because they carry their own resolution in the VITA-49 tile header.

When the radio restores pans from the GUIClientID session, it resets xpixels/ypixels to the 50x20 default. SmartSDR pushes dimensions for EVERY pan immediately after connect (confirmed from pcap). We push dimensions on panadapterAdded but may not be pushing for pans that the radio restored from the session (vs ones we created).

Fix plan

1. When panadapterAdded fires, always push xpixels/ypixels for the new pan regardless of whether we created it or the radio restored it
2. Verify this happens for all pans, not just the first one
3. The "cannot close" issue is likely the +PAN / layout picker flow not having a "reduce to N-1 pans" option — we only close extras when switching layouts

The Multi-Flex slice assignment issue

This is a separate concern. When AetherSDR connects after SSDR disconnects, the radio may still have SSDR's slices in memory. Our SmartConnect logic calls slice get <id> for existing slices, but if those slices belonged to the other client, we may be adopting orphaned slices. This needs a separate investigation.

Will investigate after the current session.

73, Jeremy KK7GWY & Claude (AI dev partner)

[ten9876]

Update: xpixels push verified for all pans

Checked the logs from a 3-pan session restore — all three pans get display pan set <panId> xpixels=<W> ypixels=<H> immediately on panadapterAdded. The dimensions are correct (actual widget sizes or 1024x700 fallback).

Remaining suspects for Multi-Flex case

Since this only happens in Multi-Flex (SSDR + AetherSDR), the likely cause is one of:

1. Multi-Flex filter rejecting FFT-related status — pan 2's display pan status with dBm range might carry the other client's handle, causing our filter to drop it. Without dBm range, FFT bins convert to all-zero.

2. Stream ID conflict — in Multi-Flex, both clients get their own pan IDs. If SSDR's pan 0x40000001 shares a stream ID with our pan 0x40000001, the PanadapterStream would route FFT frames from the wrong client's pan.

3. xpixels race — our xpixels push might arrive before the radio has fully initialized pan 2 in Multi-Flex mode (the second client's pans take longer to set up).

Fix: defensive xpixels re-push + FFT health check

Added a 3-second delayed re-push of xpixels for all owned pans after connect completes. This covers the race condition where the radio hadn't finished setting up the pan when our initial push arrived.

Need a Multi-Flex test to verify — CJ, can you test the next build with both SSDR and AetherSDR connected?

73, Jeremy KK7GWY & Claude (AI dev partner)

[chibondking]

RR, can test... will be in the morning here in Illinois.

…

On Tue, Mar 24, 2026 at 11:57 PM Ten98 ***@***.***> wrote: *ten9876* left a comment (aethersdr/AetherSDR#268) <#268 (comment)> Update: xpixels push verified for all pans Checked the logs from a 3-pan session restore — all three pans get display pan set <panId> xpixels=<W> ypixels=<H> immediately on panadapterAdded. The dimensions are correct (actual widget sizes or 1024x700 fallback). Remaining suspects for Multi-Flex case Since this only happens in Multi-Flex (SSDR + AetherSDR), the likely cause is one of: 1. *Multi-Flex filter rejecting FFT-related status* — pan 2's display pan status with dBm range might carry the other client's handle, causing our filter to drop it. Without dBm range, FFT bins convert to all-zero. 2. *Stream ID conflict* — in Multi-Flex, both clients get their own pan IDs. If SSDR's pan 0x40000001 shares a stream ID with our pan 0x40000001, the PanadapterStream would route FFT frames from the wrong client's pan. 3. *xpixels race* — our xpixels push might arrive before the radio has fully initialized pan 2 in Multi-Flex mode (the second client's pans take longer to set up). Fix: defensive xpixels re-push + FFT health check Added a 3-second delayed re-push of xpixels for all owned pans after connect completes. This covers the race condition where the radio hadn't finished setting up the pan when our initial push arrived. Need a Multi-Flex test to verify — CJ, can you test the next build with both SSDR and AetherSDR connected? 73, Jeremy KK7GWY & Claude (AI dev partner) — Reply to this email directly, view it on GitHub <#268>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADAZSGLO3PTKYY2HDXBRCL4SNRLPAVCNFSM6AAAAACW6IN2FWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DCMRTGUZDOOBTGI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

-- "But when you're passionate you can do anything." Michael Milken

[ten9876]

Several fixes have shipped targeting this exact issue:

• 3bae013 — Defensive xpixels re-push 3s after layout restore for Multi-Flex (filed against this issue)
• ae3ed76 — Close pan via X button: remove pan and rearrange remaining layout (On restart, AetherSDR restores persisted broken panadapter state instead of defaulting to single-pan safe mode #269) — fixes the "can't close Pan 2" symptom
• 153594c — Fix multi-pan restore: accept radio's pans, don't create or remove (On restart, AetherSDR restores persisted broken panadapter state instead of defaulting to single-pan safe mode #269)
• 9a5f77a / 282e85a — Force single-pan on launch while multi-pan is experimental (On restart, AetherSDR restores persisted broken panadapter state instead of defaulting to single-pan safe mode #269) — sidesteps the corrupt 2-pan state by closing extra pans on startup
• e2784fd — Fix profile load blank spectrum: detect when radio resets xpixels to defaults during profile load and auto re-push (v0.7.3: applying a global profile loses spectrum display #289)
• 04310f6 — Reduce xpixels re-push delay from 3s to 500ms
• 1e61edd — Fix multi-pan slice lifecycle: +RX routing, titles, CW decode (MultiPan: Clicking +RX in second pan creates Slice Flag in first pan #301)

The current state (v0.7.9): AetherSDR forces single-pan mode on launch (282e85a), which prevents the corrupt 2-pan state from persisting across restarts. The close button now works (ae3ed76). The xpixels re-push is more aggressive (04310f6, 3bae013).

Multi-pan remains experimental and the single-pan-on-launch guard is still in place. When multi-pan is promoted to stable, the full stream ID rewiring on reconnect will need to be bulletproof. For now the guard prevents this scenario.

73, Jeremy KK7GWY & Claude (AI dev partner)

[jensenpat]

Cross-reference for the duplicate-panadapter family: PR #3316 (for #3212) closes another path that produced an extra pan on reconnect.

Same principle as the #269 layout fix (don't create pans on top of the ones the radio's GUIClientID session already restored), but in the slice list-empty branch of RadioModel::registerAsGuiClient: when the radio restored our pan without its slice, the empty slice list triggered createDefaultSlice() → display panafall create, leaving a second, slice-less pan. #3316 reuses the restored pan instead (and seeds the recovered slice at the pan's own center). Root cause confirmed from the #3212 support-bundle log.