Category Archives: rtl-sdr

Embedded rtl-sdr setup: RTL-SDR + OpenWRT = OMG!!

To see in the new version of the osmocom rtl-sdr package the new TPC version, I decided to try to realize my idea about a small embedded rtl-sdr setup.
The basic idea was to run the small rtl-sdr util on a small embedded box connected with the dbv-t dongle at near the antenna, and transmit the data on ethernet connection. The more processing and vizualization can be continue on the desktop/laptop machines.
To this setup I choosed my old small linux box, the NSLU2. It has 2 USB conncetors, network connection, and, more than 2 years ago I installed on it a Debian lenny version, on a 4 Gbyte pendrive.
The running version of linux:

LKGE25945:/home/src# uname -a

Linux LKGE25945 2.6.26-2-ixp4xx #1 Thu Nov 5 05:37:51 UTC 2009 armv5tel GNU/Linux

That time was used as a test setup for a “navigation computer” for a small boat, intelled on it a meteo software, gps and aprs daemon, a Blitzortung lightning detection client, and more. The summary of this can be read here:
That time I installed on it the development packages, a “native” gcc compiler, to compile source packages directly on it.
Now I tryed to install on it the rtl-sdr software too:
The steps I used:

1. The dependency of the rtl-sdr is the libusb 1.0 version. I didnot find binary package to this armel architecture, I downloaded the source, and compiled it. This was standard procedure with the configure, make, make install commands.

2. On the osmoscom git repository, I didnot find a downloadable compressed (source) package, it can be access only through the git clone mechanism. On my NSLU2 I havenot git installed. I made the git clone on my desktop, and tar-zipped on it, and after I moved the fresh distribution package to the small box with wget.

3. The rtl-sdr packege offers two different way to configure and compile:
a. use the cmake. I tryed to find the binary for debian package to the armel architecture, it seems, it was, but now the repositories are empty for this old debian packages.
b. use the autotool. It run on my NSLU2, I choosed it. It is important to use the -i option, because without it send only errors connected to some m4 macro incompatibilities. I used this command, proposed here:
autoreconf -i
after this you can use the standard method to configure, make and make install (if you would like).

4. to run the tcp version, I use this command:
LKGE25945:/home/src# ./rtl_tcp -a -f 433920000 -s 400

The -a parameter is the IP address of this NSLU2 on my local LAN, I use the default port, which is 1234.
I used the 433.92 MHz ISM band for test, because there is nearby outside, a wireless temperature sensor, it sends a short strong signal at every seconds, usefull for test. Finally I choosed 400 ksample for digitization speed. I used the small GP antenna, found in the package of the dvb-t dongle. I dont apply the rtl_tcp file dump feature.

5. When started the rtp_tcp program, it recognized the dvb-t dongle, and start to listen to the default port for a client connection. It send this mesages on an ssh terminal:

LKGE25945:/home/src# ./rtl_tcp -a -f 433920000 -s 400
listen addr
Found 1 device(s).
Found Fitipower FC0012 tuner
Using Terratec Cinergy T Stick Black (rev 1)
Tuned to 433920000 Hz.
Tuner gain set to 5 dB.

6. On the desktop machine I made a simple gnuradio block to make connection to this small server, and receive this TCP stream.
It contains only a TCP source block, and a WX Waterfall/scope or FFT block to receive/visulaise the data stream.

7. If I start the desktop client machine this gnuradio block, on the server you can see this messages:

client accepted!
ll+, now 1
ll+, now 2
ll-, now 0
ll+, now 1
ll-, now 0
comm recv socket error
Signal caught, exiting!
worker socket error
Signal caught, exiting!
all threads dead..

You can see on this messages, sometimes the server drop the connection, and restart to listening mode.
Practically you need a permanent ssh terminal to monitoring the state of the client.

