FoxSDR no longer opens a console window beside its own. On Windows, starting FoxSDR from the Start Menu, the desktop shortcut, the Store tile or the installer's "Launch now" button used to open a second window as well - a black window, or a Windows Terminal window, titled cascade.exe - and keep it open for as long as FoxSDR ran; on a computer where Windows Terminal is the default, that window was on screen for the whole session. 0.99.67 made closing it safe; now it is not there at all. Running FoxSDR from a terminal works as before - --version and the other switches print in that terminal, and Ctrl+C or closing it still closes FoxSDR properly - with one change you will notice there: cmd.exe and PowerShell no longer wait for FoxSDR to finish, so at a plain prompt the answer can appear after the next prompt and the exit code is not shown (in PowerShell, piping the output, as in .\cascade.exe --version 2>&1 | Out-String, restores the wait and the exit code).
A new RADIO SETUP page says what to install when FoxSDR cannot find a radio. Of 813 installs that reported in one month, 578 reported no radio at all, and the usual reasons each have one fix: an RTL-SDR still wearing the DVB-T television driver Windows gives it (invisible to every SDR program until Zadig binds WinUSB to it), an SDRplay RSP with no SDRplay API service behind it, a USRP with no UHD, or no radio plugged in. FoxSDR used to show a receiver on the signal generator and nothing else. Now, once a launch, if the check at start-up finds no radio you can use and FoxSDR's own list is empty too, the page opens by itself. It reads the USB ports, names the driver Windows actually bound to each radio it knows (RTL-SDR, Airspy, Airspy HF+, HackRF, SDRplay RSP, USRP B2xx, LimeSDR), looks for the SDRplay API and for UHD, and writes one block per radio: what is wrong, the exact thing to install, and a link to the vendor's own page (zadig.akeo.ie, sdrplay.com, files.ettus.com, airspy.com). CHECK AGAIN reads it all again after you have installed something, "Don't show this again" keeps the page from opening by itself (it is remembered), and a RADIO SETUP key under Refresh in the Source section opens it whenever you want it. The check only reads device properties and two files and asks Windows whether the SDRplay service is running: it opens no radio, runs on a thread of its own so the window never waits for it, and sends nothing anywhere. On Linux it says it does not check radio drivers, and never opens the page.
An NFM row in the airband monitor now plays through the same 50 microsecond de-emphasis the receiver's own NFM has always had. A ground, company or utility frequency typed in (or imported) as NFM was played straight from the strip's FM discriminator, which is flat in frequency for a constant deviation, so a 3 kHz hiss came out as loud as a 1 kHz voice and the channel sounded harsh beside the receiver. Measured through the real runner, one channel alone, 3 kHz over 1 kHz at equal deviation: before, -0.01 dB; now, -2.31 dB at both 2.4 and 2.048 MS/s, where the 50 microsecond one-pole works out at -2.30 dB. AM rows, whose audio is an envelope with nothing to undo, are untouched: 0.02 dB between the same two tones, and bit-identical audio with the stage on or off. The one filter is now shared by the receiver's demodulator and the monitor, so they cannot come to disagree about what 50 microseconds means. An NFM row at 1 kHz is 0.4 dB quieter than it was (NFM against AM at their nominal modulation: 0.99, now 0.95), inside the bounds the level test already holds it to, and the level was not retuned for it.
Looking up an airport while the monitor is listening no longer changes what it plays. The lookup always put the airport's list on show, and the list on show is what the monitor plays: a monitor listening to one preset was moved onto the airport's rows under the listener's ear, and one listening to "every ticked" was narrowed to them. Adding a frequency by hand and importing a preset already left a listening monitor alone; the lookup now does the same. The airport's rows are added and ticked as ever, and when the monitor is playing a different preset the note says so - "The monitor keeps playing X; choose Y in the group list to hear it." Not listening, the lookup puts the airport on show as before.
A crash, freeze or "ended from outside" report pasted into REPORT A BUG / DISLIKE is now recognised, and upload local-only says what it means. The diagnostics you copy or attach lists the reports FoxSDR holds on your computer, and a report that is marked upload local-only stays on your computer on purpose: it is either a display-driver stall, or FoxSDR being ended from outside (Task Manager, taskkill, a log-off) while it was working normally, and neither is a fault in FoxSDR. Until now the list said only the word, and a tester on 0.99.66 pasted a whole report into the bug form to ask what it meant. The list now says why in a sentence under it, and "Show what will be sent" on the report page says it in your language, with the folder the file is in. When the text you type or paste into the box contains one of these reports, the page says so before you press SEND ("A report was recognised and attached as sentinel:outside"), and the report is sent once more beside your message with its kind and the version that wrote it, so it is filed as the report it is instead of as a paragraph of text. It is the same words you were already sending: nothing else is read, no file is opened, and an older website that does not know the new field is retried without it. From a field report on 0.99.66.
The Fitted modules window now says which module files were not installed from the plugin store and are not running, and removes one on request. A file in the plugins folder with no install record, that the catalogue does not list for this platform and that the host has not loaded (refused at load, or turned off as another copy of a plugin) was left where it was, and the only word of it was a line in the diagnostics log - "is installed but not recorded; it is left alone". Its row now reads "Not installed from the plugin store and not running:" followed by the host's own reason, word for word, and its plate explains it and carries REMOVE FILE, which deletes that one file after the same two presses as REMOVE MODULE and writes one line to the log. The rule is applied again at the moment of removal against the live scan: a file that is loaded, or that an install record or the catalogue names, is never removed by this key, whatever the window showed a moment before.
The diagnostic log, and every report, now name the other programs' DLLs that are loaded into FoxSDR. Two field deaths - 0.99.64 on an RSP1 after 48 minutes, 0.99.65 on an RTL-SDR after 12 seconds - were fast-fails in the hand-off to the graphics driver, where the overlay DLLs that other software injects into every program (an audio driver's on-screen display, a frame-rate counter, a capture or input tool) hook in, and their reports could say where the program died and nothing about what else was in it. Once the window is up FoxSDR now writes one line to the diagnostic log naming every loaded module that is neither Windows' own, nor part of FoxSDR (its folder, its plugins, its C++ runtime), nor an SDR vendor's driver file, for example modules: 3 foreign - AudioDevProps2.dll, NahimicOSD.dll, ProductInfo.dll (the three this development computer reports; NahimicOSD.dll is the overlay the only earlier death of this shape was inside), and one more, module arrived: NahimicOSD.dll (12.3 s), each time another is loaded later. The same list is the foreign-modules line in the context block of a crash report, a freeze report, the sentinel's report and Copy diagnostics, because by the time something fails the log of a long session has lost its first lines, and it is sent in the automatic crash report with the rest. These are the file names of other programs' components, never a folder or a version, and a file name can show what software is installed on your computer; files in the Windows folder are left out so that the list is short, and PRIVACY.md and the privacy page on the website say so. Nothing is written when one is unloaded, a name is written once a session, and with Diagnostics off nothing is written to disk or sent. Checked in FoxSDR's tests against the real loader on Windows 11 (a DLL loaded into the test program from a folder that is neither FoxSDR's nor Windows' is named, one from Windows is not) and in the real program's own log, a sentinel report and a freeze report; not checked on Windows 10, on a computer with a graphics-driver overlay, or on Linux, where the report line reads (not applicable). It does not by itself explain either death: it says what else was there.
The usage report now says how a session that did not end cleanly ended. FoxSDR has always counted the sessions that ended without closing normally as one number, and that number mixed a real crash with a window ended from Task Manager, a closed console window, a log off and a power cut - so a version that crashes could not be told from a person who ends the task. From this version the same count is also split four ways: FoxSDR failed (it crashed, or its window had stopped drawing and was then ended); it was ended from outside while working normally; Windows closed the session (a log off or a shutdown); or there is nothing to tell by (Diagnostics off, a power cut). The class is chosen on your computer at the next start, from the reports Diagnostics already writes there - with Diagnostics off nothing is read and every unclean exit is counted as unknown - and goes out as four bare numbers beside the crash count, never reset like it. Nothing else is added: no report text, no exit code, no module, no time of day. The same sentence is written to the diagnostic log at start-up (previous session ended: killed (...)), the Usage reporting panel lists the four numbers, and PRIVACY.md and the website's privacy page give them field by field.
The ADS-B scope's compass labels no longer read from a released string. The bearing labels around the scope's compass ring (N, 030, 060, ...) were built from a piece of text that had already been released by the time the label was drawn. On the Windows build the memory was still intact, so the labels read correctly; a memory checker (AddressSanitizer, on Windows and on Linux) reported it on every draw of the scope, and a different compiler or optimisation level could have drawn garbage in its place. No wrong label has been reported. The label text is now kept alive for the draw. Found by reading the sanitizer run nobody had read, along with a bandwidth that is not a number reaching a filter design (now the narrowest bandwidth), a signal-generator race no user path reaches, and a dozen races and deliberate leaks in the tests themselves.
The machine translations added for 0.99.66 to 0.99.68 were reviewed in German, French, Italian, Spanish and Dutch. Eighteen strings per language (the airband section's presets, add row, import and export, and the NFM wording); twelve were corrected - Dutch rows are "rijen" as everywhere else in that catalogue, not "regels"; French says the monitor "joue" the rows it has "lues" instead of "lire" them; German names the "Flugfunk-Monitor" and keeps its typographic quotes; Italian drops a stray article before "NFM". Spanish needed nothing. They are still machine translations, and every catalogue still says so in the language list.
--rtlsdr-check now notices a dongle that has stopped receiving. While this version was being checked against the bench's own RTL-SDR, the dongle turned out to have been delivering the same 1880 samples over and over since the day before, at every frequency, at exactly the right rate and a plausible level with no error - and the check, and the live test behind it, had passed on it for a day, because they counted samples and looked at their level and neither says whether the samples came from the air. A stream from the air never matches itself exactly; the check now keeps the first 32768 samples, looks for an exact repeat at any lag up to 4096 samples, and when it finds one prints the period, what the driver's own PLL lock check made of the tuner (on the bench: locked on every tune), and the one remedy known - unplug the dongle and plug it back in - and exits 1 instead of PASS. Nothing in the receiver itself changed.
Still not fixed, and known: the two fast-fail deaths reported from the field (0.99.64 on an RSP1 after 48 minutes, 0.99.65 on an RTL-SDR after 12 seconds) are not explained - from this version every report names the other programs' DLLs in the process, and since 0.99.66 the sentinel names the faulting module, so the next one says more; the other twenty-eight languages' airband strings were not reviewed, and Italian and Dutch call the frequency list "Segnalibri" and "Bladwijzers" where German, French and Spanish call it by a name of its own, a difference older than 0.99.65 that was followed, not resolved; a recording whose disk disappears part way ends as an empty file with nothing on screen saying so; an MP3 patch speaker whose folder is removed says nothing; a log file held open by another program at start-up is silently switched off.
SHA-256 of foxsdr-setup-0.99.69.exe:
e7685af028a7278010d478309e0dbfd1b76919ebe3aa6c8904e68d47e14a70b9
SHA-256 of FoxSDR-0.99.69-x86_64.AppImage:
30aeaf3113439a9ce88171eae8cae9ee7324ece4e169b26b2f7f8c9adcf7ba4f
SHA-256 of foxsdr-0.99.69-linux-x64.tar.gz:
d9c6c42822e597c223b85ac1e086ecbd68fe47a4f9282592c764cff33855ce2d
SHA-256 of FoxSDR-0.99.69-aarch64.AppImage:
f3179f413b01a7ff5841072d6ac21eb41ca385157065eb34ee2d6a4db251eec0
SHA-256 of foxsdr-0.99.69-linux-arm64.tar.gz:
40052bff33239de9d82b242c9222e476c0570a2bdc740df43494a208fca8f5da