Addressing some issues.

[Dentonknifeworks]

My station is in a remote place from my house. Short story shop in back yard where all the ham stuff is located.
I use a remote SDR.
Love the work that has gone into this would like to try it out.
Thanks
N0SSE

[JF9SOM]

Sorry for the slow reply here — this has been sitting for about 6 days since you posted it. Thanks for your patience.

Thanks for this request — remote SDR is genuinely useful for a setup like yours (station/antennas in a separate building, radio room elsewhere).

This is now implemented via SoapyRemote, SoapySDR's own remote-device mechanism, so it plugs straight into the existing SDR device list rather than being a separate special case:

• On the machine the SDR is physically connected to (e.g. the shed): install that SDR's normal SoapySDR module as usual, then install and run SoapySDRServer (sudo apt install soapyremote-server && SoapySDRServer on Linux — see the SoapyRemote wiki for other platforms).
• On the machine running FBSAT59 (the client): Linux — sudo apt install soapysdr-module-remote; macOS — brew install soapyremote; Windows — nothing to install, it's bundled in the installer.
• If both machines are on the same LAN, the remote SDR is usually auto-discovered and just shows up in Rig Settings > SDR Settings like any local device.
• If auto-discovery doesn't reach it (e.g. a different subnet, or reachable only over VPN), there's a new "Add Remote Host…" button in Rig Settings > SDR Settings — enter the server's IP/hostname (and optionally a port and driver hint) and it's saved for future sessions.

Help > SDR Device Installation now also has a "Note for Remote SDR Users" section with these same instructions in-app.

One honest caveat: I don't have a second machine + real SDR to test this against end-to-end myself, so this has been verified by code review and a full 3-platform CI build (including the Windows bundling of the client module), but not against a live SoapySDRServer. This will ship in the next release, v0.2.15 (not tagged yet). Once it's out, could you give it a try with your setup and let me know how it goes? If something doesn't work I'll dig into it with your logs.

Thanks again for the suggestion!

[Dentonknifeworks]

Ok I am running soapySDRServer --bind on the remote raspberry pi.
When I go to Rig Settings its not listed. Presing Enumerate has no effect.
I dont see the "Add Remote Host" button.

[Dentonknifeworks]

Note
I have this working with other software it is on the same LAN getting to it has not been an issue and I use it for other software. Thanks for any help.

[Dentonknifeworks]

[JF9SOM]

Thanks for testing this so quickly, and sorry for the confusion!

Looking at your screenshots, I can see you're running v0.2.14 (both the title bar and the Check for Updates dialog confirm this). That build actually predates the Remote SDR / SoapyRemote support — that feature (along with the "Add Remote Host…" button) was merged after v0.2.14 was tagged, so on that version the SDR Settings tab won't show it or find your server, which matches exactly what you're seeing. Nothing wrong on your end.

Good news: v0.2.15 is out now (just released), and it includes:

• The Remote SDR / SoapyRemote support described above
• A couple of related fixes found while finishing this up (a CI test crash fix, and a fix so the Linux AppImage can find an apt/zypper-installed SoapySDR)

Could you grab the new v0.2.15 installer (or use Help > Check for Updates… in the app) and give it another try? On Windows there's nothing extra to install — the SoapyRemote client module is already bundled — so with SoapySDRServer running on the Pi, it should either auto-discover on your LAN or you can add it manually via the new "Add Remote Host…" button in Rig Settings > SDR Settings if discovery doesn't reach it.

If it still doesn't show up, let me know and I'll dig in with whatever logs/screenshots you can share.

[Dentonknifeworks]

Ok Grabbed ver 0.2.15. I now have what you said in the menu but still no joy.

<img width="1247"

="799" alt="Image" src="https://github.com/user-attachments/assets/0da1e5f8-8609-4444-817a-cc1ea6361581" />

[Dentonknifeworks]

[JF9SOM]

Thanks for testing that so quickly — and nice work tracking down that soapysdrutil behavior yourself, that's genuinely useful data (it tells me the SoapyRemote client plumbing and network reachability on your PC are fine — the failure is happening somewhere in FBSAT59's own connect step).

