Open nmaster2042 opened 2 years ago
Sounds good. We'd just need to detect the RSP_CAPABILITIES_MAGIC
on the first frame received and then switch to use the extended mode options.
There still isn't any back channel and no flow control. I was thinking about adding a best-effort flow control transparently, basically a command to pause/resume the stream according to (de-)activateStream
API. Not sure if that would help much though (you could keep a receiver open and paused without spending time and bandwidth in the sender).
I don't know if it can help for dev work but there is the Extio RSP_TCP source code here: https://github.com/SDRplay/ExtIO_RSP_TCP where is implemented the specific client part.
Thanks, always good to confirm that we got the right idea. I guess it will more difficult to install an SDRplay test environment than to implement the extended protocol ;)
You're right. Here I have RSP 1A, 2pro, Duo & DX for tests. I can open a rsp_tcp server for you to try ? One device at a time. FTTH here so it should work, even if it doesn't for higher BW.
I'll add a branch with basic support for the extended mode. Maybe it'll just work :)
There is an implementation of RTL_TCP / RSP_TCP as plugin from SDRAngel.
https://github.com/f4exb/sdrangel/tree/master/plugins/samplesource/remotetcpinput
It could help add the rsp_tcp protocol in the Soapy driver ?
In this plugin, the 2 protocols are supported RTL0 for rtl_tcp and SDRA for rsp_tcp with it's enhanced features.
SDRplay team has developed an extended version of RTL_TCP called RSP_TCP : https://github.com/SDRplay/RSPTCPServer
There is the -E (extented mode) to control specific RSP devices settings + 12 bits instead of 8 from original RTL-SDR.
This would bring access to remote sdrplay family devices from Soapy.