Recorded data with rtl_tcp seems weird

[OevreFlataeker]

I have rtl_tcp running on a remote system, connected to an RTL SDR Blog v3 stick. Using rtl_tcp with tools like gqrx or rtl_433 with the source defined remotely (rtl_tcp) works fine. Using urh, I can use the spectrum analyzer and also this looks fine. But actually recording doesn´t work properly. It looks as if the signal is glued to the top of the window and has long vertical lines. I can see impulses when I send something (e.g. click a key fob), but the recorded data is not parseable either. There is no error otherwise.

Display when nothing is detected .

Pressing a key/sending a signal

In addition the address of the remote rtl_tcp is reset on every usage to 127.0.0.1. The previous value is not saved. Also using a DNS name would be nice here

Some sample recordings signals.zip

URH 2.9.6 on Ubuntu 22.04. rtl_tcp from Ubuntu package rtl-sdr, Version 0.6.0-4

[andynoack]

This looks like a format mismatch somehow, rtl_tcp outputs a .complex16u format. The attached signals, however, seem to be in a wrong format, there does not seem to be any information in it (most information is very near to -1.0 or 1.0).

[OevreFlataeker]

Well, I agree it looks "mismatched" - the question is, what I can do about it? The only option I see which might actually have an effect is the sample rate itself but I don't see anything about the format?

rtl_tcp, an I/Q spectrum server for RTL2832 based DVB-T receivers

Usage:  [-a listen address]
        [-p listen port (default: 1234)]
        [-f frequency to tune to [Hz]]
        [-g gain (default: 0 for auto)]
        [-s samplerate in Hz (default: 2048000 Hz)]
        [-b number of buffers (default: 15, set by library)]
        [-n max number of linked list buffers to keep (default: 500)]
        [-d device index (default: 0)]
        [-P ppm_error (default: 0)]
        [-T enable bias-T on GPIO PIN 0 (works for rtl-sdr.com v3 dongles)]

[andynoack]

Hmm, difficult to suggest a solution here! Apparently there are different versions of rtl_tcp and this version either doesn't record data in a clean way or is not compatible with the standard socket implementation used in URH. Can you have a look at the network trace to find out, if it is a problem on the network or SDR interface side?

[OevreFlataeker]

But wouldn't other tools like rtl_433 and gqrx then also have a problem with a wrong transmitted data type? Or are they that forgiving?

I think I'll first try to build rtl_tcp from sources and check if that makes any difference.

Can I verify your assumption it's the wrong datatype with tcpdump/wireshark?

[andynoack]

Well, the RTLSDR is not a real SDR but a misused DVB-T stick, therefore precision and so on is not as good as in "normal" SDRs, see e.g. the castrated I/Q format (.complex16u). There are tools optimized for this special RTLSDR (like those you mentioned) but URH is rather designed for real SDRs like the USRP or HackRF. I can image that those tools are more forgiving in consequence and maybe also have support for the latest RTLSDR hardware revisions (which may be not the case for default URH). I know, however, that RTLSDRs and also the TCP variant have been working for many years, because it was among others my part to implement years ago. If you can observe the TCP stream in wireshark (I would prefer it over tcpdump here), you should predominantly see 16 bit (4 nibble) packages that consist of values near 00 or ff (i.e. -1.0 or 1.0 I/Q) if something with the data does not really work out.