Join GitHub today
Access SoapyRemote from the public ip ? #38
Thank you very much for your help with the installation of soapy remote. I have been listening to GQrx and win7 pro from my local network for 19 days and I am very satisfied. Will it be possible soon to access SoapyRemote from the public ip ?. Is there any other sdr client that works from windows 7?
Yes, I'd like to know how to do that too.
Trying to access it using CubicSDR 0.2.5
Locally I can add a device using the Manual Device tab
If I add the device as
BUT hitting Start does nothing, there is no streaming of audio or waterfall starting.
I have had a friend across the Atlantic try it remotely and he too can see my device, but Start fails. No crash or hang, just nothing happens
Router set up for Single Port forwarding TCP/UDP on 55132
Is there another undocumented port that is needed too ? I only found 55132 via help here, wonder if there is another that is needed too ?
Thats probably why this is an open issue, the control is TCP on a configurable server port. But the streaming (which can be TCP or UDP) just uses the first port available which is allocated by the OS.
You can change this by changing the bind port to something specific that you can put into your NAT/router.
Keep in mind that both sides are binding to a socket, and this isnt a case of UDP hole punching. So if its an rx stream, the server is running a server for the rx stream, but the client is also running a server for the flow control messages, and status messages. You can skip status probably, but both sides need a way to get to the port on either side through NAT.
I’ll stick with the rtlsdr stick and software for now. Bought an SDRPLAY RSP device as they promised so much more than the rtl usb sticks, but as yet, no software capable of streaming across internet for the RSP devices. At moment I can tune and stream to iPhone via RTL -TCP stream, which is my ultimate goal
RTL-SDR Receiver Iphone app.
I was thinking about this problem and came to the conclusion that perhaps it's better to write a "SoapyInternet" server/device.
The problems are really quite orthogonal; it's a big difference streaming over the Internet vs streaming over a local network. You suddenly have to deal with security, smaller MTU, packet loss, NAT, and firewalls.
I'm thinking about writing something using RTP/RTCP.
Thanks for the work on this! Maybe the ship has sailed, but ideally the current protocol would be changed to be "one-way". Meaning the client (sdr#/cubicsdr) would be the only one making the connection to the server running the SDR. Maybe you'd also have more flexibility to allow manually entered SoapyRemote addresses rather than only using avahi? Happy to help brainstorm and test if you'd like. My interest here would be the ability to place plutosdr devices running SoapyRemote directly on them (like PlutoWeb) facing the web, similar to how Airspy has done. With a OTG ethernet adapter PlutoSDR can even be headless, no computer needed on the SDR side. (cpu usage would be of concern as well in my use-case due to the limited nature of embedded SoC's.)
Would also have to take into consideration the bandwidth required of the IQ data obviously, would be very easy to change a setting and have 10MB/sec start coming down the wire. :)
If I had to choose between starting a new project or expanding soapyremote, I would expand it since I think all of the hard stuff of unix sock cross platformness and wrapping every API call has been taken care of.
Mentioned above, its probably an afternoons work to get the NAT issue solved, its a matter of ports and who first binds the sockets and who first sends to that socket. But with that in mind, its a unencrypted protocol with no security or permissions whatsoever :-)
Here is a list of what I think is missing in SoapyRemote to make it internet safe:
Changes to streaming