Top 10 Questions Engineers Ask About Software Defined Radios

Below we discuss the top 10 questions asked by engineers about SDRs. These questions have been gathered from emails, calls and industry panel discussions Per Vices has been a part of. The questions are grouped into three broad categories: SDR specifications, Field-programmable gate arrays (FPGAs) and host systems.

Software Defined Radio (SDR) products are fully integrated platforms that allow software applications to send and receive analog signals. This allows a software application to control and process a radio chain for various applications, including radar, GNSS, low latency links, spectrum monitoring & recording, medical fields, test & measurement and electronic warfare.

SDR Specifications

What is the RF frequency tuning range for your SDR platforms?

RF frequency tuning range refers to the ability of an SDR to be able to receive/transmit at a given frequency. This is an important specification that is application dependent since RF communications and protocols operate at various frequencies and/or a client may be needing wideband operation for a specific application.

Per Vices offers two platforms: Crimson TNG and Cyan. Our Crimson platform has a frequency range from near DC to 6 GHz, and Cyan goes from near DC to 18 GHz. We are also able to support customer requirements up to 40 GHz for those that need extended tuning ranges.

Cyan is the highest performing SDR available and is manufactured by Per Vices.

What SDR product provides the highest instantaneous sampling bandwidth?

Instantaneous bandwidth refers to the maximum continuous RF bandwidth that an SDR can transmit or receive. This is generally related to the sample rate at which the convertor device (ADC/DAC) is operating at. The maximum sample rate of the convertor device is further limited by the rate at which the information can be sent to, or from, the FPGA, which is further limited by silicon capabilities and the bit resolution of the convertor device.

For Crimson TNG, we have an ADC and DAC sampling rate of 325 MSPS which sample IQ pairs resulting in 325 MHz of sampling bandwidth. For Cyan, we have an ADC and DAC sampling rate of 1 GSPS, again sampling IQ pairs resulting in 1 GHz of sampling bandwidth. Our latest Cyan platform has the highest sample rate of any SDR, which supports an instantaneous bandwidth up to 3 GHz.

Could the SDR be configured to have eight receive-only channels instead of four transmit and four receive or vice versa?

An RF chain or channel is the series of electrical components such as amplifiers, filters, attenuators, local osclliators, mixers, ADC/DACs, etc. which are configured for either receiving or transmitting signals. The requirements are very much application dependent. For example, if you are designing a radar, you will likely need to have both transmit and receive in order to send out a signal and then capture the reflection. However, if you’re developing a spectrum monitoring application, you may benefit from a larger number of receive chains.

Yes, the Per Vices Cyan SDR is modular in design and can support up to 16 receive only radio chains or any combination of receive and transmit that sum to 16. Our Crimson TNG platform provides fixed support for 4 fully independent Rx and Tx channels.

Is there a lot of latency in your products, and if so, how can this be improved?

Latency refers to the amount of delay (or time) it takes to send data from one point to the next and is usually measured in milliseconds (ms). Minimizing the amount of latency in a system is critcal for industries relying on information and data at split second timing, such as high frequency trading (HFT). Per Vices has extensive knowledge on this, as our SDR products are actually powering the fastest trans-Atlantic link with our very low latency SDRs.

Latency exists in any electronic communications system including our SDRs. Sources of latency in SDRs include the radio chain, DAC/ADC, FPGA DSP, packetization, networking transmittion latency and operating system latency. Our stock products are not optimized for latency, however, we offer a variety of methods to minimize this, inlcuding low latency FPGA IP cores, moving to a real-time operating system (such as a real time Linux kernel), interfacing with another FPGA, embedding application logic on an FPGA or custom interface protocols using SFP+ connectors.

Field-programmable Gate Arrays (FPGAs)

What advantages do FPGAs offer when used in an SDR?

A field-programmable gate array (FPGA) is a semiconductor device with an architecture centered around a matrix of configurable logic blocks (CLBs) with densities from 500 kLE and 10.2 MLE (LE = logic elements), which are (re)configurable into different logic gates and flip-flops by an engineer. This matrix architecture is better known as a fabric; owing to the ability of an FPGAs intellectual property (IP) core to be reprogrammed, reconfigured and perform highly parallel computations at very high throughput data rates. This is done using a bit-file or a bitstream. The FPGA is capable of implementing the various functions discussed above.

FPGAs provide flexibility and reconfigurability required by RF systems. Capabilities in various fields such as radar require FPGAs for beamforming algorithms, triggering, storing wavesforms and pulses used in the field. FPGAs also provide a means to test new protocols for GPS/GNSS testing and simulation. Moreover, FPGAs provide interoperability; the ability of one SDR communications system to be compatible with other communications and other electronic equipment.

