In short
Software defined radio (SDR) is a radio system that performs functions traditionally built into fixed hardware circuits, such as filtering, modulation, demodulation and signal processing, in software running on processors, FPGAs or SoC devices. Because behaviour is defined in software rather than in the circuit, one hardware platform can be reconfigured for different frequency bands, protocols and waveforms through a software update instead of a redesign.
Most radios are defined by their circuits. The filters, mixers and demodulators are physically present on the board, and what the radio can do is fixed the moment it is manufactured. Supporting a new band or a new protocol means designing new hardware.
Software defined radio inverts that. The radio still needs an antenna and an analog front end, because physics does not move into software, but the functions that used to live in dedicated circuits, filtering, modulation, demodulation and signal processing, run instead as software on processors, FPGAs and SoC devices. Change the software and the radio changes what it does.
That is the whole idea. The rest of this article is what follows from it, and what it means when you are specifying hardware for an Indian RF lab, a telecom physical-layer bench, or an embedded sensing programme.
SDR Versus a Traditional Radio
The practical difference is where capability is decided.
| Traditional radio | Software defined radio | |
|---|---|---|
| What sets capability | The hardware circuit | The software and FPGA image |
| Supporting a new protocol | New hardware design | Software update |
| Development iteration | Board respin | Rebuild and reload |
| Best suited to | Fixed, stable, high-volume requirements | Evolving requirements, multi-standard work, research |
Neither is universally better. A traditional radio built for one job at volume is smaller, cheaper per unit and lower power. SDR earns its place where the requirement moves: where you need to support several standards on one platform, where the specification is still changing, or where the point of the exercise is to explore the spectrum rather than to occupy one channel of it.
The Three Stages of an SDR Signal Chain
Every SDR, from a hobbyist dongle to a rack-mount research platform, is the same three stages in sequence.
1. The RF front end
The antenna, low-noise amplifiers, mixers and filters. This stage sets the frequency coverage and much of the sensitivity and noise performance. It is irreducibly analog.
In the USRP B-series, this stage is the Analog Devices AD9361 (or the single-channel AD9364), described by Analog Devices as a highly integrated RF Agile Transceiver operating from 70 MHz to 6.0 GHz with channel bandwidths from 200 kHz to 56 MHz. The AD9361 provides two receive and two transmit channels; the AD9364 provides one of each.
2. Conversion
Analog-to-digital conversion on receive, digital-to-analog on transmit. Resolution, sampling rate and dynamic range here directly bound what the radio can resolve. Digilent’s own overview of SDR calls ADC performance one of the most important factors in a radio’s overall capability, and that is a fair way to put it: a converter that cannot separate a weak signal from a strong neighbour will not be rescued by anything downstream.
3. Digital processing
Filtering, modulation and demodulation, channelization, spectrum analysis, error correction and protocol implementation. This is the part that used to be circuits and is now software and programmable logic.
Why the FPGA Matters
This is the question that most often decides which SDR a team should buy, and it is worth being concrete.
At radio sample rates, a general-purpose CPU cannot keep up with the front of the processing chain. Something has to decimate the sample stream before it reaches the host, and that something is the FPGA.
In the USRP X3x0 series, the UHD manual describes the FPGA as running the digital down-converter (DDC) and up-converter (DUC) chains, timed commands and timed sampling. The master clock rate is the base sample rate of the radio blocks, and the DDC and DUC blocks in the default FPGA image derive the application sample rate from it. The Kintex-7 XC7K410T in the X310 is large enough that user-defined DSP blocks can be added alongside, through the RFNoC framework.
So the FPGA answers two separate questions:
- Can the radio sustain the rate at all? The DDC and DUC chains are what make a 200 MS/s front end deliverable over a link the host can actually consume.
- Can you move your own processing into the radio? If the algorithm has to run with deterministic latency, or the host link cannot carry the raw rate, it belongs in the FPGA fabric.
A team that only needs to capture and post-process can treat the FPGA as an implementation detail. A team building a real-time system cannot.
What Runs On Top
USRP radios are driven by UHD, the USRP Hardware Driver, the open-source driver and API through which host software connects to and controls the device. The current manual documents version 4.10.0.0 and covers the device families, the C++ API, FPGA images and RFNoC.
Above UHD, most work happens in GNU Radio, described by the project as a free and open-source software development toolkit that provides signal processing blocks to implement software radios, used across research, industry, academia, government and hobbyist environments. MATLAB and Simulink are the other common host environment.
The practical consequence is portability. A flowgraph developed against a B210 on a laptop generally moves to an X310 on a workstation with a device argument change rather than a rewrite.
Where SDR Actually Gets Used
Digilent’s overview lists amateur radio and spectrum monitoring, military communications and drone data links, satellite communications where protocols may need updating after deployment, medical imaging research, and cognitive radio.
Cognitive radio deserves a note, because it is the clearest illustration of why the software-defined part matters. A cognitive radio monitors spectrum conditions, identifies interference and adapts its operating parameters automatically. That behaviour is only possible if the radio’s parameters are software-settable in the first place.
For hobbyist experimentation, low-cost receive-only dongles are a common entry point, and Digilent’s article contrasts them with professional platforms on bandwidth, dynamic range and synchronization. The distinction that matters when specifying equipment is not price, it is whether the platform can transmit, whether channels are phase-coherent, and whether the timing discipline is good enough for the measurement you intend to make.
Choosing Hardware: The Short Version
Once the concepts are clear, selection comes down to four questions: how many channels, how much instantaneous bandwidth, what host link your processing can sustain, and whether the radio has to run without a host PC.
Three reference points from the USRP range GSAS supplies in India:
- USRP B210: 2x2 MIMO, 70 MHz to 6 GHz continuous, up to 56 MHz of real-time bandwidth, on the AD9361 with a Spartan-6 XC6SLX150 FPGA over bus-powered USB 3.0. Ettus benchmarks real-time throughput at 61.44 MS/s quadrature. The default first radio for most labs.
- USRP X310: two daughterboard slots covering DC to 6 GHz, up to 160 MHz of baseband bandwidth per slot with UBX or TwinRX, a Kintex-7 XC7K410T for user DSP, and dual 10 GigE or PCIe to the host. Ettus quotes 200 MS/s per channel on dual 10 GigE. The choice when bandwidth or custom FPGA work drives the requirement.
- USRP E320: 2x2 MIMO, 70 MHz to 6 GHz on receive, up to 56 MHz instantaneous bandwidth, on a Zynq-7045 SoC whose dual-core Arm Cortex-A9 runs Linux onboard. Ettus states it offers four times the FPGA resources of the E31x devices. The choice when there is no host PC in the deployment.
The full comparison, including the compact B200mini and B205mini-i, is in our USRP selection guide for India.
One handling rule worth carrying over from the UHD manual regardless of model: never apply more than -15 dBm into any RF input, and use at least 30 dB of attenuation when operating in loopback.
Buying USRP Software Defined Radios in India
GSAS Micro Systems is an authorized Digilent engineering partner in India. We supply the NI Ettus USRP B-series, X-series and E-series with INR invoicing, GST-compliant quotation and RF application engineering support, and we are registered on GeM, SAP Ariba, Coupa and TReDS for institutional procurement.
Our application engineers work with RF and telecom teams from Bengaluru, Hyderabad, Chennai, Pune, Mumbai and Delhi NCR, and can help size a radio against your channel count, bandwidth and host-link constraints before you commit. Request a quote with your requirement.
References
- Digilent, “What is SDR (Software Defined Radio)?” https://digilent.com/blog/what-is-sdr-software-defined-radio/
- Ettus Research, USRP Hardware Driver and USRP Manual, v4.10.0.0 https://files.ettus.com/manual/
- Ettus Research, USRP B200/B210 and X3x0 and E3xx device manuals https://files.ettus.com/manual/page_usrp_b200.html
- Analog Devices, AD9361/AD9364 RF Agile Transceiver system documentation https://wiki.analog.com/resources/eval/user-guides/ad-fmcomms2-ebz/ad9361
- GNU Radio project, About https://www.gnuradio.org/about/
Also appears in:
Interested in Digilent tools?
Talk to our application engineers for personalized tool recommendations.
More from Digilent
View all →