Dont wait to much miracles from such a small setup, but its working:
On a small  embedded linux box you can compile and run an easy way the rtl-sdr software, specially the tcp version of it, and you can use this setup as a remote sdr receiver and TCP server. Ofcourse, on your embedded box you need at least min one USB connector to connect the rtl-sdr comaptible dvt-t dongle.
Not all the tryed gnuradio sink blocks were working at the same way. Sometimes the server dropped the connection to the client.
It seems, it need more works around this setup to get a stable version of it.

On the picture you can see my first, temporaly setup of the embedded rtl-sdr server, running on NSLU2 box.
You can see on the NSLU2 box the connections:
Top white cable is the ethernet LAN cabel. The small black box is the pendrive, holding the OP system.
The next small box is the dvb-t dongle, connected to a tv cabel to the Turstain antenne, working on 430 MHz.
The bottom black cabel is the power connection.

Here is the gnuradio block to test the TCP connection:


Mon Apr 30 10:03:50 CEST 2012
Janos Tolgyesi
hg5apz (at) gmail

My first notes about this topics are here, mainly in hungarian:
Jegyzetek az rtl-sdr-el valo ismerkedesem tapasztalatairol

Wed May  2 11:50:08 CEST 2012

Following the propose of the Admin on the site,
(, used this nice illustration, )
I reconfigured my basic setup, with more Tux support: this is a “near-movable” version, with wifi connection.

The Tux supports the wireless access of the embedded rtl-sdr server:


I said, “near-movable”, because in this moment I didnot deal with the batteries powered solutions for the used small devices, but the connection to the embedded rtlsdr receiver was realized on wireless connection, used an old trick, how can bridgeing two parts of a wired LAN segments into one…
Originally I used this bridgeing to built “wireless cluster”, if you search on this idea, you can find this, now never accessible server/link: This was my server, and this was my web page, I have a local copy of it, I put here two pictures from this publication, clarifying, how I realized the wireless connection of a distributed, virtual machine. It seems, now the problem is similar… Ofcourse the “real” solution would be to build the rtl-sdr utils into an openWrt, and use only one box to serve the “remote sdr receiver”, based on dvb-t dongle.

The remote connection:
My NSLU2 has only 2 USB connectors (maybe can extend it?) and I used one for the system software, connected on a usb pendrive. I use the second usb connector to connect the dbv-t dongle for the sdr receiver. Maybe can use another wifi-dongle to build wireless connection to this box, but now I doesnot try it: The small embedded box has its limitation with memory and the cpu power, to serve the high speed data transmission, maybe not the best idea to put top of this to serve the local wireless connection.
Here is, where come up the old idea, to bridgeing the two segments of a local lan  into one with two wireless AP.
I use two Micronet SP918BK modells:

This small, cheap AP-s have the so called AP Bridge Point-to-Point Mode. This mean, based on this configurations, the two AP-s accept data transmission from the pearing device, based on the mutually used/configured MAC addresses.
This two pictures quoted from my old web page:
1. Setup and testing the minimal “segments” of this lan.

2. The configurations details used two cheap Micronet AP-s for this bridgeing.

