Summary

Fixes #2194 by making AetherSDR's startup panadapter creation resilient when SmartSDR, DAX, or another GUI/audio client is already connected to the radio.

The primary startup path now matches FlexLib v4.2.18 and creates a display pair with:

display panafall create x=100 y=100

If older firmware rejects that command, AetherSDR falls back to the legacy:

panadapter create

The fix also hardens status handling so AetherSDR can recover when panadapter or waterfall ownership status arrives out of order during multi-client startup.

Fixes #2194, #2210, #2203, #2221, #2223, #2224

Root Cause

When SmartSDR DAX is already running, the radio is not starting from a quiet single-client state. On connect, AetherSDR receives status for all current radio objects, including slices, pans, waterfalls, DAX streams, and TX/audio streams associated with other client handles.

AetherSDR correctly filters these objects by client_handle so it does not accidentally adopt SmartSDR/DAX-owned state. The failure came from the interaction between that filtering and the startup fallback:

1. AetherSDR connects and registers as a GUI client.
2. The radio replays status for multiple clients.
3. AetherSDR rejects non-owned slices and panadapters, as intended.
4. slice list can still return non-empty because slices exist globally on the radio.
5. AetherSDR may still have no owned slice after filtering.
6. The deferred startup fallback creates a default pan and slice for AetherSDR.
7. That fallback used the older bare panadapter create command and waited too heavily on later pan ownership status.
8. If display pan status was delayed, interleaved, or first arrived without client_handle, AetherSDR could fail to instantiate a PanadapterModel.

Without a PanadapterModel, FFT and waterfall stream IDs are not registered with PanadapterStream, so VITA-49 data never reaches the UI and the startup "getting ready" path can remain stuck.

Why DAX Exposed This

The SmartSDR DAX app creates exactly the kind of multi-client environment that stresses this path:

• the radio reports globally existing slices even when they belong to another client
• DAX and SmartSDR stream status includes separate client_handle ownership
• pan/waterfall/slice status can be interleaved with AetherSDR's own startup sequence
• AetherSDR must reject other clients' objects, then create or claim its own objects

So the issue is broader than firmware 4.2.18. The newer firmware and FlexLib API made it more visible, but the underlying bug was that AetherSDR's owned-pan startup path was too dependent on later, perfectly ordered ownership status.

Implementation

This PR changes RadioModel in a few coordinated ways:

• Adds normalized panadapter ID parsing for command responses that may return either pan=0x..., id=0x..., or a bare stream ID.
• Adds ensureOwnedPanadapter() to create and register a PanadapterModel as soon as AetherSDR has an owned pan ID.
• Updates manual and startup pan creation to try display panafall create x=100 y=100 first, matching FlexLib v4.2.18.
• Keeps compatibility with older firmware by retrying panadapter create if display panafall create fails.
• Defers early display pan status that lacks client_handle instead of dropping it permanently.
• Replays deferred pan status once ownership is confirmed.
• Uses owned waterfall status with panadapter=... to recover the parent pan/waterfall association if waterfall status arrives before a complete pan status.
• Emits the existing status-bar capacity signals when pan or slice creation ultimately fails, so true radio resource exhaustion is visible instead of looking like a startup hang.

Compatibility

Older firmware should continue to work. The new command is tried first because it is what current FlexLib uses, but any rejection falls back to the legacy panadapter create command.

This is intentionally capability-based rather than a hard firmware-version gate. The radio/API behavior varies enough across model and firmware combinations that "try current command, fall back to legacy command" is safer than guessing from version strings.

Panadapter and Waterfall Sizing

display panafall create x=100 y=100 is only the creation request for the paired display object. It does not set the final UI stream dimensions.

AetherSDR still pushes real dimensions after the PanadapterModel exists with:

display pan set <pan_id> xpixels=<widget_width> ypixels=<widget_height>

That matches FlexLib's model: panadapter width/height drive display pan set ... xpixels/ypixels, while waterfall width/height do not send separate pixel sizing commands. Final FFT/waterfall sizing is therefore still controlled by AetherSDR's widget-dimension path, not by the initial x=100 y=100 create command.

User Impact

Users should be able to start AetherSDR while SmartSDR DAX or another client is already connected, as long as the radio still has available pan/slice capacity.

If the radio is genuinely out of resources, AetherSDR now routes that failure through the existing status-bar messages instead of silently failing to get a panadapter.

Validation

• Reviewed issue Failure to start AetherSDR properly when either Flex CAT or DAX is already connected to radio #2194 and the attached user logs.
• Compared AetherSDR's startup path with FlexLib v4.2.18.41174.
• Confirmed FlexLib uses display panafall create x=100 y=100.
• Built successfully:

cmake --build build -j10

• Ran CTest discovery:

ctest --test-dir build --output-on-failure -j10

CTest completed successfully but reported no registered tests in this build tree.

👨🏼‍💻 Generated with OpenAI Codex (GPT-5.5 Pro 4/23) and tested by @jensenpat