Repository navigation
Releases: wonderingStars/foxsdr
Release list
FoxSDR 0.99.73
FoxSDR now keeps the radio and its sound responsive when many modules are fitted. The DECODER OUTPUT and plugin picture windows open inside the main window, including on scaled displays where they could appear as a thin strip; RESET WINDOW SIZES places them there again. Each radio now remembers whether Auto gain was on. On Windows the source and DSP threads ask for Pro Audio priority, with an above-normal fallback. The sound buffer starts at 120 ms and, after three starved callbacks in a minute, raises its lead through 240, 480 and at most 960 ms; the audio matcher follows that lead. Automatic depth is remembered for the next launch. The Sinks control can instead hold a chosen depth. A raised lead can cause one longer silence when playback next has to prime; lowering the depth drops old queued sound so the shorter delay takes effect promptly, with a possible one-time jump. Fitted decoders now run while their window, map, output, patch or live browser session needs them, and become IDLE after 30 seconds without a use; opening one starts it again. START, a pressed preset, or Keep running pins a module on, while STOP leaves it off. Existing stopped modules stay stopped across an update. Background work such as coverage collection with the map closed now needs Keep running. The Fitted modules window distinguishes IDLE from a decoder that is failing to receive data.
Still not fixed, and known: the two previously reported fast-fail deaths remain unexplained; this release has not been tried on the slow computer that reported repeated audio starvation, so its effect there is unproven. Linux builds of the priority branch have not been run locally. The new words in thirty-three languages have not been reviewed by native speakers. A plugin picture from a regional catalogue is not shown. An MP3 patch speaker whose folder disappears says nothing, and a recording whose disk disappears may end as an empty file without an on-screen explanation.
SHA-256 of foxsdr-setup-0.99.73.exe:
4b9f9328566f80181a672d0db2283632bbdda9ad631e81d3d34be9a1e8082dd0
SHA-256 of FoxSDR-0.99.73-x86_64.AppImage:
6e538a0643700c1bdf6fcdab4b11ec33dd87f360a28fa3f19943d943004e25ee
SHA-256 of foxsdr-0.99.73-linux-x64.tar.gz:
70a3c2e4cbe39cd7f3e14eb498ac7f96efab5a153cad7fd4705498a174b482f2
SHA-256 of FoxSDR-0.99.73-aarch64.AppImage:
9e6f1b60ee5d07c09b32d16011b293e493fb97a9ef40739f7c92c43bf462146b
SHA-256 of foxsdr-0.99.73-linux-arm64.tar.gz:
9942e7f1fbee3717dc9a02ef19cee9b452971d77b6f93c5e79211dc68c12874a
FoxSDR 0.99.72
The Plugin store is laid out like a store now, and the Fitted modules window like an operating panel. The store opens on BROWSE: the catalogue in sections by category (aircraft, marine, satellites and weather, meters and paging, voice and data, maps and tools), each plugin a card with a small drawing, its name, one line about it, a badge when it has never decoded a real signal (EXPERIMENTAL) or has no build for your system (WINDOWS ONLY, LINUX ONLY), and one key: GET, FITTING... while it downloads, INSTALLED, or UPDATE with the two versions beside it ("1.8.0 to 1.8.1"). A key that cannot act is greyed and says why when you rest the pointer on it. A click on a card opens the plugin's page: its pictures first, then what it does, what is new in this version, the maker's legal notice where there is one (with a tick the key waits for) and, under SHOW DETAILS, the facts - maker, licence, plugin ABI, size, the SHA-256 of the build, and what the module says it reaches. Only three plugins have pictures yet; every other page says "No pictures published yet". The UPDATES tab lists what you are behind on, with the first line of what is new and an UPDATE ALL key. A plugin is now recognised as installed by its id and version, not by its file name, so a newer one in the catalogue shows as an update to the one you have. The last catalogue FoxSDR read is kept in the plugins folder and shown at once the next time; if a refresh then fails, the list stays and the top bar says so in amber ("Catalogue from 2026-10-07; could not refresh: ...") instead of the store going empty. The catalogue is still contacted only when you open the store for the first time in a session or press CHECK AGAIN, and nothing is fetched at start-up. A plugin's pictures are fetched only when you open its page, one at a time, over https, at most 4 MiB each, and each must hash to the SHA-256 the catalogue published before it is kept. An update that succeeds removes that plugin's older copy by itself, as it has since 0.99.50, UPDATE ALL included; this release adds a test of it on real modules. The Fitted modules window is rebuilt too: five filter chips with counts (FED, NOT DECODING, TAKES NO SIGNAL, STOPPED, REFUSED), one row per module with STOP or START and REMOVE, which asks twice, and a page per module that opens with what is true on this machine; the old data plate is gone, and the store window now remembers its size and place as the Fitted modules window already did. The catalogue's entries can now also carry a category, an experimental flag, a what's-new text, a publication date, pictures and the capabilities each plugin declares; a catalogue without them still reads, and an entry with a bad picture loses that picture, not the plugin. Nothing is signed, nothing is sandboxed - a fitted module runs inside FoxSDR with every privilege FoxSDR has, and its page says so beside the list of what it declares it reaches - and nothing updates itself.
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 - since 0.99.69 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; the rtl_tcp source's Stop and Start keys in the window itself, and its Linux build, have not been tried against a real server; the store's new words are in all thirty-three languages but no native speaker has reviewed them in any of them; a plugin from the regional list shows no pictures; the pictures of the three plugins that have them (ADS-B, ACARS, EPIRB) had not yet been fetched over the network by the shipped build at release time, only from a local copy, which is what the testers proved (the tests fetch from a stand-in server); and the new windows have not been built or run on Linux, nor looked at at a display scale other than 100%.
SHA-256 of foxsdr-setup-0.99.72.exe:
b931adcd530bcb2caa62f3e0ac2fd8e6fcf2bb191d45c2057f74c5123ab0d562
SHA-256 of FoxSDR-0.99.72-x86_64.AppImage:
699facaa6cc3a12165531d2cc877dd5db32f9d79732b2daccde515bd210e9076
SHA-256 of foxsdr-0.99.72-linux-x64.tar.gz:
f4d2d3642d44e7792e0c18c3ab15c9b787402a89982bc2841339d5589506b4bc
SHA-256 of FoxSDR-0.99.72-aarch64.AppImage:
51e811c48150254ee46570c3468fd7e0053d3eb44f9eac5af07fa94fff5884f3
SHA-256 of foxsdr-0.99.72-linux-arm64.tar.gz:
b39976f3ca25fab549d9cb2fcc9cbfa6d8ea95abb7b468afd64f31fcd733220e
FoxSDR 0.99.71
The Airband monitor says what it is hearing where you are looking. While LISTEN plays, the spectrum carries a line at its top left, over the channel marks: the block of frequencies on the air and, in amber, the names of the channels whose squelch is open - "Hearing: O'Hare Tower, O'Hare Ground". The same two lines have moved up in the Airband section, from under the keys to just above the list of frequencies, and the second line is always there while the monitor plays ("Hearing: -" while nobody is talking), so the rows and the keys no longer shift down a line when someone starts to speak. A tester listening to O'Hare, whose twenty-nine frequencies make the section taller than the window, had to hold the rail scrolled to its foot to read which frequency was talking: measured on 0.99.70 in a 1600 by 1000 window with the rail scrolled to the section, the LISTEN key sat at pixel row 909 of 1000 and the two lines under it, off the bottom of any shorter window. Asked for on 2026-10-07. The same tester asked for the Airband controls as a floating window; FoxSDR's window has no floating panels, and the caption puts the message where the eye already is, so that is not done. Nothing else changes: the strings are the ones the section already had, in every language.
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 - since 0.99.69 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; the rtl_tcp source's Stop and Start keys in the window itself, and its Linux build, have not been tried against a real server.
SHA-256 of foxsdr-setup-0.99.71.exe:
ab28c658447ab0703ceef691f79fb86f011a3a2bba7300e3e78a11a043e07f5a
SHA-256 of FoxSDR-0.99.71-x86_64.AppImage:
d997fa611b2d8b7e4b64c747614ff4e86f21253e02233fb0fb6d4003e459c2a7
SHA-256 of foxsdr-0.99.71-linux-x64.tar.gz:
a35e2353ff10163fedd5e92cbcc006f25d9dae37997091242b36f0c7997c05e7
SHA-256 of FoxSDR-0.99.71-aarch64.AppImage:
1b2a5a685ae75e292a9cdd669c18908fe7dac1b28bdccaa82e208395f07e759d
SHA-256 of foxsdr-0.99.71-linux-arm64.tar.gz:
27447ddca3feb76ba7dc3fdec88be80975be913d6397d36aae45ea35600ff747
FoxSDR 0.99.70
FoxSDR can now listen to an rtl_tcp server on the network. rtl_tcp is the small program that ships with the RTL-SDR software: it holds a dongle on one computer and sends its samples over the network, which is how an RTL-SDR on a Raspberry Pi in the loft, or on another PC, is heard from here. The Source list has a new last row, "rtl_tcp server (network)". Type the server's address into its box - a name or a number, then a colon and the port if it is not 1234 - and press Open, the way the Pluto's row works: selecting the row contacts nothing, and a failed Open leaves whatever was running alone. The sample rate, one tuner gain, automatic gain, the frequency correction (whole ppm) and the bias tee work as on a local RTL-SDR; the samples arrive as 8-bit values, as from any RTL-SDR. Stop pauses the stream but keeps the connection, so the server stays busy until you close the source. There is no automatic reconnect: if the server goes away the receiver says "Device stopped" and you press Open again. Nothing is installed on this computer - FoxSDR speaks the protocol itself. It was checked against the real rtl_tcp program serving an RTL-SDR on the bench: FoxSDR connected, streamed 2.4 MS/s, and reported the lost connection when the server was stopped. A Stop followed by a Start, sent through the browser remote (which runs the same code as the window's Stop and Start keys), was also tried against the real server: the spectrum froze, the connection was kept, and the spectrum ran again after the Start. Pressing the keys in the window itself, and the Linux build, have not been tried. Asked for through the feature-request box on 2026-10-03.
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 - since 0.99.69 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.70.exe:
95399ad9983aecac71458856f7fdb9a69a00a4591a255f3fd17d02c6066c9f38
SHA-256 of FoxSDR-0.99.70-x86_64.AppImage:
4ac2b465329981859a483de44437fa2c4ea54b5c394f66b65d8fb859bd066582
SHA-256 of foxsdr-0.99.70-linux-x64.tar.gz:
cca03ccd4e49d217ad10ffb204e7949e23f6b15553949b7ec61313252a340155
SHA-256 of FoxSDR-0.99.70-aarch64.AppImage:
55567d9de71d9f1266a501661a217214dd3193738725454c4eda2de0b8fea15f
SHA-256 of foxsdr-0.99.70-linux-arm64.tar.gz:
9add51bc0d682ba30c7d696746e00716747a564f33df5972e15945eaa9a102a2
FoxSDR 0.99.69
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 (...)...
FoxSDR 0.99.68
A stop no longer waits on the recorders when nothing is recording, and the log says who asked for it. STOP, the Start/Stop key, the scope's POWER key, and a stop from the web remote or a plugin used to end both recorders even when neither was running, and each of those steps waited for the signal thread to finish the block it was on - a block a busy plugin can stretch to hundreds of milliseconds. The 0.99.65 crash report this comes from showed a 740 ms stop four seconds into a session with nothing recording, eight seconds before the program died by a fast-fail that no report has yet explained. Now an idle recorder is left alone, and every stop writes one line in the diagnostic log naming what asked for it, what it ended and how many milliseconds ending it took, so the next such report says why the receiver stopped and not only what it cost.
With the browser remote on, the window no longer waits for the signal thread's block every frame it hands audio to the browser. Each frame that had new audio copied it out of a short rolling window that sat behind the same lock the signal thread holds for a whole block, so the window stopped drawing until that block was done. It turned up while testing the stop change: with a block stretched to a second and a half, as a busy plugin can, a single frame waited a second and a half inside that copy and nothing else. The window now has a lock of its own, which the signal thread holds only while it writes a block's samples into it, so the browser gets exactly the same audio and the window no longer queues behind the block.
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 - since 0.99.66 the sentinel names the faulting module for the next one; the console window still opens beside FoxSDR on Windows; 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.68.exe:
c2daf51e306c1a13baa6aec96ffbf7f7bae1869036ead1a33b2692e1ea63d139
SHA-256 of FoxSDR-0.99.68-x86_64.AppImage:
81c7a7335dec1e80b1518c55546ae38362f0a9b5485c70d3750d338962a8b45d
SHA-256 of foxsdr-0.99.68-linux-x64.tar.gz:
cf8c05692fa2392a123d643e51a3cf7c0691bdac07dd388e85902a9cee05f79f
SHA-256 of FoxSDR-0.99.68-aarch64.AppImage:
8adeba381a37941df904052b284df1e0654ef7a9fed823294f583c495dfc5712
SHA-256 of foxsdr-0.99.68-linux-arm64.tar.gz:
c74ad29be84397a8cf15f4e5095f569122ff73e7e15fd74c4b68ef7a40e53bab
FoxSDR 0.99.67
Closing the console window no longer ends FoxSDR on the spot. On Windows, FoxSDR opens with a console window of its own - a black window, or a Windows Terminal tab, titled cascade.exe - beside the real one. Closing that window, or pressing Ctrl+C or Ctrl+Break in it, used to end the program at once: nothing was saved, the radio was left open, and the next start found a session that had ended unexpectedly. Now those three ask FoxSDR to close the way its own close button does, and the shutdown runs: settings and bookmarks written, the radio closed. If the shutdown takes longer than the five seconds Windows allows a closing console, Windows ends the program as before. From a field report of 2026-10-06.
Still not fixed, and known: the console window itself still opens with FoxSDR on Windows; 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.67.exe:
78abb6f52ea26ea10f3725f20e496defe36efcfae64fe316917a0f245a30669a
SHA-256 of FoxSDR-0.99.67-x86_64.AppImage:
4572e8ae3f3d31b5b2d6bf6fdc5d9aee938b5ae8ad817c510dd3699f203d45e1
SHA-256 of foxsdr-0.99.67-linux-x64.tar.gz:
508b0f074c1ba4fb7e03b5ca4db315b04e99e642bd3ae3f03f9dceff3f10030e
SHA-256 of FoxSDR-0.99.67-aarch64.AppImage:
2fcb153bf15c9ef16460221086578f8c27ac3cacd81bd5c9aa217f1d71719415
SHA-256 of foxsdr-0.99.67-linux-arm64.tar.gz:
d3e55ea4a2ffe81e27f4b33b600c636b8d5558941c0110699d80f5dfe19f3c22
FoxSDR 0.99.66
The Airband monitor takes a list you type in yourself, and plays NFM as well as AM. Under the airport box, enter a frequency in MHz, choose AM or NFM, optionally name it, and press Add: it joins the frequency list, ticked, and LISTEN plays it with everything else you have ticked. NFM rows - marine, business and public-service channels - play alongside airband at a level that matches the AM ones. A frequency outside what your radio covers is refused, with the range it does cover. WFM is not offered: broadcast FM is too wide for the monitor.
Presets: a named list you can fill by hand, from a file, and export. A preset is a named group of your frequency list. Type its name in the new Preset box, add frequencies to it, or type or paste the path of a CSV or an SDR# frequencies.xml and press Import to read the file into it, its AM and NFM rows ticked. Export CSV writes the preset to your recordings folder as a file that Import reads back, ticks included, and Remove preset takes its rows out of the list.
While the monitor is listening, the spectrum shows what you are hearing. Each channel the monitor is playing is shaded at its own frequency - brighter, with a line down the middle, while someone is talking - and the tuned-frequency band, its line down the waterfall and the "peak in passband" figure are hidden until you press STOP, because they showed a frequency that was not the one you were hearing.
A native driver for the HydraSDR RFOne. The RFOne speaks Airspy's USB protocol with its own ids and a few constants, so it is driven by the Airspy driver given its profile: the device scan, the Source list, the patch page, the web control and the Linux udev rule all know it. Not yet tested on hardware - nobody on the project has one; if you do, please report what you see.
A crash report from the sentinel now says where a fast-fail was. On Windows, when FoxSDR dies by a fast-fail - which cannot be caught inside the process - the sentinel reads Windows' own record of the crash and adds the faulting module and offset, so the next such report names the DLL and, when it is FoxSDR's own, the function.
Still not fixed, and known: 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.66.exe:
2989e1242fa57568aad6e1f183201fa6da4fd558a68774c62f4aca0c64de04cf
SHA-256 of FoxSDR-0.99.66-x86_64.AppImage:
40bd214d305b977084c0fb95d26ccf45b5debe358369d209b5923d027ccccf4a
SHA-256 of foxsdr-0.99.66-linux-x64.tar.gz:
6d045c16ae61c8b6ac41e1385324c55b4fd17e99890f3558e41ec04787584e6a
SHA-256 of FoxSDR-0.99.66-aarch64.AppImage:
162cb7a340ba62003d70ba1275bb9a94d72533998d73e66fd3716241e9e76d5f
SHA-256 of foxsdr-0.99.66-linux-arm64.tar.gz:
a743b5b0e04fc4b7166c0319e2916c3320a7fa8650dcf967ee4fba374940ac5f
FoxSDR 0.99.65
Stop, then Record again straight away, no longer overwrites the recording you just made. A recording is named for the second it starts in. Pressing Stop and then Record inside the same second gave the new recording the same name as the one just finished, and it was opened over it: one file was left, holding only the second take. A recording now never opens over a file that exists - the second take is named with -2 (then -3, and so on) - and the same holds for two recordings started in the same second by the main recorder and a patch speaker.
A damaged settings, bookmark or marker file is kept, not overwritten. If config.json, the bookmark list or the marker list could not be read at start-up - cut short by a crash or a full disk, for instance - FoxSDR started on defaults or an empty list and the next save replaced the damaged file, so whatever could have been recovered from it was gone. The damaged file is now renamed aside (.bad- and the date and time) before anything is saved, the three newest are kept, and if it cannot be moved FoxSDR does not save over it in that session.
On Linux, a folder where the bookmark list, the marker list or a band plan should be no longer ends the program. Reading one of those files when a folder sat in its place - or when the disk returned a read error part way - raised an error nothing caught, and FoxSDR closed at start-up. All of FoxSDR's file readers of that kind now report the problem and carry on.
Stopping a recording no longer freezes the window while the disk finishes the file. Stop had to flush the recording, write its header and close it on the thread that draws the window, and a slow disk held the window for as long as that took. It is now finished in the background; a Record pressed while the previous file is still closing is remembered and starts the moment it is closed. The same was done for importing a bookmark file, opening a patch Radio's I/Q recording, and removing an MP3 patch speaker. The one file read left on that thread is the reopening of a saved I/Q file at start-up.
A freeze report keeps its log when the disk is slow. The end of the log is the most useful part of a freeze report, and it was the part that went missing when the freeze was caused by a slow disk: the report waited for a log line that was itself waiting on that disk. The two no longer share a lock.
The anonymous usage record also counts slow frames and quiet recoveries. With Usage reporting and Diagnostics both on, FoxSDR now counts how many times the window took a quarter of a second, a second or five seconds to draw a frame and in which of eighteen parts of drawing it, and how many times it recovered from a fault on its own, from a fixed list of thirteen places (the sound output restarted, a radio reopened after a driver fault, a settings save that failed, and so on). Counts and words from fixed lists only - never a device name, a serial number, a path, a frequency or the text of a message. PRIVACY.md lists every word. 0.99.64 does not send these two.
A settings folder that cannot be written is no longer retried every two seconds for ever, and a failed screenshot no longer writes its folder's path into the log or leaves a broken picture behind.
Still not fixed, and known: 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.65.exe:
4fa0f3cfe8a6dbc2cffc73eb0f183bb3629e0654c38ee20ef6496906ab977878
SHA-256 of FoxSDR-0.99.65-x86_64.AppImage:
7f5701530fa0e9febc48da519583ca0f1eb406e7f72f445494fd38fe04916700
SHA-256 of foxsdr-0.99.65-linux-x64.tar.gz:
a894f47434bdef05ccc4c4a9974f269ad0beb94c1ec49b47d57b5d2a1939bdfd
SHA-256 of FoxSDR-0.99.65-aarch64.AppImage:
90f2d908bf836f270b841d4fd25f664542f810e3c52b41ef5933ad29f9901fcc
SHA-256 of foxsdr-0.99.65-linux-arm64.tar.gz:
c5e3c5c8519bb5064fc1c9a2e8b0ed50f1f4456970f69fff9e72b35f183781b3
FoxSDR 0.99.64
FoxSDR now notices when it ends without having been able to say why. Some endings nothing inside a program can report: a failure so abrupt that it skips every handler, a window frozen so hard that the part that watches for freezes is stuck too, a failure before the window opens, a frozen window that is then ended from the taskbar. In one week the installs counted at least 85 sessions that ended that way and about 12 reports arrived. With Diagnostics on, FoxSDR now starts a second, windowless copy of itself - the sentinel - that does nothing but wait for the first to end. It reads no memory and takes no dump: it is told how FoxSDR ended, and reads a small page of numbers FoxSDR keeps up to date (which stage it is in, how many frames it has drawn and when it last drew one, which part of drawing the window is under way). When FoxSDR ends abnormally and wrote no report of its own, the sentinel writes one, in the same folder and format as the others, and it is sent at the next start under the same switch and limits. An ending from outside while the window was drawing or being held (you ended FoxSDR from Task Manager, or were dragging the window), and an ending as Windows closed your session, are kept on your computer and never sent. With Diagnostics off the sentinel is not started. You will see a second cascade.exe of about 9 MB in Task Manager; it uses no processor time while it waits and is gone within a tenth of a second of FoxSDR closing. On Linux it can tell only that FoxSDR has gone, not how.
A slow frame is now measured and named, and a freeze report says which part of the window was being drawn. Every freeze reported in recent weeks was something slow on the thread that draws the window, and the only detector fired at five seconds. FoxSDR now times each frame and nineteen named parts of it (the rail, the spectrum, the patch page, a plugin's panels, a plugin reload, starting or stopping a recording, and so on), and records any frame of a quarter of a second or more against the part that took the time - in the log, and in one line of the diagnostics bundle a bug report attaches. A freeze report carries the same word (frame-scope: rail), so it names the part of the program that held the window before anyone has read a stack. The words come from a fixed list; none is a plugin's name, a file, a radio or a frequency. A hidden or minimised window, a display change, a window being dragged and a computer going to sleep are not counted.
The anonymous usage record now counts things that quietly did not work. Five releases once shipped in which no radio of any kind could be detected, and nothing said so, because the program did not crash - it simply did not work. With Usage reporting and Diagnostics both on, FoxSDR now counts, from a fixed list of words: a scan that found no radio at all; a radio that opened, delivered samples, or would not open (by driver kind and one of eight reasons such as busy or absent); whether sound came out; a failed update check, download or install; a plugin catalogue or plugin install that failed, or a plugin refused at load; and a recording that could not start. Counts only - never a device name, a serial number, a path, a frequency or the text of an error message. Empty for most people. PRIVACY.md lists every word.
Eight more file operations no longer run on the thread that draws the window. Four freezes reported between 0.99.58 and 0.99.63 were the same defect in different places: a file being opened or written while the window waited, on a disk that was slow to answer (a synchronised or network folder, a drive that had spun down). The rest have been found and moved: opening a patch speaker's WAV or MP3 file (sound offered while a slow disk opens the file is kept and written first, up to 20 seconds of it), saving bookmarks and markers, opening an I/Q file from the Source list, listing the patch page's recordings, the F12 screenshot, Save as BMP and Export for SDR#. A check in the build now fails if a new file call is added to the window's code outside a short list of named exceptions. Still on that thread, and still reported if they stall: stopping a recording, importing a bookmark file, and reopening a saved I/Q file at start-up.
Five faults found by testing with a memory checker and with deliberately malformed input. A malformed answer to the update check, or to a feature request, could end the program. A CAT command consisting only of a vertical tab or a form feed crashed the CAT connection, so anything able to reach that network port could do it. A marker file holding a very large number made the next marker reuse a number already taken. A radio driver that returned more samples than it was asked for made FoxSDR write past the end of a buffer. All five are fixed, and the inputs that found them are now permanent tests.
SHA-256 of foxsdr-setup-0.99.64.exe:
90e10a562e238e2315f9b87a9f48ad1bb9257ea63b00446999fa3495ec2d3fa9
SHA-256 of FoxSDR-0.99.64-x86_64.AppImage:
553cd2dfd8770f6652bcfd8c22829b8890e51f19841a9119772cfe1a3a930872
SHA-256 of foxsdr-0.99.64-linux-x64.tar.gz:
7badc6a94ff2ea030148c476fae83d9510d23c5f7e2e8f1b32ef2b6edffeab8f
SHA-256 of FoxSDR-0.99.64-aarch64.AppImage:
cfb26c66c34702623570a220ef45cd895f5d869b13cdc26cfb9b24c3f1ed7f3e
SHA-256 of foxsdr-0.99.64-linux-arm64.tar.gz:
6455b1e3280782725e160b9a3489e6b4e72426b35e7857b5d1855ed97fb866b3