Title: AetherSDR hangs on startup when SmartSDR CAT or DAX is already connected (FLEX-6600 fw 4.2.18)

What happened?

When launching AetherSDR while either SmartSDR CAT or DAX is already connected to the radio, the application hangs indefinitely on the startup screen:

“Connecting to radio – Getting everything ready”

The UI never progresses past this point and appears stalled. From observation, it looks like the panadapter (display stream) is never created or initialized, preventing the client from completing its startup sequence.

This issue began after upgrading the radio firmware to 4.2.18.41174. Prior to that version, AetherSDR could start normally even when CAT or DAX sessions were already active.

The problem is consistent and reproducible whenever CAT or DAX is connected before launching AetherSDR.

What did you expect?

AetherSDR should successfully connect to the radio and complete initialization regardless of whether other clients (e.g., SmartSDR CAT or DAX) are already connected.

Specifically:

• The client should negotiate a GUI client session correctly
• A panadapter should be created and initialized
• The application should proceed past the “Getting everything ready” stage and become fully usable

Steps to reproduce

1. Start SmartSDR CAT and/or DAX and connect them to the FLEX-6600

2. Launch AetherSDR (v0.9.3)

3. Observe the startup process

4. Application hangs at:

   • “Connecting to radio – Getting everything ready”

5. Close CAT/DAX and retry launching AetherSDR

6. AetherSDR starts normally when no other clients are connected

Radio model & firmware

• FLEX-6600
• Firmware: 4.2.18.41174

OS & version

• Windows (version not specified)

Developer Notes

Based on the AetherSDR architecture (per CLAUDE.md), this issue likely occurs during the client initialization and resource negotiation phase after establishing the TCP command connection.

Likely areas involved

Client session initialization & radio negotiation

• src/radio/Radio.cpp

  • Functions handling connection lifecycle, especially:

    • Radio::connectToRadio()
    • Radio::onStatusMessage(...)
    • Radio::handleClientHandle(...)

Panadapter creation flow

• src/radio/Panadapter.cpp

  • Creation and binding of panadapter streams

• src/radio/Radio.cpp

  • Likely logic around issuing:

    display panadapter create ...
    

  • And handling responses like:

    R <seq>|0|<panadapter_id>
    

State synchronization / discovery

• src/protocol/CommandParser.cpp or similar

  • Parsing incoming status (S|...) messages

• src/radio/RadioState.cpp

  • Tracking existing GUI clients, panadapters, slices

Hypothesis

Firmware 4.2.18 may have changed behavior related to:

• Multi-client coexistence
• Resource ownership (panadapters, slices)
• Or ordering/timing of status messages during client attachment

Possible failure modes:

1. Panadapter creation command is not sent

   • Due to incorrect assumption about existing resources

2. Panadapter creation fails silently

   • Error response not handled properly

3. Client waits indefinitely for a status message

   • That is never emitted when other clients already hold resources

4. Race condition during initial status sync

   • Especially if CAT/DAX alter the sequence or timing of messages

5. GUI client handle negotiation issue

   • Radio may treat AetherSDR differently when other clients are active

Logging recommendations

To diagnose, enable verbose logging via:

Help → Support → Enable Logging Categories:

• radio
• protocol
• connection
• panadapter
• client
• dax (if available)

Specific things to look for in logs

• Whether display panadapter create is issued

• Response to that command (success or error)

• Presence/absence of:

  • panadapter status messages
  • client status messages

• Any error codes returned by the radio

• Whether the client receives a valid GUI client handle

• Whether initialization state machine stalls waiting for a missing event

Potential fixes to investigate

• Ensure panadapter creation is always attempted regardless of existing clients
• Add timeout/fallback if panadapter is not created within expected time
• Improve handling of “resource already in use” responses
• Explicitly request or reclaim a panadapter if none is assigned
• Harden initialization state machine against missing or reordered messages

This appears to be a regression triggered by firmware 4.2.18 interaction with multi-client scenarios, particularly affecting panadapter initialization during startup.

support-bundle-20260430-075753.zip