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: rpcTo 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](https://www.rtl-sdr.com/wp-content/uploads/2015/01/SAM_2226_scaled-500x375.jpg)
![Outdoor RTL-SDR Receiver Running on a BeagleBone Black](https://www.rtl-sdr.com/wp-content/uploads/2015/01/SAM_2217_scaled-500x375.jpg)
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.
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 !
I know this is an OLD!!! post, but, Bob, how did you pipe the stream into netcat?
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
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..
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,
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
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.
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
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.
Hi Fabien.
If it happens I’ll give you a hint ;). Can we reach you somewhere beside this comment center?
Of course, please contact me at:
[email protected]
Hello, i have a same problem in my raspberry remote server.
Can you give me same hint pls? 🙂
rechmp dog gmailcom
AWE_SOME. Thanks!