The basic check of this “extension”, it you can access the NSLU2 from a machine, sitting on the directly connected wires segment of the LAN.
In my example:
the router,s IP address:
the test (desktop machine)
the A participants AP of the bridge:
the “remote”, B participants AP of the bridge:
the NSLU2 box, with rtl-sdr server: participants
(in my actual configuration the client is another desktop, running on it ubuntu, its name is ubu10, IP address is
The first test to access the remote rtl-sdr server from the first desktop machine:

[root@centos5 ~]# ping
PING ( 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=64 time=9.28 ms
64 bytes from icmp_seq=2 ttl=64 time=8.93 ms

--- ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 8.936/9.109/9.282/0.173 ms

Ok, its working, but it put some small more delay into the connection, comparing to the direct wired access…

In the next stepps I used the previous commands, to start the rtl-sdr server with the tcp version of the utils:

LKGE25945:/home/src# ./rtl_tcp -a -f 433920000 -s 400
listen addr
Found 1 device(s).
Found Fitipower FC0013 tuner
Using Terratec NOXON DAB/DAB+ USB dongle (rev 1)
Tuned to 433920000 Hz.
Tuner gain set to 5 dB.

and I used on ubuntu the same gnuradio blocks, to test the connections, and the receive conditions at the remote dvt-t dongle.

On the picture you can see the two small boxes, working together to serve the remote dvb-t dongle:
One is the Micronet AP, it has its own 2.4 GHz antenna, and connected to the NSLU2 with a small piece of TP network cabel, (with the two black ends at the connectors). This small cabel represents the “remote wired segment” of my LAN. The NSLU2 carries the dvb-t dongle, it has its own antenna too, at the top of a small piece of antenna “boom”.

About the performace:

In this moment I dont able to say too much about this: the original, wired setup produced unwaited interrupts in the data transfers, sometimes it dropped the connection. Maybe you can improve this situation, for example to use the Trottle block from the gnuradio block sets…
The wireless segment in the local lan causes another unshure situations, depending of the 2.4 GHz propagations on the local conditions.
Another issues the interferences between the two radio systems: the wireless AP transmit on relative high power, near the sensitive wideband receiver, representing the tuner in the dvb-t dongle.

Here is a short part from the network monitoring between the rtl-sdr server and the gnuradio client, running on desktop: It can be help to calculate the possible transmit speed.

0:05:06.691011 IP > ubu10.49839: Flags [.], seq 3400577:3402025, ack 1, win 2896, options [nop,nop,TS val 226695 ecr 121448], length 1448
10:05:06.692587 IP > ubu10.49839: Flags [.], seq 3402025:3403473, ack 1, win 2896, options [nop,nop,TS val 226695 ecr 121449], length 1448
10:05:06.692705 IP ubu10.49839 > Flags [.], ack 3403473, win 2761, options [nop,nop,TS val 121462 ecr 226695], length 0
10:05:06.694217 IP > ubu10.49839: Flags [.], seq 3403473:3404921, ack 1, win 2896, options [nop,nop,TS val 226695 ecr 121449], length 1448
10:05:06.695886 IP > ubu10.49839: Flags [.], seq 3404921:3406369, ack 1, win 2896, options [nop,nop,TS val 226696 ecr 121450], length 1448
10:05:06.696200 IP ubu10.49839 > Flags [.], ack 3406369, win 2761, options [nop,nop,TS val 121463 ecr 226695], length 0
10:05:06.697674 IP > ubu10.49839: Flags [.], seq 3406369:3407817, ack 1, win 2896, options [nop,nop,TS val 226696 ecr 121450], length 1448
10:05:06.697788 IP > ubu10.49839: Flags [P.], seq 3407817:3407873, ack 1, win 2896, options [nop,nop,TS val 226696 ecr 121451], length 56
10:05:06.697864 IP ubu10.49839 > Flags [.], ack 3407873, win 2761, options [nop,nop,TS val 121463 ecr 226696], length 0
10:05:06.725398 IP > ubu10.49839: Flags [.], seq 3407873:3409321, ack 1, win 2896, options [nop,nop,TS val 226702 ecr 121454], length 1448
10:05:06.761895 IP ubu10.49839 > Flags [.], ack 3409321, win 2761, options [nop,nop,TS val 121480 ecr 226702], length 0
10:05:07.158920 IP > ubu10.49839: Flags [.], seq 3409321:3410769, ack 1, win 2896, options [nop,nop,TS val 226745 ecr 121454], length 1448
10:05:07.159048 IP ubu10.49839 > Flags [.], ack 3410769, win 2761, options [nop,nop,TS val 121579 ecr 226745], length 0
10:05:07.160590 IP > ubu10.49839: Flags [.], seq 3410769:3412217, ack 1, win 2896, options [nop,nop,TS val 226745 ecr 121454], length 1448
10:05:07.160637 IP ubu10.49839 > Flags [.], ack 3412217, win 2761, options [nop,nop,TS val 121579 ecr 226745], length 0
10:05:07.162232 IP > ubu10.49839: Flags [.], seq 3412217:3413665, ack 1, win 2896, options [nop,nop,TS val 226745 ecr 121454], length 1448
10:05:07.162284 IP ubu10.49839 > Flags [.], ack 3413665, win 2761, options [nop,nop,TS val 121580 ecr 226745], length 0


Modification of the rtl-sdr dongle to the direct sampling receive

Here is the description of this small modification:
Steve said, it need to connect a long wire to the 1 or 2 pin of the rtl2832 chip, and can use the modified rtl-sdr tool to tune below 30 MHz.
In my first version of the parctical modification used a 2 pin connector. The first pin I soldered on the back side of the PCB, to the GND point of the covers of USB connector. The second pin is on the top side, and I conected it to the 1.-th pin of the rtl2832, when it connected to the smd capacitor.

After a little modification you can close the original plastic cover again:

Wed Jun  6 10:15:14 CEST 2012

Osmocom rtl-sdr running on raspberrypi:

raspberrypi working as an sdr server

This is my first test on raspberrypi with the runing osmocom rtl-sdr utils, specially the rtl_tcp server.
The command, starting the server:

root@raspberrypi:/home/pi/rtlsdr/rtl-sdr/build/src# ./rtl_tcp -a -f 433900000 -g 1

It found the connected rtl-sdr dongle, and start to listening:

Found 1 device(s).
Found Fitipower FC0013 tuner
Using Terratec NOXON DAB/DAB+ USB dongle (rev 1)
Tuned to 433900000 Hz.
Tuner gain set to 1.000000 dB.

The client runing on the same lan, on the ubuntu, the gnuradio 3.5 version, with a simple receiver block, consistst of a tcp receiver module and a WX GUI Waterfall Sink module.
When start the receiver, the server on raspberry send this message, and start to send the data:

Use the device argument 'rtl_tcp=' in OsmoSDR (gr-osmosdr) source
to receive samples in GRC and control rtl_tcp parameters (frequency, gain, ...).
client accepted!
ll+, now 1
ll+, now 2
ll+, now 3
ll-, now 0
ll+, now 1
ll-, now 0

But shortly it hung up, with this error messages:

comm recv socket error
Signal caught, exiting!
worker cond timeout
Signal caught, exiting!
all threads dead..
Use the device argument 'rtl_tcp=' in OsmoSDR (gr-osmosdr) source
to receive samples in GRC and control rtl_tcp parameters (frequency, gain, ...).

On the gnuradio waterfall gui we can see the data transfer, but without any received signal.
From this error messages it seems me, it need some network analysis to explore the error sources.
On the picture you an see the attached rtl-sdr dongle and the network cabel, to connect to my local network.
Near the SD card there is the usb cabel, power the rpi unit and the dongle.


RTL-SDR transformer mod e4000 and r820: “H16105DF” 10/100Mbps Ethernet decoupling transformer

Some time ago I’ve tried the HF Mod (aka Direct Sampling Mod) on one of my dongles. The simplest way of doing it is by connecting one of the RTL2832U’s ADC (pin 1 or 2) inputs to an antenna which is exactly how I started. Shortly after that mikikg told me about using a transformer in order to generate a differential signal for the ADCs differential input, as well as boosting the signal and matching impedance. As a quick and dirty solution I desoldered a H16105DF 10/100Mbps Ethernet decoupling transformer from an old ADSL modem and used it. It actually matches the frequencies we care about quite well and in addition serves as a low pass filter. At the moment it is used in a 1:1 configuration, though 1:2 will probably perform better, thus I plan to try that as well. Using it together with an antenna made from a few meters of litz I receive many AM radio stations as well as lots of other signals.

Since someone over at reddit claimed that mikikg originally came up with using Ethernet transformers for the mod, implying I wouldn’t credit him properly, I feel like clarifying. On 10/3/12 I sent him a mail explaining that I had tried a variation of the HF-Mod using an Ethernet transformer and that the results were promising, I also attached a picture to that mail. Seemingly we then both blogged about it quite a while later, yet he did so before I did.

Update #2:
I have tried using the transformer in a 1:2 configuration and the signal actually got worse. That makes me wonder about the RTL2832U’s input impedance.

List of SDRSharp Plugins from (thank you guys :D)

There are a number of SDRSharp plugins that extend its functionality. Here is a collection of all the plugins and download links that I could find. The installation of most of these plugins will require editing the SDRSharp.exe.config file with a text editor such as notepad. More detailed instructions are usually bundled in a readme file with the plugin.

Unitrunker Trunking Plugin

Allows the trunking control software Unitrunker to control the frequencies in SDRSharp. This allows digital and analogue trunking systems to be followed.

Download Here

SDRSharp Trunker Plugin

Orbitron Plugin

Allows the Orbitron satellite tracking software to control the frequency in SDRSharp. This is useful as Orbitron can automatically correct for the Doppler shift when listening to satellites.

Download Here

Mirror At the bottom of this page

Satellite Tracker Plugin

Frequency Manager + Scanner and Scanner Metrics and Frequency Entry Package Plugin

This is a plugin package which comes with three plugins. It comes with a more advanced frequency manager than the one shipped with SDRSharp.

It also has a scanner option which can quickly scan through a group of your saved frequencies, looking for an active signal.

It also has a scanner metrics plugin, which records frequency activity to a database. Later this database can be analyzed to find out which frequencies are the most active, saving you time searching manually for active frequencies.

Finally, this package also has a frequency entry plugin, which works like the old SDRSharp frequency entry used to work. Basically, it just allows you to choose a center frequency and IF frequency easily by typing it in instead of adjusting it with the mouse.

Download the installation packager here

Frequency Manager + Scanner Plugin

Easy Scanner Plugin

Another scanner plugin similar to the scanner already shown above. Add frequencies to the database, then use the scanner to automatically find an active signal.

Download from the files section of this Yahoo group. (You will need to register first)

Easy Scanner SDR# Plugin

AutoTuner Plugin

Automatically tunes to signals that appear in the spectrum which are above a certain adjustable signal strength. Can also create null areas to prevent automatically tuning to unwanted signals. There seems to be only an outdated version, which is built in to an old version of SDRSharp available.

Download Here

Auto Tuner SDR# Plugin

Fast Scanner Plugin

Similar to the AutoTuner plugin in that it automatically tunes to signals above a certain power.

Download Link (Note this site is in Russian, but has a Google translate option at the top of the page. The download link is at the end of the article)

Fast Scanner SDR# PluginFast Scanner SDR# Plugin

ADSB# Plugin

Runs the ADSB# ADS-B decoding program as a plugin in SDRSharp. The main advantage to using this plugin is that you get to visually see the waterfall whilst decoding. It also adds a 1-bit CRC error check.

Download from the files section of this Yahoo group. (You will need to register first)

ADSB# SDR# Plugin

DDE Plugin

Allows programs like WXTrack to work with SDRSharp through a DDE interface.

Instructions and Download Link Here.

Audio FFT Plugin

Adds a audio FFT display in the plugin window.

Download Here

Audio FFT SDR# Plugin

ScopeView Plugin

Adds a simple audio scope to the plugin window.

Download Here

Scope Viewer SDR# Plugin

A modified version of the scope view plugin with Decimation, HoldOff and Hold options resides in the SDRSharp Yahoo group files section under the name (you will need to join the group first to download).

Download Here


Simple Audio EQ Balance Plugin

Adds a simple audio EQ balance setting option box in the plugin window.

Download Here

Audio EQ Balance SDR# Plugin

E4000 Gain Mod Enabler

A plugin which allows the E4000 Linrad gain profiles to be used in SDRSharp, via use of a modified rtl_tcp server.

Download Here

Other Plugin Lists