SDRplay RSPs no longer drop to the signal generator without saying why. A beta tester's RSP was recognised, then FoxSDR quietly switched to the built-in signal generator, and every later launch started on the generator. The cause was the SDRplay API service stopping answering after the radio opened. FoxSDR now names the radio and the reason, suggests restarting the SDRplay API service, never saves the generator over the radio you chose, and remembers your RSP for the next launch.
If FoxSDR already starts on the signal generator because of this bug, pick your RSP once in Source. Restart the SDRplay API service first if FoxSDR says the service stopped answering. From then on FoxSDR remembers it.
A stalled RSP is named, and a lost one is left alone. If the radio stops delivering samples for five seconds, FoxSDR says so instead of showing a silent receiver. Once the service is lost, FoxSDR stops sending settings to it, so nothing it shows is a setting the radio never took. A change the radio refuses half-way now shows what the radio actually kept.
Every stop ends the recordings. Stopping the receiver from the web remote, CAT, a plugin or the radar POWER key now ends any audio or I/Q recording, as the START/STOP key always did. A recording also ends, with the reason shown, when the radio faults or you switch source.
Not yet tried on the hardware. There is no SDRplay radio on this desk, so the RSP changes were proved against a faithful software stand-in of the SDRplay API. If your RSP behaves differently, REPORT A BUG / DISLIKE reaches us directly.
SHA-256 of foxsdr-setup-0.99.36.exe:
297f0334a08cab95386c98630880c68289940bbdd23c0047129e66376db6492f
SHA-256 of FoxSDR-0.99.36-x86_64.AppImage:
56735655989d6dc360341ed45f721a22fc1ceef495b65b5c5a45022681134fd6
SHA-256 of foxsdr-0.99.36-linux-x64.tar.gz:
6d5fc4f6e095a30e8aa660056ed32b9df32b2bc1d9cc863ab8e77317ebdb26c2