Unfortunately the Radio Control panel currently just shows the word "Error" with no detail (that's a UI gap on our end), so I can't tell what actually failed from the screenshot alone. The real reason is written to FBSAT59's log file, but I know that folder is hidden/awkward to find on Windows, so I put together a small script that finds it and copies what's needed to your Desktop for you — no need to hunt through AppData by hand.

collect_windows_sdr_log.bat — download that, double-click it (Windows may show a SmartScreen "unknown publisher" warning since it's unsigned — click "More info" → "Run anyway"), and it will save two files to your Desktop:

1. fbsat59_log_XXXXX.txt — the full log
2. fbsat59_sdr_summary_XXXXX.txt — just the SDR/Remote-related lines (please attach this one first, it's much shorter)

If you'd rather not download a .bat from a link, here's the exact contents — you can paste this into Notepad and save it as collect_windows_sdr_log.bat yourself:

@echo off
setlocal EnableDelayedExpansion
set "SRC=%LOCALAPPDATA%\fbsat59\fbsat59\Logs\fbsat59.log"
set "DEST=%USERPROFILE%\Desktop"
set "STAMP=%RANDOM%"
if not exist "%SRC%" (
    echo Log file not found at %SRC%
    pause
    exit /b 1
)
set "OUT_FULL=%DEST%\fbsat59_log_%STAMP%.txt"
set "OUT_SUMMARY=%DEST%\fbsat59_sdr_summary_%STAMP%.txt"
copy /y "%SRC%" "%OUT_FULL%" >nul
>  "%OUT_SUMMARY%" echo FBSAT59 SDR / Remote-related log lines
>> "%OUT_SUMMARY%" echo Generated: %DATE% %TIME%
findstr /I /C:"SDR" /C:"Soapy" /C:"remote" /C:"Rig1" /C:"Rig 1" /C:"RigConnect" /C:"Error" /C:"Exception" /C:"Traceback" "%SRC%" >> "%OUT_SUMMARY%"
echo Done - check your Desktop.
pause

Just drag both files into this comment box on GitHub to attach them. Thanks again for your patience — we'll get this working.

[dentonknifeworks-pixel]

fbsat59_sdr_summary_16309.txt
fbsat59_log_16309.txt

[JF9SOM]

Found it — thanks for the logs, that made this easy to pin down.

Your log shows exactly what's happening:

SoapySDR::loadModule(...\soapy_modules/remoteSupport.dll)
  duplicate entry for remote (c:\Program Files\PothosSDR/lib/SoapySDR/modules0.8/remoteSupport.dll)
...
SDR open attempt 1/3 (full args) failed: RuntimeError('SoapySDR::Device::make() no match')

You have PothosSDR installed separately (I can see you were using its soapysdrutil.exe for testing earlier — nice detective work on that, by the way, it really helped narrow this down). On Windows, SoapySDR's core library checks a registry key that the PothosSDR installer writes, and adds PothosSDR's own module folder to its search path in addition to the one FBSAT59 bundles — regardless of what FBSAT59 sets SOAPY_SDR_PLUGIN_PATH to. Since both FBSAT59 and PothosSDR have their own copy of remoteSupport.dll, SoapySDR sees two modules trying to register the same "remote" driver name, rejects the duplicate, and ends up with no usable "remote" driver at all — hence no match on every attempt. (The same "duplicate entry" happens for airspy/airspyhf/hackrf/rtlsdr too, in case you have PothosSDR builds of those — RTL-SDR and HackRF just don't hit it because FBSAT59 bypasses SoapySDR entirely for those two on Windows.)

Could you try uninstalling PothosSDR (FBSAT59 doesn't need it — everything required is already bundled) and then try Connect again? If that fixes it, it confirms this theory. If you'd rather not uninstall it, temporarily renaming this one file should have the same effect for testing purposes:

C:\Program Files\PothosSDR\lib\SoapySDR\modules0.8\remoteSupport.dll

(rename it to e.g. remoteSupport.dll.bak, test, rename back afterward if you want to keep PothosSDR around)

If this turns out to be the cause, we'll look into having FBSAT59 load its own modules in a way that doesn't collide with a PothosSDR install, so this doesn't trip up other users who happen to have both installed. Thanks again for your patience and for the detailed logs — this is exactly what was needed.

[dentonknifeworks-pixel]

Renamed no change
Uninstalled no change
New logs

fbsat59_log_8624.txt
fbsat59_sdr_summary_8624.txt

[dentonknifeworks-pixel]

I just removed the ENV paths also. still no go.
I am able to connect to the SDR in SkyRoof sat tracker.

PS C:\Users\bradv> Test-NetConnection -ComputerName 192.168.1.81 -Port 55132

ComputerName : 192.168.1.81
RemoteAddress : 192.168.1.81
RemotePort : 55132
InterfaceAlias : Ethernet
SourceAddress : 192.168.1.43
TcpTestSucceeded : True

PS C:\Users\bradv>