Here is the complete bug report, ready to paste into GitHub:
Title: Waterfall/spectrum stuck on "Connecting to radio" at launch; VFO and RHS controls functional (Windows, FLEX-6600 fw 4.2.18.41174)
What happened?
On launch, AetherSDR establishes a TCP connection to the FLEX-6600 successfully — the right-hand panel controls (VFO frequency display, tune, mode selectors, etc.) are responsive and appear to reflect radio state — but the SpectrumWidget remains frozen on the "Connecting to radio" overlay indefinitely. No FFT spectrum or waterfall data is ever rendered. The display does not recover without restarting the application. The issue is fully reproducible on launch.
What did you expect?
After a successful connection, the SpectrumWidget should begin rendering the live FFT spectrum (PCC 0x8003) and scrolling waterfall tiles (PCC 0x8004) within a second or two of the radio completing its VITA-49 UDP stream setup. The "Connecting to radio" overlay should clear once the first FFT or waterfall VITA-49 packet is received and processed by PanadapterStream.
Steps to reproduce
- Launch AetherSDR 0.9.3 on Windows.
- In the
ConnectionPanel (left pane), confirm the FLEX-6600 appears in the radio discovery list (UDP broadcast on port 4992).
- Click Connect.
- Observe that the right-hand applet panel controls (VFO, tune, RX applet, etc.) become active and reflect radio state.
- Observe that the center
SpectrumWidget (FFT + waterfall pane) remains stuck on the "Connecting to radio" overlay.
- Wait 30–60 seconds — the display does not recover.
Radio model & firmware
- Radio: FlexRadio FLEX-6600
- Firmware: 4.2.18.41174
OS & version
- OS: Windows (version not specified)
- AetherSDR: 0.9.3
- Qt: 6.7.3
Developer Notes
Symptom analysis
The fact that the VFO, tune, and RHS controls are functional confirms that the TCP command channel on port 4992 is healthy — RadioConnection is receiving V, H, and S status messages, and RadioModel / SliceModel are being populated correctly.
The "Connecting to radio" overlay in SpectrumWidget is shown when no VITA-49 FFT or waterfall packets have been received. This points squarely at the VITA-49 UDP path (PanadapterStream, UDP port 4991) failing silently — the radio is either not sending packets to the client's UDP port, or the packets are being sent but blocked or dropped before PanadapterStream can process them.
Most likely root causes
1. Windows Firewall blocking inbound UDP (most probable)
On Windows, inbound UDP traffic on ephemeral or application-defined ports is blocked by default unless an exception is created. The VITA-49 stream (port 4991 or the dynamically bound PanadapterStream port) is the most likely victim. The TCP connection succeeds because outbound TCP is generally unrestricted, but inbound UDP packets from the radio carrying FFT/waterfall data are silently dropped by the firewall.
To test: Temporarily disable Windows Firewall (or add an inbound UDP rule for AetherSDR) and retry. If the waterfall appears, this is confirmed.
2. UDP port registration step failing or not completing
Per the connection sequence in RadioModel (step 4–5 of the protocol), AetherSDR must:
- Bind the UDP socket in
PanadapterStream
- Send a single
\x00 byte to radio:4992 to punch a NAT hole / register the source port
- Issue
client udpport <port> so the radio knows where to send VITA-49 packets
On firmware v4.2.18.41174, the behavior of client udpport may differ from v1.4.0.0 (where error 0x50001000 was expected and handled). If the firmware v4.x returns a different response code that RadioConnection treats as a fatal error, it may silently abort the stream setup before the radio begins sending VITA-49 data.
3. PanadapterStream socket binding to wrong interface on Windows
If PanadapterStream binds to 0.0.0.0 (all interfaces) and the radio is on a different subnet or VLAN than the default route, Windows may not deliver the UDP packets to the socket. On Linux, SO_REUSEADDR / SO_REUSEPORT semantics also differ from Windows.
4. Stream ID filtering mismatch (less likely but possible)
PanadapterStream::setOwnedStreamIds(panId, wfId) filters VITA-49 packets by stream ID. If the display pan / display waterfall status messages arrive out of order or are parsed with the wrong handle on this firmware version, the owned stream IDs may never be set, causing all received packets to be silently dropped in the PCC router.
Files and functions to investigate
| File |
Area of interest |
| src/core/PanadapterStream.cpp |
UDP socket bind, setOwnedStreamIds(), PCC dispatcher |
| src/core/RadioConnection.cpp |
client udpport response handler — check error code branch for fw 4.x |
| src/models/RadioModel.cpp |
Connection sequence steps 4–7; createDefaultSlice() / SmartConnect path; m_ownedSliceIds population timing |
| src/gui/SpectrumWidget.cpp |
Condition that clears "Connecting to radio" overlay — verify it fires on first updateSpectrum() or updateWaterfallRow() call |
| src/gui/ConnectionPanel.cpp |
Connect button state machine |
Logging to enable
In Help → Support, enable the following diagnostic categories before connecting, then share the full log bundle:
RadioConnection — will show the full V/H/R/S/M protocol exchange, including the client udpport response code from this firmware versionPanadapterStream — will confirm whether the UDP socket binds successfully, which port is used, whether any VITA-49 packets arrive, and whether any are dropped by the stream ID filterRadioModel — will show the connection sequence state machine, slice discovery, and when (if ever) setOwnedStreamIds() is called with valid pan/waterfall IDs
A Wireshark capture on the host NIC filtering for udp.port == 4991 during a connect attempt would definitively confirm whether the radio is sending VITA-49 packets at all and whether they are arriving at the host.
Aether_Hang.txt
support-bundle-20260430-110356.zip
Here is the complete bug report, ready to paste into GitHub:
Title: Waterfall/spectrum stuck on "Connecting to radio" at launch; VFO and RHS controls functional (Windows, FLEX-6600 fw 4.2.18.41174)
What happened?
On launch, AetherSDR establishes a TCP connection to the FLEX-6600 successfully — the right-hand panel controls (VFO frequency display, tune, mode selectors, etc.) are responsive and appear to reflect radio state — but the
SpectrumWidgetremains frozen on the "Connecting to radio" overlay indefinitely. No FFT spectrum or waterfall data is ever rendered. The display does not recover without restarting the application. The issue is fully reproducible on launch.What did you expect?
After a successful connection, the
SpectrumWidgetshould begin rendering the live FFT spectrum (PCC0x8003) and scrolling waterfall tiles (PCC0x8004) within a second or two of the radio completing its VITA-49 UDP stream setup. The "Connecting to radio" overlay should clear once the first FFT or waterfall VITA-49 packet is received and processed byPanadapterStream.Steps to reproduce
ConnectionPanel(left pane), confirm the FLEX-6600 appears in the radio discovery list (UDP broadcast on port 4992).SpectrumWidget(FFT + waterfall pane) remains stuck on the "Connecting to radio" overlay.Radio model & firmware
OS & version
Developer Notes
Symptom analysis
The fact that the VFO, tune, and RHS controls are functional confirms that the TCP command channel on port 4992 is healthy —
RadioConnectionis receivingV,H, andSstatus messages, andRadioModel/SliceModelare being populated correctly.The "Connecting to radio" overlay in
SpectrumWidgetis shown when no VITA-49 FFT or waterfall packets have been received. This points squarely at the VITA-49 UDP path (PanadapterStream, UDP port 4991) failing silently — the radio is either not sending packets to the client's UDP port, or the packets are being sent but blocked or dropped beforePanadapterStreamcan process them.Most likely root causes
1. Windows Firewall blocking inbound UDP (most probable)
On Windows, inbound UDP traffic on ephemeral or application-defined ports is blocked by default unless an exception is created. The VITA-49 stream (port 4991 or the dynamically bound
PanadapterStreamport) is the most likely victim. The TCP connection succeeds because outbound TCP is generally unrestricted, but inbound UDP packets from the radio carrying FFT/waterfall data are silently dropped by the firewall.2. UDP port registration step failing or not completing
Per the connection sequence in
RadioModel(step 4–5 of the protocol), AetherSDR must:PanadapterStream\x00byte toradio:4992to punch a NAT hole / register the source portclient udpport <port>so the radio knows where to send VITA-49 packetsOn firmware v4.2.18.41174, the behavior of
client udpportmay differ from v1.4.0.0 (where error0x50001000was expected and handled). If the firmware v4.x returns a different response code thatRadioConnectiontreats as a fatal error, it may silently abort the stream setup before the radio begins sending VITA-49 data.3.
PanadapterStreamsocket binding to wrong interface on WindowsIf
PanadapterStreambinds to0.0.0.0(all interfaces) and the radio is on a different subnet or VLAN than the default route, Windows may not deliver the UDP packets to the socket. On Linux,SO_REUSEADDR/SO_REUSEPORTsemantics also differ from Windows.4. Stream ID filtering mismatch (less likely but possible)
PanadapterStream::setOwnedStreamIds(panId, wfId)filters VITA-49 packets by stream ID. If thedisplay pan/display waterfallstatus messages arrive out of order or are parsed with the wrong handle on this firmware version, the owned stream IDs may never be set, causing all received packets to be silently dropped in the PCC router.Files and functions to investigate
Logging to enable
In Help → Support, enable the following diagnostic categories before connecting, then share the full log bundle:
RadioConnection— will show the full V/H/R/S/M protocol exchange, including theclient udpportresponse code from this firmware versionPanadapterStream— will confirm whether the UDP socket binds successfully, which port is used, whether any VITA-49 packets arrive, and whether any are dropped by the stream ID filterRadioModel— will show the connection sequence state machine, slice discovery, and when (if ever)setOwnedStreamIds()is called with valid pan/waterfall IDsA Wireshark capture on the host NIC filtering for
udp.port == 4991during a connect attempt would definitively confirm whether the radio is sending VITA-49 packets at all and whether they are arriving at the host.Aether_Hang.txt
support-bundle-20260430-110356.zip