SDRplay on Windows: FoxSDR no longer offers a second, doomed way into your radio. An RSP1A user reported that the radio worked through the SDRplay API, then dropped and left FoxSDR on the signal generator, with a Windows USB error in the log. When the SDRplay API could not list the radio, FoxSDR's own native driver row for it became visible, and opening it could only fail. On Windows that native row is now hidden whenever the SDRplay API is installed, and FoxSDR says what to do instead, following the API's own reason: a lost session says "restart FoxSDR", an old API says "update it", and the API simply not listing this radio says "restart the SDRplay API service". Linux is unaffected. Separately, FoxSDR now acknowledges the SDRplay API's radio-overload warnings on the same bounded, serialised path as every other control instead of on the API's own callback thread - defensive hardening, not a confirmed fix for the drop itself, whose cause is still unknown.
FoxSDR's own native Mirics driver should now be able to open radios on Windows - not yet tried on hardware. Its USB register writes named an endpoint the device does not have. Windows rejects that; Linux's USB stack does not check it. The Linux kernel's own driver for these chips, and a Windows port of the same open-source driver FoxSDR follows, both address the device itself, which is what FoxSDR now does. There is no RSP or Mirics-based radio on the development desk, so if you have one (for example an RSP without the SDRplay API, or a Mirics television stick), a report either way through REPORT A BUG / DISLIKE is genuinely useful.
A bug report can now carry the log that explains it. REPORT A BUG / DISLIKE has a new "Attach the diagnostics log" box - ticked by default when you report a bug, off for a dislike, and yours to change either way - plus "Show what will be sent", which previews the exact text before you press SEND. The log is scrubbed the same way a crash report's log is, and kept under 64 KB (newest lines kept). If the site it talks to does not yet accept the log, FoxSDR resends the same report once without it rather than losing it. Both report pages also warn when the contact field has no email address - a callsign alone means we cannot reply - without blocking SEND. Sound-card device names (which can be a paired phone or headset's own label) are no longer written into the log at all.
Plugins can ask you to type something in, and one disclosed permission lets a plugin read your receiver's approximate position. A plugin can declare a text box, number or switch (a callsign, for example), and FoxSDR draws it wherever that plugin's controls appear - its own window, the rail row and the patch-page inspector. A new permission lets a plugin read your receiver's position as a 6-character Maidenhead grid square - a few kilometres across, never a precise point - only if the plugin declares it; this is shown on the plugin's card in Fitted modules and the Plugin store. It exists for the FT8 plugin's optional PSK Reporter reporting, which sends nothing until you enter a callsign and switch reporting on. PRIVACY.md has a new section, "Plugins and your receiver's position".
SHA-256 of foxsdr-setup-0.99.43.exe:
af51070e043f133dd5bb4f489eb4e0fda78c9bbb1be8d5c9af3380cf250ce530
SHA-256 of FoxSDR-0.99.43-x86_64.AppImage:
77503079f7b35781a48d2a8c04cabfcf7457c193ea504806e458e0fc6e41a915
SHA-256 of foxsdr-0.99.43-linux-x64.tar.gz:
8107880f061a684d05b47368bc13bb45c25a0a6058fa42c8b61123b7c5d9484b