Using the Red Pitaya STEMlab 125-14 PRO Gen2 as an SDR in GNU Radio | controlpaths.com

-->

CONTROLPATHS.<br>COM

-->

The Red Pitaya STEMlab 125-14 PRO Gen2 slogan is “The swiss army knife for engineers”, and it is very true. The board is a compact Zynq-based system with two analog inputs and two analog outputs, and it can be used as a signal generator, an oscilloscope, a spectrum analyzer, a logic analyzer, a function generator, and essentially any other applications about reading a signal or generating a signal or both together. Then we have a set of software applications that run on the board and give you a web interface to read and generate signals. In this blog we already covered the Red Pitaya STEMlab as a spectrum analyzer in a previous article using the built-in web applications. Also, we used it from a Python application running in a host computer, and using SCPI commands to control the board.

This time we are going to use another different interface: the Red Pitaya as a software-defined radio inside GNU Radio , where the STEMlab becomes the digitizer and all the signal processing lives in a flowgraph on my computer.

Table of contents

The Red Pitaya blocks for GNU Radio

Preparing the board to accept connections

A first experiment: filtering a signal

Why GNU Radio is not made for this

From a signal generator to an antenna

Receiving 94.2 MHz with a 125 MSPS ADC

The analog wall

Conclusions

The Red Pitaya blocks for GNU Radio

The Red Pitaya source and sink blocks for GNU Radio come from Pavel Demin’s red-pitaya-notes repository. They live inside the SDR transceiver project:

git clone https://github.com/pavel-demin/red-pitaya-notes.git<br>cd red-pitaya-notes/projects/sdr_transceiver/gnuradio

From this repository, I’ve created a repository on my GitHub named redpitaya_projects that contains the same blocks plus a few flowgraphs I used to test them. The repository also includes the import_blocks.sh script that sets the environment variables GNU Radio needs to find the blocks and launches GNU Radio Companion (GRC).

In the original repository, we can find two GNU Radio blocks: a source , which makes the Red Pitaya read a signal from one of its ADC channels and stream it to the host, and a sink , which makes the board generate a signal through one of its DAC channels.

What is worth understanding before drawing any flowgraph is how these blocks are built, because it explains every limitation later in this article. The implementation has two halves. On the board there is an HTTP server together with a set of HDL modules that configure the DACs and ADCs and implement a digital down-converter (DDC) in the FPGA fabric. On the host there are a couple of XML files that define the GRC blocks plus a Python script, red_pitaya.py, that opens TCP sockets to the board and sends the configuration commands.

This is the key point: the GNU Radio block is essentially a gr.hier_block2 wrapping two sockets. A control socket carries the tuning frequency and the sample rate, and a data socket carries a stream of complex gr_complex samples read straight from a file_descriptor_source. Nothing you draw in your flowgraph runs on the Red Pitaya. The board acquires, decimates, and ships samples; every block you add afterwards executes on your computer. (This is not valid only for this board, is the way most SDR front-ends work, including the USRP and the HackRF).

The source block exposes the parameters you would expect from an SDR front-end: the board address and port, the center frequency, the sample rate, and a frequency correction in ppm.

Preparing the board to accept connections

Before GNU Radio can talk to the board, two things need to be in place. First, you need the Red Pitaya’s IP address. You can navigate to the Red Pitaya Network Manager in the web interface and read it there. In my setup the board sits at 192.168.100.201.

Second, and this is easy to forget, you need to launch the SDR transceiver application from the Red Pitaya home page. That application is the server side of the pavel-demin blocks, and until it is running the board will simply not answer the sockets. If you only boot the stock image and never open that app, the source block streams nothing useful and you stare at a flat noise floor wondering why.

The port number selects the channel. Configuring the block to port 1001 works with channel 1, while port 1002 works with channel 2, so the same flowgraph can address either analog front-end just by changing the port. The sink block is almost identical to the source, with one extra parameter: a Push to talk field that must be set to True to actually enable the output channel.

A first experiment: filtering a signal

My first idea was naive but instructive: use the Red Pitaya as a real-time DSP engine. Read a signal with the source, run it through a GNU Radio filter, and play it back out through the sink. A hardware-in-the-loop filter, basically.

The flowgraph is simple. The source is tuned with...