Software Defined Radio (RTLSDR) — Part I

By | 2012-10-13

A quick (simple) word first on how radio receivers work. A “message” is created at so-called “baseband”. You can think of it, if you like, as the signal that comes from the microphone in the radio studio. That message is used to modulate a carrier wave. A carrier wave is a pure sinusoid at a frequency much higher than the baseband signal. The “modulation” of it, in essence, imposes slight deviations on the carrier, so it is no longer a pure sinusoid. That resultant signal is then fed into a transmitter, pushed up an antenna to make it escape from the wire and into the free space of the universe.

A traditional radio receiver has an antenna too. That antenna feeds into tuner. That tuner is selective, it filters everything but a certain range of frequencies around some chosen target frequency. That target frequency matches a carrier frequency. The output of this tuner is then demodulated, which is the process of pulling the original signal off the carrier, back down to baseband where it can be fed to, for example, a speaker for you to hear. You then pick the centre frequency of the tuner to hear different broadcasts.

Here’s the thing though: the “demodulator” is usually hardware. It’s two processes really, a shift of the high frequency radio broadcast back down to baseband, and a demodulation to turn it into a message.

The advantage of hardware is that it is infinitely fast (electronics just “works” once it’s designed – the physics of the universe is what makes it do its job). The advantage of software is that it is flexible, but slower. Our computers now though are fast enough that they can run software fast enough to do the jobs that hardware previously did. Software defined radio moves the demodulation process from hardware into software.

Demodulation hardware is tailored to a particular type of modulation. You’ll have heard of a couple:

  • Amplitude modulation (marked AM or LW on your radio)
  • Frequency modulation (marked FM on your radio)

These are just a subset though; there are far more modulation schemes. Inside your radio there are, in fact, two separate radio receivers. They share a tuner, but the demodulators are AM and FM and are separate.

Terrestrial Digital Video Broadcast, DVB-T, uses one of these more advanced modulation schemes, but the principle is the same – just think of DVB-T as analogous to FM or AM – it’s a modulation scheme. A tuner feeds to a demodulator. The output is digital instead of analogue at the end, but the principle is the same. You can buy a little USB dongle for your computer that contains a DVB-T receiver and pushes that digital output along the USB cable where it can be fed to your video player application, turned into a picture and be put on your screen. (A similar thing happens in freeview TVs of course, but it’s unlikely USB is involved).

These days, even the hardware methods go digital very quickly. The dongle will have a tuner, but instead of outputting analogue signals to a demodulator, it includes analogue to digital converters and sends digital numbers to the demodulator.

A Linux driver writer was working on a driver for the RTL2832U DVB-T chip; which is used in a great many of these USB dongles. While doing so he discovered that the chip had an undocumented mode where it would stop doing the demodulation itself, and would instead pass the raw samples from the tuner along the USB connection.

This was exciting, because it meant that instead of only being able to “hear” DVB-T from the dongle, we can hear digitised radio. As close as possible to unaltered as it can be. The demodulation can then be done by the PC, but importantly, the demodulation can be AM, FM, DAB, DVB-T, SSB, SSB-SC, DSB, FSK, ASK, PSK, QAM, or anything else that comes along.

Best of all, these dongles can be obtained for about £15.

Being a geek, I’ve got one. Don’t let your lack of geekiness stop you though, the geeks will write the software, you’ll just get a cool toy to play with. For example, the fabulous generic radio tuner, HDSDR, for Windows can be used to browse the airwaves:

Already people are using these to listen to normal FM, and DAB radio. But additionally you can tune in to air traffic control, NOAA weather satellites, amateur radio satellites, GPS satellites, pagers, temperature stations, garage openers, car central locking key fobs, RFID tags, etc, etc. (Don’t worry, your car can’t be opened, it wouldn’t be very secure if a geek with a radio receiver could open it whenever they wanted). These are facilities that were previously only open to electrical engineers with specialised and very expensive test gear. Now, all you need is a USB port and a laptop.

The fun stuff (for me) is the ability to connect this hardware to a software suite called GNU Radio, which provides optimised routines for building arbitrary signal processing flows easily. It’s also gained (since last I looked at it) a GUI called GNU Radio Companion.

Here’s what I did to get that working on my Debian system. This is different from the other instructions out on the web, as I didn’t want to compile gnuradio (which is big and horrible).

Firstly, the application itself (make sure you get a 3.5.3 or above version, as the RTL driver requires it):

$ apt-get install gnuradio

The RTL2382 driver isn’t yet included with gnuradio, so we have to build that separately. For that we’re going to need a few development packages.

$ apt-get install cmake gnuradio-dev libboost-dev python-dev \
    libfftw3-dev swig libusb-1.0-0-dev

Let’s build the USB driver.

$ git clone git://
$ cd rtl-sdr
$ mkdir build
$ cd build
$ cmake ../
$ make
$ sudo make install

This will build and install the driver to /usr/local/lib.

Next, we want GNU Radio to have a source block available that pulls data from, and lets us control, the device via this USB driver. This is the gr-osmosdr plugin. This was the hardest one to find the dependencies for for me because the cmake run will complete even when some are missing.

$ git clone git://
$ cd gr-osmosdr
$ mkdir build
$ cd build
$ cmake ../ -Wno-dev -DCMAKE_INSTALL_PREFIX:PATH=/usr
$ make
$ sudo make install
$ sudo ldconfig

For this build we have overridden the installation prefix of /usr/local/ because we are using the Debian-installed GNU Radio from /usr/. That means the module must go there too.

I also found that I had to edit the CMakeLists.txt file to make it correctly find the boost library I had installed from Debian. To do that I altered the following line:


It’s not clear to me why cmake doesn’t find it without this, it seems to be mentioned as one of the Boost_ADDITIONAL_VERSIONS, but I couldn’t be bothered to investigate.

At this point you should be able to run gnuradio-companion and see an osmosdr/rtlsdr Source under the Sources category in the block list.

You can now remove the development packages if you worry about disk space (or more likely, dpkg database speed):

$ apt-get remove --purge cmake gnuradio-dev libboost-dev python-dev libfftw3-dev swig

Learning to use GNU Radio Companion (GRC) shouldn’t take long for basic operation. Although you will need familiarity with some mathematics and signal processing ideas to do useful work yourself. Don’t despair if you don’t have that, the people who are playing with it tend to publish their GRC files so that you can repeat their experiments without needing to be able to create them yourself.

Leave a Reply