Getting started with GNURadio & scapy

GNURadio is an open-source software for making Software Defined Radio. It can be used to model a radio transmission or the process a real radio communication.

Scapy is a python tool set able to interact with GNURadio. Basically GNURadio will receive an signal from a SDR key and process it to get a digital sequence. Scapy will process this sequence and potentially generate a new sequence to be process by GNURadio to be transmitted.

There are plenty of example of GNURadio/Scappy usage to hack, simulate, learn many radio protocols like WiFi, GSM, Bluetooth… I want to play a little with Sigfox also so that’s why I started to investigate on this tool.

As this tool is a bit complicated, this post details the key element having helped me to getting started with this tool.

Starting the GNURadio application

First of all to use GNURadio you need to install it. Usually you need to install the following packages:

# apt-get install gnuradio
# apt-get install gnuradio-dev (for dev stuff)

You can also choose a distrib with GNURadio directly installed like pentoo linux. Where the software is already installed.

I do not recommend to install GNURadio on a raspberry PI for development as the software is a bit CPU consuming. We will see later how to using a PI for executing the final result in an embedded way.

Once we have GNURadio installed we can start using it in a graphical environment: A graphical tool (gnuradio-companion) is used to create you model.

Basically, to use GNURadio you select different box and connect these box in a graphical ways. Each of the boxes process the signal and transform it.

On the left part we have the schema of the model with the different blocs and on the right side we have an access to the list of existing blocs. It it possible to extend this list of blocks with your own one, developed in python or C++.

As part of the blocs we find signal processing blocs and data visualization blocs working with QT or Wz.

The main key-understanding points

There are different ways to represent signal and the blocs are designed for a certain type of representation.

This type is indicated by the color of the connector. The complex structure is largely used as it is usually the one correctly adapt to digital radio signal processing in the frequency domain.

Float can also be used to process signal in time domain.

On top of the different type the size matters, Complex float 32b is blue when Complex 64b is light green.

The system also manage some messaging system in gray. The messaging connector are used, as an example, for interacting with external code like scapy.

The full list of color is above:

As a consequence we need to connect blocs using the same type of connector together. It does not means this connection makes sense. It just means the data exchanged are using the same type.

Data are in most of the case vectors of data. If you apply a FFT on a signal, you need to do it per bloc of data so you need to provide a vector and you get a vector of frequencies as a response. The vector size need to match.

 

 

 

Let’s illustrate with a simple FFT (2 in fact)

In the above schema we have an example with 2 different graphical FFT print.

The first component on the right (osmocom-source) is a bloc to connect a physical SDR dongle to the circuit for getting signal into the system. This bloc is sampling the radio signal on a given frequency and a given sampling rate. These parameters are defined in the Variable blocs on the top left and reused as part of the osmocom bloc parameters.

The osmocom-source bloc provide data as a fow of complex data (where only real part is initialized are we are in the time domain.

Then we have different blocs processing the signal.

  • The Simple Squelch bloc bloc the signal under a certain power level
  • The DC Blocker bloc remove the DC part of the signal to avoid having a signal pic on the central frequency.

From this point we can directly use the QT GUI Frequency Sink to display the FFT of the signal. This graphical component is processing the FFT internally and graph the result. If we want to process the FFT manually we can go the other path:

  • The Stream to Vector bloc group the flow of complex values coming from the previous bloc in vector of a given size. This will represent the size of the data sample we want to proceed and also the size of the outgoing FFT and its associated frequency precision.
  • Once we have this vector we can proceed it with a FFT bloc, this bloc transform the time based vector into a frequency based vector.
  • To trace the FFT from this bloc we need to transform the Complex vector into a vector of float with for each entry the power for each frequency. The Complex to Mag^2 blocs plays this role of converting the data.
  • Once done we can trace the FFT with the QT vector viewer.

The different blocs are linked together by clicking on the input and output connector to link. The arrow will then appear. To remove an arrow or a bloc you need to right click and delete.

Once drawn, the circuit can be executed by clicking on play button. The attached SDR will be detected and the signal proceeded. The SDR dongle signal can captured with osmocom-source bloc or with the USRP Source bloc. This one seems to be able to be controlled externally having a message connector as an input. In my experience it did not supported all my SDR dongle compared to osmocom-source bloc.

Next step

In the next post we will see how to create our own bloc and later what we can do with GNURadio and Sigfox.

 

This entry was posted in Networks and tagged , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.