No FFT data when connecting to SoapyRemote

[Rua]

I'm trying to connect Gqrx to a remote server using the SoapyRemote protocol. Using Gqrx locally, with client and server on the same machine, it works normally. But when the client is on a different machine, when I activate Gqrx, I get no data, and a lot of No audio FFT data. messages on stdout. I can successfully connect and use both CubicSDR and SDRAngel, so it must be something either Gqrx is doing wrong, or I'm doing wrong with it.

I'm using the following device string:

soapy=0,driver=remote,remote=tcp://192.168.178.234:55132,remote:driver=airspyhf,serial=e252d65db9cb3936

I investigated with Wireshark, and Gqrx very clearly does connect to the server and exchanges information with it. However, when the data stream is started, the UDP packets being sent by the server, containing the SDR data, all have a 24 byte payload and seem to contain no usable data. With CubicSDR and SDRAngel, these packets do contain useful data and they are able to display and demodulate it, so it seems that something is going wrong in Gqrx's communication with the server that is making it send bogus data.

I've attached the Wireshark capture here: soapyremote2.pcapng.zip. It shows all the communication between the two hosts from the point where Gqrx is started to the moment it exits.

[cytrinox]

@Rua I've the same problem, even when connecting to localhost. Have you found a solution?

[Rua]

Nothing so far. I ended up using USB/IP instead. If SoapyRemote worked I'd rather use that though.

[cytrinox]

Nice idea with usbip. But my Airspy mini seems incompatible with usbip. On two different hosts I get the same errors:

[  602.799992] usbip-host 10-3: urb completion with non-zero status -71
 usb usb11-port1: Cannot enable. Maybe the USB cable is bad?

Device works correct when not using usbip.

I assume the problem with soapyremote is within the gnuradio drivers.

[cytrinox]

The interesting thing is that I can reproduce your issue only with a Airspy Mini. With a RTLSDR v3 dongle it just works.

[Rua]

With an RTL, using the auto-detected device string available=Yes,driver=remote,manufacturer=Realtek,product=RTL2838UHIDIR,remote=tcp://192.168.178.234:55132,remote:driver=rtlsdr,rtl=0,serial=00000001,soapy=7,tuner='Rafael Micro R820T' I get the error message "Wrong rtlsdr device index given. Please select another device." Using Soapy locally with the RTL, I have the same problem as I have with the Airspy remotely, no FFT data. Again, CubicSDR can connect via Soapy without issues.

[cytrinox]

I can reproduce it with gnuradio 3.8 using gr-osmosdr and gr-soapy. I've built the whole server side from git master (soapysdr, soapyremote, soapyairspy) but it is still unusable. So I don't think this bug is related to gqrx but to soapysdr.

I've no interests in debugging soapysdr because this is a "nice-to-have" feature, not a requirement for me. For anyone who wants to fix this I would recommend to open an issue on soapysdr/soapyremote/soapyairspy. I would put my money on soapyremote as the root cause.

[Rua]

If Soapy is the cause though, why do SDRAngel and CubicSDR not suffer from it? What is Gqrx doing differently?

[cytrinox]

@Rua I don't think gqrx is doing anything different. gqrx uses soapy through gr-osmosdr (afaik) so it is fully transparent to gqrx. Maybe the problem ist between gr-osmosdr -> soapysdr -> soapyremote. The interesting part is that with gr-soapy there exists direct support to gnuradio for soapy (withaout gr-osmosdr as middleware) and even with this module I'm unable to access the Airspy mini behind a soapy server.