Schematic of the functions an FPGA does in Per Vices SDRs

Do your SDRs have built-in digital down-conversion (DDC) and digital up-conversion (DUC)?

Digital down-conversion is the process of mixing an input frequency with a numerically controlled oscillator (NCO) to obtain an output frequency that is of a lower frequency. Digital up-conversion is the process of mixing an NCO such that the output is larger than the input. This is done on the FPGA, using a CORDIC which mixes the Tx (DUC) or Rx (DDC) samples with those generated by a numerical oscillator (CORDIC). This causes the frequency of all our signals to increase or decrease accordingly. DDC/DUC is important because in order for our radio/computer to process very high frequencies, they will need to be converted to a lower frequency in order to be in the ADC bandwidth. Likewise, in order to transmit very high signals, you must start with those that a DAC can handle and then upconvert accordingly.

Crimson TNG and Cyan both have digital down conversion (DDC) and digital up-conversion (DUC) onboard. This is to support the various modes of operation for both Tx and Rx (baseband, midband and highband) and to shift the signal to a specific frequency and corresponding bandwidth.

Do you support custom FPGA images/IP cores that could be implemented into your SDRs?

An FPGA image or IP core refers to the bitstream or bitfile that can be put on a flash drive and copied onto the FPGA. Some customers are interested in offloading processing that would otherwise be done on a host system’s CPU onto the FPGA due to it’s superior performance/parallel processing abilities compared to a CPU.

We do offer a number of IP cores to our customers depending on the specific application need. In addition to offering these cores from our IP library, we also can integrate 3^rd party IP cores or design new cores to meet customer requirements. For those customers that have experience in FPGA designs, we also offer the option for customers to get a license for our source code and any modifications they need for their application.

Host Systems

What network cards/controller (NICs) are required to interface with your SDRs?

A network interface card (NIC) implements the electronic circuitry required to communicate from our SDR to the host machine using a specific physical layer and data link layer standard; in our case this is Ethernet. The IQ pair data is packaged via a VITA49 standard within Ethernet. In certain applications that require a very large instantaneous bandwidth capture, such as spectrum monitoring/sweeping, you would need a NIC that has a very high throughput and lossless data streaming to the host machine.

This is dependent on the product/amount of data you’re looking to send to the host system. Crimson TNG uses a 10 Gbps Ethernet connection (SFP+ ports) to quickly send and receive data. The Crimson TNG uses a 10GBASE-R PHY that interfaces with each SFP+ port using a single, 10.3125 Gbps serial lane and a scrambled 64B/66B coding scheme. It is very important to ensure that network devices or interfaces intended to be used to connect to Crimson TNG support 10GBASE-R. On the higher throughput end, Cyan uses a 40 gigabit Ethernet connection to quickly send and receive data and requires 40GBASE-R NICs on the host. On our roadmap are 100 Gbps links, which will require more advanced NICs.

What type of hardware or server do you propose for handling the large amounts of data being captured from the 1GHz of bandwidth of I/Q data, per chain, captured by Cyan?

Server systems are often needed in order to handle the massive amounts of data that will be sent over the qSPF+ ports. Users require a very fast system with large amounts of RAM, SSDs, etc. As we like to say, it’s like “trying to drink from a fire hose”-- meaning that it’ll be awfully hard to capture the data without a system specifically designed for this. Customers who need this tend to be in radar or spectrum monitoring applications where a large amount of bandwidth is continuously captured.

Generally speaking, customers tend to purchase a custom host system to use with the Cyan unit due to the very large amount of data needing to be stored, processed or monitored. In order to handle the 1 GHz of bandwidth of IQ data streams using the Cyan SDR, we would recommend a dual processor computer, with a minimum of 500 GB RAM (ideally 1 TB), dedicated FPGA-based accelerator cards with large amounts of onboard memory, and a sufficient number of PCIe v4.0 NVME drives in RAID 0 configuration to support streaming the data to disk. If you're planning on doing processing of the captured data, and your work is amenable to it, including two graphics cards is also useful. We also suggest sufficient bulk storage to maintain a history of data captured.

Can I use GNU Radio for programming with this SDR?

A GNU radio is a free and open source platform for developing signal processing systems and tools for SDRs. Many customers choose this platform to test and simulate with their SDR before coding DSP or other functionalities in a lower level language such as C++.

Yes, we interface with GNU Radio right out of the box so you will be able to start working with it right away using GNU Radio and our UHD GitHub branch.

GNU Radio flow graph example showing basic signal processing capabilities

Click here to learn more about Per Vices on everything RF.

Click here to view Software Defined Radios from Per Vices.