search

pothosware / SoapySDR

Vendor and platform neutral SDR support library.
https://github.com/pothosware/SoapySDR/wiki
Boost Software License 1.0
1.09k stars 176 forks source link

Hepl needed with SoapySDRServer #187

Closed ghost closed 5 years ago

ghost commented 5 years ago

I ran SoapySDRServer --bind and connected to the port shown in the console using SdrDx.

SdrDx keeps connecting and disconnecting and this is what i get on the console:

SoapyServerListener::accept([::ffff:127.0.0.1]:49876)
SoapyServerListener::handlerLoop() FAIL: SoapyRPCUnpacker::recv() FAIL: header word
SoapyServerListener::close()
SoapyServerListener::accept([::ffff:127.0.0.1]:49877)
SoapyServerListener::handlerLoop() FAIL: SoapyRPCUnpacker::recv() FAIL: header word
SoapyServerListener::close()
SoapyServerListener::accept([::ffff:127.0.0.1]:49878)
SoapyServerListener::handlerLoop() FAIL: SoapyRPCUnpacker::recv() FAIL: header word

Wrong protocol?

guruofquality commented 5 years ago

Can you run locally without soapyremote and see if there are any crashes. Its probably just some segfault or improper shutdown - so the threads in the server just report the error and close the socket.

ghost commented 5 years ago

The software doesn't support the SDRPlay natively, so i was hoping it would work with SDR Remote. Assuming that there is a common protocol for SDR devices. Wrong assumption?

On Sun, Sep 9, 2018 at 5:18 PM Josh Blum notifications@github.com wrote:

Can you run locally without soapyremote and see if there are any crashes. Its probably just some segfault or improper shutdown - so the threads in the server just report the error and close the socket.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/pothosware/SoapySDR/issues/187#issuecomment-419722940, or mute the thread https://github.com/notifications/unsubscribe-auth/AEqHE5N1WKxsoIwWZPn0vvwxFcxa80Lqks5uZTEogaJpZM4WgNpO .

guruofquality commented 5 years ago

Assuming that there is a common protocol for SDR

lol. come again?

so SdrDx isnt linked against soapysdr, you are just giving the SdrDx the ip address and port of the SoapyRemote server and its speaking a different protocol, and SoapyRemote just "hangs up". Thats whats happening?

BTW if thats the case, whatever the SdrDx protocol may be, a server like SoapyRemote that implements this protocol and calls into soapysdr would be great. Theres other suggestions like that, spyserver for example: https://github.com/pothosware/SoapySDR/issues/156

ghost commented 5 years ago

Yeah, i guess that's what's happening. What is it that needs to happen for you (or whoever on the Soapy side) and Ben (on the SdrDx side) talk to each other and see if it's a big effort to get Soapy support into SdrDx?

guruofquality commented 5 years ago

Well either SdrDx should link against SoapySDR and call into its API to talk to SDR devices and to stream samples just like gr-osmosdr or cubicsdr does. -- OR -- someone should implement a server that mimics whatever this network protocol is that you were trying to use and talk to SoapySDR API. Any idea what the protocol is called? And honestly both options may have some utility.

ghost commented 5 years ago

Check mail.

guruofquality commented 5 years ago

in any case, see https://github.com/pothosware/SoapySDR/issues/32

ncorgan commented 2 years ago

https://fyngyrz.com/?p=915

All you need to do with regard to SdrDx is tell me what device name you will use with the server (it currently reports in as "RTLSVR", you need to pick a name for the device you’re supporting, and tell me what it is.)

A GPLv2 server exists to link a device to SdrDx; it wouldn't be difficult to port. All that would be necessary is to give the developer, Ben, a string to associate a SoapySDR server with it. Assuming he's still maintaining this, this is relatively simple.

zuckschwerdt commented 2 years ago

It looks like the SdrDx protocol is a control channel with a sparse set of commands and a UDP broadcast of SDR data. Workable but it misses many nice features of SDRs. Also framing SDR data into UDP is a bottleneck and not a good abstraction. It certainly looks like a nice UI but the project isn't very active. I'd say SDRangel is a match for features, or SigDigger for a fresh and simpler UI, and then with the classics of Gqrx and CubicSDR, maybe SDR# or things like the new SDRPlusPlus, there is a broad choice of alternatives. I'd rather like to see attention on on #156.

ncorgan commented 2 years ago

SDRPlusPlus and SDRangel already support Soapy. I hadn't heard of SigDigger, but apparently it does too.

I dove a bit into the SdrDx client, and I agree on the limitations. I'm already working on a SpyServer device and SDR# plugin (among some other Soapy projects) when I can, so that should widen support significantly.

ncorgan commented 2 years ago

I have a few things I haven't pushed. With the possible exception of the SpyServer device, which is in the testing phase, these projects are too early-on to be usable, but I can put them up (at least in private repos) for now with that disclaimer.