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

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

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?

UPDATES:

  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).
Advertisements
Categories: GNURadio and USRP Tags: ,
  1. January 29, 2011 at 8:58 am

    Greetings,
    I have following your post and made the connections/etc, however, attempting to send the data using the perl command a second time doesn’t get to the other side, so I added a -v and it says connection refused the second time I try to run it after I just start up, do you have any ideas what might be happening?

    Thank you,
    Tyson

  2. pwnhome
    January 29, 2011 at 9:45 am

    So it works the first time? Are you adding -v to nc? If the answer is yes to both of those questions, I think I know the answer. The TCP source is not very intelligent. It will only accept one connection and then stops. You’d have to rerun the code in gnuradio-companion to get it to accept another connection. I’m not sure why they wrote it this way.

    There are two ways to fix that. You could try a UDP source instead. I’ll give it a try when I get a chance and let you know. If you get it working, please let me know and I’ll add it to my code for others to use. Another option would be to create your own block. You could use the current tcp source as your base. That code is located at /usr/lib/python2.6/dist-packages/grc_gnuradio/blks2/tcp.py in my Ubuntu install.

    Good luck!

  3. pwnhome
    January 29, 2011 at 9:51 am

    Tyson,

    I just thought of another way you could do it. Instead of using NC, you could write your own TCP client that never breaks the connection.

    In python you could do something like this:

    from socket import *
    from time import sleep # just used to add some delay

    sock = socket(AF_INET, SOCK_STREAM)
    sock.connect((‘127.0.0.1’, 9000))
    sock.send(‘a’*1024)
    sleep(2) # sleep for 2 seconds
    sock.send(‘b’*1024)

    You can modify the calls to send to create a program that actually does something :) Note, I haven’t tested the above code, but it should work.

  4. Patel
    February 10, 2011 at 8:37 am

    Hi,

    I was wondering the order you executed this tutorial. Did you first enter the “perl -e….” to Port 9000, then send the “nc localhost 9001” command, then run the grc? This is the order I attempted it and I have been unable to see an output of 1024 “a’s.” Could this be the source of the problem?

    Also, a more general question. I have done a variety of tutorials involving gnuradio and this is the first where the generate option has been selected to “No GUI.” I notice the program fails to compile when set otherwise. What gave you the intuition to set it to “No GUI”?

    Regardless, thanks for the tutorial.

    • pwnhome
      February 10, 2011 at 3:22 pm

      Patel,

      Yes, order does matter. It should be.
      1. Execute the grc code.
      2. In one terminal, run nc localhost 9001
      3. In a separate terminal, run perl -e …

      The grc code must be executed first because it opens the sockets that nc connects to. The “nc localhost 9001” must be executed second since the TCP Sink block does not cache data.

      “No GUI” is because there are no GUI components in the GRC diagram. If you look at Part 2 of my tutorial, I use a GUI component.

  5. Vikrant Sharma
    March 14, 2011 at 6:46 am

    Regards,
    I have undertaken a project based on USRP for intercompatibility of two different radio sets. Can you help me out with this, so as to how should i proceed? Secondly is encryption of the data possible with this setup?

    • pwnhome
      March 14, 2011 at 4:16 pm

      I’d be glad to help, but you’ll have to provide more info. Do you want me to contact you privately?

      Encryption (or really anything for that matter) should be possible as the USRPs are software defined radios. Anything you can do in software, you can do on the radios.

  6. GT
    June 2, 2011 at 7:53 am

    Hi,
    It can’t work in GNU Radio 3.3.0. Both of your two methods don’t work(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)).
    I don’t know why, please help me!
    Thank you!

    • pwnhome
      June 2, 2011 at 2:34 pm

      What does it do? Any errors? Did you try the py file from the repository?

  7. prakash
    June 14, 2011 at 1:21 am

    dear pwnhome,
    am into a project in Cognitive radio involving USRP and GNU radio. so, starting from the basics, i was try to play around with GNURadio Companion. I was trying to implement a basic OFDM modulator following one of your earlier post. I got the FFT output, bt didn’t understand what exactly was going on in each step as there is no proper mention in grc about what each parameter in the ‘properties’ window of the block meant. I am confused. Can u pls help me out with a step-by-step understanding of the implementation of basic OFDM, QPSK, QAM etc. in grc. Also, i didn’t understand what the commands ‘nc localhost 9001’ and ‘perl -e “print ‘a’x1024″ | nc localhost 9000’ were doing and it didn’t work out as well… I didn’t get the desired output. pls help me!

  8. frank
    March 20, 2012 at 12:36 pm

    I don’t know why but I tried this with a OFDM mod and OFDM demod and it doesn’t work. I don’t want to take you much time but if you know why it doesn’t work I would be pleased if you told me why

    • pwnhome
      March 23, 2012 at 5:35 pm

      I believe that the OFDM mod and demod have a packet encoder and decoder already built in. So, you can remove those blocks. That might fix the problem.

  9. vegi
    June 26, 2012 at 6:07 am

    hello there,

    well i try to sent 256 ‘a’ and i don’t take any output. I think it is because packet encoder has payload length 512.

    then i try to sent 2 times 256 ‘a’ but still i don’t see any output..

    the client is

    from socket import *
    from time import sleep # just used to add some delay

    sock = socket(AF_INET, SOCK_STREAM)
    sock.connect((‘127.0.0.1’, 9000))
    sock.send(‘a’*256)
    #sleep(2) # sleep for 2 seconds
    sock.send(‘a’*256)

    any idea?

  10. December 13, 2012 at 12:22 pm

    Please

    I´d like to know, why constellation doesn´t work well in OFDM mod and demod blocks….

    any idea?

  11. manju
    March 4, 2013 at 1:51 pm

    Hi..This didnt work for me..Can you please tell me the list of commands to use make it run?

  12. September 28, 2014 at 4:12 am

    Wonderful website, thank You !!

  13. Gaz
    June 27, 2015 at 7:32 am

    I can successfully connect to the tcp source and sink sockets but no data flows (in either direction). If I build the radio with tcp source=>tcp sink (and nothing in between) it works as expected, but as soon as I add the packet encoder and mod+demod as you’ve done, it breaks. I’ve tried just the packet encoder/decoder and just the mod/demod as well with no luck. Any ideas?

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: