rtl_tcp IQ datastream as signal source

[peedy2495]

First of all, thank you for the great work on readsb!

I'm currently attempting to use an external IQ datastream via rtl_tcp as the source for readsb, but I have not been able to get this setup working. I haven't found any documentation or configuration hints suggesting whether this method is supported.

Steps I've taken:

• Set up an rtl_tcp server on another machine, confirmed it's working with rtl_tcp clients like rtl_test and SDRangel.
• Attempted to point readsb to this source, but it's unclear if readsb supports rtl_tcp as an input or what flags/configuration would be required if it does.

My questions:

• Is receiving IQ data from an rtl_tcp source currently supported in readsb?
• If not, is this a feature that could potentially be supported?
• If it is supported, could you please provide guidance or documentation on how to configure it?

Thanks again for your work on this project.

[wiedehopf]

You could use it via soapy probably.

Potentially it could be directly supported but i'm not sure i'm motivated to do this.
Just run readsb instead of rtl_tcp server, it's not that heavy.
Then just run another readsb that ingests beast data from port 30005 from the one with the SDR.

[peedy2495]

Thanks for the quick response!

The reason I’m exploring rtl_tcp (or a similar IQ stream method) is due to resource and thermal constraints on the receiving side — specifically using devices like the Raspberry Pi Zero, which struggle with real-time demodulation and decoding tasks.

My setup involves multiple low-power, edge receivers, and the most effective architecture I’ve found is to stream the raw IQ data to a more powerful central server for demodulation, decoding, and visualization. This significantly reduces thermal and CPU load on the edge devices, enabling more stable long-term deployments.

While I understand that readsb isn't currently optimized for this use case, I’d appreciate any further pointers — for example:

• Might SoapySDR be a possible workaround regarding the limitations?
• Would you be open to a contribution or PR in this direction?

While I don't have the skills to contribute code myself, I really appreciate the insight that SoapySDR might be a possible workaround. If this type of setup ever becomes more officially supported, I’d definitely be interested.

[wiedehopf]

Have you tried readsb on the pi zero? Try it please.
You can disable the tar1090 service.

readsb can do soapy sdr and soapy sdr can do rtl_tcp.
it doesn't need code changes.
You just need to compile with soapy SDR support and use the proper soapy sdr driver.

[peedy2495]

Again, thanks for the quick response and thanks for the clarification!
I’ll give that a try with SoapySDR, either on the Pi Zero or on the server side.

Appreciate the guidance!

[wiedehopf]

soapySDR can speak rtl_tcp.
so you compile readsb with soapySDR support and tell the soapySDR driver to connect via rtl_tcp.

readsb on the pi zero works out of the box.
it has been tested by a good number of people.
The preamble filter is reduced slightly to consume less CPU.
But it works just fine with plenty of headroom.

What you don't want to do is run the various aggregators on the pi zero, that can become problematic.
If you only run readsb it's not an issue.
Best to also systemctl disable --now tar1090 to reduce CPU further.

--net-connector pizero,30005,beast_in
That is what you add to readsb on the server you're running it on to consume the beast data.
Or just use adsb.im stage2 mode to connect all your sites into a nice interface that allows sending data to various aggregators.
In that case you just give it the IP of the pizero to add a site.