aethersdr/AetherSDR

Report preparation I used the AI-assisted bug report tool (Help → Support → File an Issue) I have attached a support bundle or log file What happened? The Aetherial Audio channel strip cannot be found in the DSP tab. Greg WK0B What did you expect? No response Steps to reproduce connect to flex 660 nide set ti ssb open DSP no Aetherial Audio channel strip to select AetherSDR version 26.10.1 Radio model & firmware Flex 4.2 Operating system Windows OS version and hardware 11 pro

What happened? With Frameless Window off, a popped-out panadapter's native window title shows raw HTML markup: AetherSDR — Slice A₁ The panadapter's own header strip inside the same window renders the label correctly, as "Slice A" with a subscript 1. What did you expect? The window title should read as plain text, for example AetherSDR — Slice A1, with no HTML tags. The title bar, taskbar and Alt+Tab all show plain text. Steps to reproduce View → Frameless Window off. Pop out a panadapter (the ⬈ button on the panadapter's header). Look at the popped-out window's title bar: it shows Slice A₁. System AetherSDR: 26.10.1 built from main on Oct 7 2026 Qt: 6.12.0 OS: Windows 10 Pro 22H2 (build 19045), x64 Renderer (Help → About): GPU QRhi (D3D11; Intel(R) HD Graphics 520) Radio: FLEX-6600, SmartSDR 4.2.20.41343, over LAN; slice A on 30 m, DIGU Screenshot To be attached in a comment: 2026-10-08 01_37_57.

Summary On Icom radios, the panadapter ANT panel's Preamp and Atten buttons can show the wrong position for up to about 3 seconds after you change the other one. The radio links the two stages and doesn't report the side effect: You do The radio also does AetherSDR's button shows ATT → 20 dB drops the preamp to OFF Preamp still P.AMP1 until the next poll ATT → OFF brings the preamp back to P.AMP1 Preamp still OFF until the next poll Preamp → P.AMP1 while ATT is on drops ATT to OFF Atten still 20 dB until the next poll The buttons do catch up. They are not stuck, but they show a state the radio isn't in. Anyone reading the panel right after a click, including an automation snapshot, sees the wrong state. Root cause IcomCivBackend::setPanPreamp() and setPanAttenuator() write their own stage and queue a confirmation read of that stage only. The other stage is re-read only by the periodic controls poll (16 02 and 11 every ~3 s). Neither change arrives unsolicited. The c

What happened? On an ANAN or an RTL-SDR, DX-cluster, RBN, WSJT-X, POTA and manual spots never reach the panadapter, while the Passive toggle is off (its default). Each one is turned into a Flex spot add command and dropped, because these two backends have no command plane. The Icom backend opts out of this path with alwaysUseClientSideSpots = true. #6020 does the same for the HL2. ANAN and RTL still inherit the false default. The review of #6020 found this and suggested a separate issue so it is not only recorded in a table (inline comment on Hl2Backend.cpp: "AnanBackend and the RTL backend inherit the same = false default and have no command plane either, so their spots are dropped identically"). This is that issue. The chain, verified at main 20d022d: RadioCapabilities::alwaysUseClientSideSpots defaults to false (src/core/backends/RadioCapabilities.h:1131). IcomCivBackend::capabilities() sets it to true (IcomCivBackend.cpp:619). AnanBackend::capabilities() (AnanBackend.cpp:402-523)

Report preparation I used the AI-assisted bug report tool (Help → Support → File an Issue) I have attached a support bundle or log file What happened? The same wideband block feeds two readings in healthSnapshot(), and they disagree about what "stale" means. One withholds; the other keeps publishing a frozen number as though it were current. Hl2Backend::healthSnapshot() gates the three Converter rows on nothing but whether a block has ever arrived: section("adcPeakDbfs", QStringLiteral("Converter")); const bool haveBlock = m_bandscopeBlock.samples > 0; const double peak = haveBlock ? m_bandscopeBlock.peakDbfs() : 0.0; const double rms = haveBlock ? m_bandscopeBlock.rmsDbfs() : 0.0; adcPeakDbfs, adcRmsDbfs and the peak-to-RMS crest row therefore publish for as long as the process lives, however old m_bandscopeBlock is. There is no age term anywhere in that path. A few hundred lines earlier, the same member is read with an explicit age and withheld when it is old: const AetherS