aethersdr/AetherSDR

Request preparation I used an AI assistant to help structure this request I checked for existing issues covering the same feature What would you like? Feature request: Allow hiding the decoded RTTY text panel Title: Allow the decoded-RTTY text panel to be hidden/disabled independently Type: Feature request Body: Problem: When RTTY mode is active, AetherSDR displays a decoded-text panel in the UI. For operators who use a third-party RTTY decoder instead (e.g. SDR Console's Digital Decoder), this panel takes up screen space and visually overlaps with the third-party decoder's own window, even when AetherSDR's own decoding isn't being used. Requested change: Add a setting (or a right-click/context-menu option on the panel itself) to hide or disable the decoded-RTTY text panel independently of RTTY mode itself — similar to how other applets/panels in AetherSDR can already be toggled or floated. This would let operators keep RTTY mode active for band/filter purposes while relying on a

Request preparation I used an AI assistant to help structure this request I checked for existing issues covering the same feature What would you like? Title Change Band Plan text formatting to non-bold font weight What Change the font styling used for region/frequency segment labels in the Band Plan overlay (rendered within SpectrumWidget / PanadapterOverlay) from bold (QFont::Bold / QFont::Weight::Bold) to a normal or light weight font. Why The current bold font weight used for rendering segment annotations across the spectrum overlay can appear heavy, overly dense, and "fat"—especially on higher DPI screens or tight frequency spans where multiple band plan segment labels overlap or cluster together. Using a regular/non-bold font weight significantly improves readability and text legibility without visually cluttering the spectrum display. How Other Clients Do It SmartSDR (FlexRadio Native): Displays band plan region labels in a clean, non-bold, light-sans typography directly o

Request preparation I used an AI assistant to help structure this request I checked for existing issues covering the same feature What would you like? Filing this as a tester report since the release notes asked for radio and firmware details from people running the experimental Icom backend. There don't appear to be many IC-9700 reports yet. Setup Radio: Icom IC-9700, firmware 1.42 AetherSDR v26.8.4, Windows 11, laptop Connection: radio's rear LAN port to a router, DHCP, radio at 10.0.0.17, laptop on the same subnet Configured in ASDR CI-V address field left blank so the auto-detect from #4991 does the work What works Connected first try after the radio-side setup was right. Confirmed on 146.520 FM: Frequency and mode read correctly and follow the radio Panadapter and waterfall both live, including the 3D view S-meter tracking RX Controls shows repeater tone (103.5), offset (0.600 MHz), and Simplex/XFC — the tone/duplex work from #5140 is reaching the radio correctly Status b

What A sensitivity/squelch control for the RTTY decoder pane, so characters demodulated from noise are dropped instead of rendered. The CW pane already has exactly this control; the RTTY path computes every ingredient it would need and currently uses them only for display. Why Between transmissions the Baudot demodulator keeps slicing noise into valid characters, so the pane fills with continuous low-confidence gibberish that buries real copy [RIG — observed on live RTTY, remote-receiver audio, 2026-08-14]. The decoder emits every decoded character unconditionally (src/core/RttyDecoder.cpp:278), and the pane appends every one of them — confidence selects only the text color (src/gui/PanadapterApplet.cpp:971-974). The RTTY toolbar offers Mark/Shift/Baud/Rev and no sensitivity control, so there is nothing the operator can adjust. Code references — the ingredients are already computed Per-character confidence is calculated and emitted with each character (src/core/RttyDecoder.cpp:2

What Add ~20 rows to the SmartSDR .map translation table (kSmartSdrMapFunctions, src/core/MidiSettings.cpp:88) mapping the vendor's direct band-select and mode-select function names to the direct-select MIDI params AetherSDR already registers. Pure data change to the importer added by #4898 — no new params, no new code paths. Why The published Lynovation SmartSDR mapping files assign a large share of their controls to direct band/mode select, and today every one of those rows imports as a named skip ("no AetherSDR equivalent") even though the equivalent exists. Measured against the vendor's public config packages (https://ctr2.lynovation.com/category/download/config/, distinct functions per map, at c02d32ce): Device map maps today with these rows CTR2-MIDI (CTR2-MIDI_SmartSDR_v1.0.map) 17/23 (73%) 18/23 (78%) CTR2-Dial v2 / Quad (SmartSDR_CTR2-Dial_v2.0.map) 27/80 (33%) 47/80 (58%) CTR2-Max (CTR2-Max_SmartSDR_v1.0.map, v100 zip) 27/75 (36%) 47/75 (62%) The CTR2-Max "27