Posts Tagged ‘GNURadio’

Intro to GNURadio and the USRP (Part 2, Visualizing the Waves)

January 29, 2011 3 comments

Ever wonder what data looks like as it propagates through space as a waveform? In this second part of my introduction to GNURadio and the USRP, we will find out. For this part, we will again build a simulated setup in gnuradio-companion. The basic setup will be as follows: source -> modulator -> amplifier -> channel model -> throttle -> sink. In the picture below you can see our setup. The actual setup is fairly complicated, but instructions to download the source can be found in part 0.

In this example I am using a random source to generate random blocks of size 512. The OFDM modulator automatically packetizes the data. The Multiply Const block will act as an amplifier, which will be controlled from the mult_const variable. The channel model is the same as in part 1, but I’ve added a noise_voltage slider to control the noise. The throttle block was added to slow things down. Last, the FFT sink is a graphical sink that plots the FFT of the signal. The FFT converts from the time domain to the frequency domain. If you want to see what things look like in the time domain, use the Scope  graphical sink.

Running It and Experimentation

To run the code in gnuradio-companion, just generate the python code (F5) and execute it (F6). You should get something that looks like this:

This is what the random source looks like in the frequency domain. You can see the noise floor is about -30 dB and the bandwidth is about 7kHz. Using the GUI you can play with 2 variables. The noise voltage and the multiplication constant. Increasing the noise voltage should cause something like this:

As you can see, the noise floor goes up, but the level of the actual signal stays the same. This could make it hard for a decoder to be able to extract the data, we’d need to amplify the signal. That would look like this:

A signal like this should be much easier to decode.

Another interesting thing to play with is the “Occupied Tones” of the OFDM modulator. In the figure below, I’ve changed the tones from 200 to 50. You’ll need to stop the code, make the change, regenerate the python code, and run it (F7, F5, F6 are the hotkeys). What happened?

What now?

There is a lot to understand and play with here. Here are some things to look at.

  • Using the default parameters, what happens to the noise floor if you change the multiplier from 1 to 10? Why does this happen? (Checking Peak Hold can help you see exactly what is happening)
  • Try a few different modulators (change the Modulation Technique in the OFDM modulator, replace OFDM with something different and add a packet encoder if necessary). Does the view of signal change with different modulators?
Categories: GNURadio and USRP Tags: , ,

Intro to GNURadio and the USRP (Part 0, Code Repository)

January 29, 2011 5 comments

I’ve created a source code repository for the Intro to GNURadio and the USRP series of blog posts I’m doing. Check out the source at so you don’t have to worry about creating all the blocks yourself. Just go to the link above, click on the source tab, and follow the instructions to check the source out of the SVN repository.

Categories: GNURadio and USRP Tags: , ,

Intro to GNURadio and the USRP (Part 1, Simple Path)

January 19, 2011 17 comments

I’m starting to play with GNURadio and the USRP some. Coming from a Computer Science background, I do not have much experience with wireless communication systems. So, I thought I’d post my experiences to help others. In the first part of the series, we’ll design a very simple (simulated) communication system using gnuradio-companion (the GNURadio gui).

From the reading I’ve been doing on wireless communication system design, things can get pretty complicated very quickly. A basic simulated setup can be created fairly easily though. This requires no special hardware (e.g. a USRP) and has allowed me to do some tinkering.

The above figure (click to enlarge) shows our basic setup. GNURadio works by building paths from a source to a sink with (potentially) a number of intermediate blocks. Some example sources might be a file, a TCP socket, or a USRP radio. Sinks typically have a corresponding source (e.g. File Sink, TCP Sink, USRP Sink). In this case, I’m using a TCP Source and a TCP Sink. Any combination of source and sink will work (TCP Source with USRP Sink, USRP Source with File Sink, etc).

Simulated Setup

From the TCP Source, we go to the Packet Encoder (found under Synchronizers in grc). The encoder adds important information such as a preample and CRC32 checksum to each packet. Since I’ve left the payload length at 0, it will use the default 512. That means all packets will be 512 bytes (not including the bits that the encoder adds). This is important since that means all info sent to the TCP source must be a multiple of 512 bytes. The data is then modulated. Modulation converts the bits into something that a radio can actually transmit (complex numbers). Notice how the “in” link of the modulator is pink and the “out” is blue. That is because it is converting bytes to complex. After modulation, your data is ready to be placed into the air (via a USRP sink). Since I am only building a simulator, however, I’ve added a Channel Model block in there (found under filters).

The Channel Model block will simulate a wireless channel. You can configure various parameters (noise, etc). For now, I’m just leaving that alone.

After the channel comes the demodulation. If we were actually using USRP radios, our transmitter would be done, and we have to start designing a receiver in a new grc file. Since this is just a simulation, I’ve just hooked the channel model’s “out” to the demodulator’s “in”. The process is then reversed (to a packet decoder, then a TCP sink). So, does it work?

Running It

Now the code is ready to run. Press F5 to build the python code and then F6 to run it. Since I’m using a TCP source and sink, we can connect to the proper ports to send and receive data. Before sending, make sure you connect to the sink socket so you can see the data come through. The command I use is: nc localhost 9001. To send data I then use: perl -e “print ‘a’x1024” | nc localhost 9000. That will send the character ‘a’ 1024 times to port 9000. Here is the output:

What now?

Even with this simple setup, there are a number of things you can play with.

  • Change the parameters of the modulator and demodulator
  • Try out a different modulator/demodulator pair (OFDM which is used in 802.11a for example)
  • Change the noise voltage and see how high you can set it before the communications break
  • Once you break communications with noise, add an error correction block to fix it
  • Any other ideas?


  1. After looking into the OFDM modulator code that GNURadio-Companion produces, it turns out that it automatically creates a Packet Encoder block for you. So if you are trying to use OFDM, remove the Packet Encoder from the path and change the modulator to OFDM.
  2. I recently compiled the grc file with the latest version of GnuRadio-Companion, and it didn’t work any more. After looking at the python code, I realized what happened. The latest version is creating the tcp source first. This blocks execution until something connects to the source. To fix this, just go into the py file and move the tcp sink creation to before the tcp source (or just use the py file from the repository).
Categories: GNURadio and USRP Tags: ,