In Part 1 of this blog series, we showed how to use the PicoSDR as a vector signal generator for RF performance characterization:

Performing fast RF performance characterization for specific protocols: Part 1

In this blog post, I focus on how to use the PicoSDR reference design as a vector signal analyzer. By using this configuration, the RF performance on the radio front-end can easily be characterized. Once all the RF limitations of the platform are known, the migration from simulation to implementation on a real platform can be done without any surprises.

Vector signal analyzer

There are many ways to use the PicoSDR’s default configuration as a vector signal analyzer. The Radio420X FPGA core has 12-bit I/Q outputs to access the digitized baseband signal from the radio front-end.

Figure 1: Record I/Q samples in internal memory

Figure 1: Record I/Q samples in internal memory

Figure 1 shows that data received from the Radio420 core can be transferred to the DDR3 memory. An external computer application can configure the FPGA to record the Radio420 I/Q samples. The recording process can be controlled by software or by an external trigger signal in order to synchronize multiple acquisitions performed on different systems.

Any signal generator, vector signal generator, or other SDR platform can be connected to the Radio420X’s RX port. The signal requiring analysis can be directly connected using MMCX cables. Antennas can also be used instead.

Using this method, the 4 Gigabytes (GB) of the Perseus’ DDR3 memory can be used. If the 12-bit I/Q samples are stored in a 16-bit format, 4 GB allows for 35 seconds of recording when using a multiple-input/multiple-output (MIMO) 2×2 configuration with a 30 MHz bandwidth.  The memory can be written at a rate of 5.7 GB/s, which is far higher than the Radio420’s maximum data rate. This permits the DDR3 controller to simultaneously record different data from each Radio420X card for MIMO 2×2 applications.

In the default application, data recorded in the DDR3 memory contains the I/Q data of the first radio, in int16 format, interleaved with the I/Q data of the second radio. The record can be configured and the DDR3 data retrieved using simple command-line interface (CLI) instructions:

recplay_record 1048576
ram_get record_data.bin 0 1048576 1024 20000

The first command configures the memory to record 1048476 bytes. The second command transfers the recorded data from the DDR3 memory to the computer using 1024-byte Ethernet packets.

Once the binary file is on the computer, it can be analyzed with any programming language (MATLAB, Python, GNU Radio, and so on). For example, the recorded waveform can be used as a test vector input for your project’s algorithm that was developed in a high-level programming language.

Nutaq’s software includes a simple MATLAB script for converting a binary file to a MATLAB matrix:

signals = fpgaacqgetframes(‘record_data.bin’, 4, ‘int16’, 262144);

In the above example, the binary file “record_data.bin” is read as four distinct int16 data columns. The generated signals variable is a <Nx4> matrix containing the columns I1, Q1, I2, and Q2. I1 represents the in-phase data of the first Radio420X and its data range is from –2048 to 2047 due to the 12-bit format of the Radio420X interface.

Once loaded, the raw signals can be inspected. The time domain and frequency domain plot can be displayed. The raw signals can be demodulated if applicable and the constellation shown. Several parameters can be computed: IMD3, carrier leakage suppression, sideband suppression, second harmonic level, and so on.

Figure 2: Streaming I/Q samples from an external computer

Figure 2: Streaming I/Q samples from an external computer

Another approach is to stream the raw I and Q samples directly to an external computer using the RTDEx library shown in Figure 2. The PicoSDR supports both Gigabit Ethernet and PCIe interfaces to transfer data between a computer and the FPGA logic of the platform.

The host computer can store the raw I and Q data in its own DDR3 memory or in a file on a hard drive. It could also dynamically perform signal processing algorithms on the real-time signals and provide visual feedback to the user. Compared to the DDR3 memory recording on the PicoSDR, the host computer doesn’t have the same limitations – the file size can be as large as required since its hard drive can keep up with the required throughput and is not limited to 4 GB.

On top of Nutaq’s C library, Nutaq’s GNU Radio plug-in can be used to rapidly create algorithms and perform real-time signal processing using blocks freely available from the open-source community. GNU Radio also supports graphical sink blocks for rapid visualization of signals (time domain, spectral domain, constellation, histogram, etc).

The drawback of this streaming approach is that all the I/Q data needs to go through the data exchange interface. Using a high-end CPU, the maximum sustained transmission rate using Gigabit Ethernet is around 120 MB/s. This means that when using a single radio front-end, each I and Q signal can be sampled up to 30 MHz. When using the two Radio420X TX paths, this value is divided by a factor of 2. The user must be aware that performing data processing or using other peripherals while performing an RTDEx transfer can lower the overall throughput that the computer can achieve.

This bandwidth limitation can be overcome by using the PCIe interface to transfer data between the PicoSDR and the external computer. Its data link can operate at up to 750 MB/s when transferring data from the FPGA to the computer. At this rate, a computer can stream to the four radios inside a PicoSDR 4×4 at a 30 MHz sampling rate without encountering throughput issues.

Conclusion

The PicoSDR hardware and software suite provided by Nutaq are designed to help you develop and verify your software-defined radio application as quickly as possible. The reference design included with the PicoSDR enables you to use it as a vector signal generator and a vector signal analyzer. These modes allow rapid testing and characterization so you can narrow down all unknowns before moving your new protocol from simulation to hardware implementation.