Trying to make SoapyRemote work

[System L0rd]

My setup is very much junky, but I figured it doesn't hurt to ask.

So what do I have: 

- Cheapest RTL SDR dongle 

- Rooted Google Pixel 4 smartphone 

What have I already achieved:

- Built "librtlsdr" under Termux had to sacrifice zero-copy allocations, but it is working fine

- Built SoapySDR, SoapyRTLSDR, SoapyRemote under Termux 

- SoapySDRServer runs perfectly fine ("CubicSDR" which also uses SoapyRemote works!)

What problem do I have now:
SkyRoof connects to server and discovers device successfully (I can see "Remote: Generic RTL2832U OEM :: 00000001"), but while trying to activate the device, "SDR" indicator in the status bar blinks red, nothing happens. 

Server logs:
~ $ sudo SoapySDRServer --bind="0.0.0.0:1234" --probe="driver=rtlsdr"
######################################################
## Soapy Server -- Use any Soapy SDR remotely
######################################################

Server version: 0.6.0-g54caa5b2
Server UUID: 247574da-0a53-1000-8567-51ef00000001
Launching the server... tcp://0.0.0.0:1234
Server bound to 0.0.0.0:1234
Launching discovery server...
Connecting to DNS-SD daemon...
[WARNING] SoapyRemote compiled without DNS-SD support!
Press Ctrl+C to stop the server
SoapyServerListener::accept(192.168.1.100:63383)
Found Rafael Micro R820T/2 tuner
SoapyServerListener::accept(192.168.1.100:63384)
SoapyServerListener::close()
SoapyServerListener::close()
SoapyServerListener::accept(192.168.1.100:63385)
SoapyServerListener::accept(192.168.1.100:63386)
SoapyServerListener::close()
SoapyServerListener::close()
SoapyServerListener::accept(192.168.1.100:63387)
SoapyServerListener::accept(192.168.1.100:63388)

And it continues indefinitely, increasing port number each time it tries.
At this point I have no idea what am I doing wrong, but given that CubicSDR works fine using same server, I figured I give it a shot and ask you all. 

[Alex VE3NEA]

This is a great project, just a smartphone as a remove SDR server! Please send me the log from SkyRoof, we will see why it closes the connection and retries. One possible cause is SoapySDR version mismatch: CubicSDR uses v.0.7, or maybe even 0.6, while SkyRoof uses the latest v.0.8.

[System L0rd]

It seems like there is something with setBandwith that fails

2025-08-07 14:35:07.451 +03:00 [ERR] Error starting Remote: Generic RTL2832U OEM :: 00000001
System.Exception: SoapySDR error: RemoteError: setBandwidth failed
   at VE3NEA.SoapySdr.CheckError() in D:\a\SkyRoof\SkyRoof\SkyRoof\SDR\SoapySdr.cs:line 74
   at VE3NEA.SoapySdrDevice.SetAllParams() in D:\a\SkyRoof\SkyRoof\SkyRoof\SDR\SoapySdrDevice.cs:line 232
   at VE3NEA.SoapySdrDevice.Start() in D:\a\SkyRoof\SkyRoof\SkyRoof\SDR\SoapySdrDevice.cs:line 116
   at VE3NEA.SoapySdrDevice.TryStart(Boolean logErrors) in D:\a\SkyRoof\SkyRoof\SkyRoof\SDR\SoapySdrDevice.cs:line 70
2025-08-07 14:35:30.701 +03:00 [INF] Stopping SkyRoof

Also, attaching complete log 

четверг, 7 августа 2025 г. в 14:17:06 UTC+3, Alex VE3NEA:

[Alex VE3NEA]

You are right, the remote server refuses to set the filter bandwidth in the radio. The capabilities returned by the server include this:

  "BandwidthRange": [
    {
      "minimum": 0.0,
      "maximum": 8000000.0,
      "step": 0.0
    }
  ],

However, when SkyRoof sends a command to set:

  "HardwareBandwidth": 2090000.0000000002,

it receives:

RemoteError: setBandwidth failed.

Since you are building the server from source, maybe you could fix this and perhaps ignore the setBandwidth command if it cannot be executed properly on the radio.

[System L0rd]

Debugging little bit more I discovered that the server is in fact setting bandwidth, I just had to wait for server logs little more. I presume logs from original post are at "stage discovery" logs (my bad, sorry):
...

Found Rafael Micro R820T/2 tuner

Disabled direct sampling mode
Exact sample rate is: 2500000.107620 Hz
Allocating 15 (non-zero-copy) user-space buffers
SoapyServerListener::close()
SoapyServerListener::close()
SoapyServerListener::accept(192.168.1.100:51734)
SoapyServerListener::accept(192.168.1.100:51735)
SoapyServerListener::close()
SoapyServerListener::accept(192.168.1.100:51736)
SoapyServerListener::close()
SoapyServerListener::accept(192.168.1.100:51737)
...

But looking at it, server sets bandwidth somewhat different from what client is asking for. So I guess for the long term I have to patch some logic to "fake" successfully setting bandwidth.
While continuing attempts to debug I cloned SkyRoof source code from github, successfully compiled, and hit a place where SkyRoof calls NativeSoapySdr function which does not have debug symbols and I have no idea of how to build it.
So (for now at least) what I did is just suppressed error handling in SkyRoof/SDR/SoapySdr.cs at line 70. Works just fine for now. 

Thanks a lot for help!

четверг, 7 августа 2025 г. в 14:57:52 UTC+3, Alex VE3NEA:

[Alex VE3NEA]

Actually the server log contains the sampling rate, not the filter bandwidth. It does not mention an attempt to set the bandwidth, successful or not. 

If you want to debug the  NativeSoapySdr functions, you can rebuild SoapySDR with debug info, then you can step into the SoapySDR code when debugging SkyRoof in Visual Studio.

To build SoapySDR (from my memory):

- install Pothosware so that you have all header files for SoapySDR

- clone SoapySDR and run cmake:

clone https://github.com/pothosware/SoapySDR.git

md build

cd build

cmake ..

- open in VS the SoapySDR.sln solution generated by cmake, enable debug info in the solution properties, and build the solution.