TCP Enabled version of librtlsdr

Recently RTL-SDR.com reader Fabien wrote in to let us know that he has created a new version of the librtlsdr RTL-SDR drivers which have built in TCP support.

Fabien built a remote SDR using a BeagleBone Black mini embedded computer and put it outside for better reception and to be closer to the antenna. When trying to remotely access the dongle he discovered some problems. He writes:

I then access the dongle over TCP from an indoor PC. One issue is that some existing tools such as rtl_fm, rtlizer or rtlsdr_waterfall lacks TCP/IP connectivity.

To solve this problem, I added TCP support to the rtlsdr library. When a tool communicates with the now physically distant dongle, this new implementation transparently forwards the data using TCP instead of USB. It allows one to use existing tools without modifying them. Also, it allows a developer to use the same librtlsdr, no matter whether the dongle is local or distant.

The implementation is located here: https://github.com/texane/librtlsdr
branch: rpc

To use it, one must compile and install the library. Then, a server (called rtl_rpcd) must be run on the remote location (in my case, the beagle bone black at address 192.168.0.43): RTLSDR_RPC_SERV_ADDR=192.168.0.43 \ rtl_rpcd

Then, the existing tool (for instance rtlizer) can be run using:
RTLSDR_RPC_IS_ENABLED=1 RTLSDR_RPC_SERV_ADDR=192.168.0.43 \
rtlizer

Outdoor RTL-SDR Receiver Running on a BeagleBone Black
Outdoor RTL-SDR Receiver Running on a BeagleBone Black
Outdoor RTL-SDR Receiver Running on a BeagleBone Black
Outdoor RTL-SDR Receiver Running on a BeagleBone Black
Subscribe
Notify of
guest

14 Comments
Inline Feedbacks
View all comments
Bob

Very cool! Would you consider adding UDP support? Dropped frames are like dropped samples, not ideal but not a problem either. However, with UDP support you can do multicast/unicast so you could have multiple bits of software listening to the same samples simultaneously and you don’t run into any windowing or retry issues that tcp incurs if you lose a packet.

I tested the concept a bit last year by piping rtl_sdr into netcat and it seems to work fine.

fabien

Hi,
good idea … supporting another protocol should be
quite straightforward. I am still investigating issues
in the current implementation, but will come back
to this idea after. Thanks !

Jon

I know this is an OLD!!! post, but, Bob, how did you pipe the stream into netcat?

SM0YYQ

Can also tell that the software seems to compile well on my Hackintosh 10.10.1, .. with Clang (Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn))

/M

SM0YYQ

Thx, for this thing.. i have looked forward for it.. as RTL_TCP doesn’t work any good anymore (at least for me).
Maybee u should make a HOW-TO or similar so peoples know how to handle this goodie.?, as i don’t really understand how it works, .. and how to implent it in software.
Hope u understand my question..

Fabien

Hi,

actually, there is not much documentation for now. I added a
readme here:
https://github.com/texane/librtlsdr/blob/rpc/README.rtlsdr_rpc

I agree this light, and will improve it according to feedbacks. Do
not hesitate to let me know what you would like to see added.
Ideally, you can use the github issue tracker to submit ideas.
Also, do not hesitate to contribute 🙂

Cheers,

DE8MSH

Hi Fabien.

What is the difference between rtl_tcp and your rtlsdlib? Both are pumping I/Q data via tcp. Can you explain a little more?

73 de DE8MSH

Fabien

Hi,

Hi DE8MSH,

From a functionnal point of view, both allow one to configure the device and
retrieve IQs over TCP. However, rtl_tcp forces the client software to be written
in a specific way. The version I propose lets you write a client software as if the
dongle was local, with the standard librtlsdr API. Also, already written software
that do not support rtl_tcp will work without modfication.

Cheers,

Fabien.

DE8MSH

Hi Fabien.

Thank you for explanation. An idea is to xcompile your lib for WR703N chinese router and do the demodulatin/decoding stuff on other CPU. Or not to pipe and demodulate or raw data via TCP from A CPU to B CPU. Q: I know that rtl_tcp (CPU A) quits service if you disconnect/close app on CPU B. How does your lib handle a disconnect of app on CPU B?

73 de DE8MSH

Fabien

You are welcome,

In the current implementation, the server (called rtl_rpcd and running on the CPU_A
in your example) still listens for incoming connection when the client (app on CPU_B)
disconnects.

However, there is still a bug that makes the server crash when the client disconnect
after having called rtlsdr_read_async. Let me know if you encounter the same issue.

DE8MSH

Hi Fabien.

If it happens I’ll give you a hint ;). Can we reach you somewhere beside this comment center?

Fabien

Of course, please contact me at:
[email protected]

rechmp

Hello, i have a same problem in my raspberry remote server.
Can you give me same hint pls? 🙂
rechmp dog gmailcom

KD0CQ

AWE_SOME. Thanks!