TCP Enabled version of librtlsdr

Recently 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:
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 RTLSDR_RPC_SERV_ADDR= \ rtl_rpcd

Then, the existing tool (for instance rtlizer) can be run using:

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


  1. 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

      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 !

  2. 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))


  3. 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..

  4. 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 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.



      • 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

Post a comment

You may use the following HTML:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>