Introduction to software-defined radio (SDR).
What is a software-defined radio (SDR)? How are SDRs designed? What are the pros and cons? This post will cover introductory information on the topic of SDR.
Defining Software-Defined
As far as I know, “software-defined radio” is not a fully standardized term that has one official meaning. So the first thing I need to do is establish what exactly I mean when I say “software-defined radio.” Actually, I’ll start by mentioning two things that I don’t mean:
- A typical hardware-based RF communication system that can be modified in some way via software is not an SDR. For example, if a radio has hardware for both frequency modulation and amplitude modulation and allows the user to choose between the two by means of a software (or firmware) setting, we are not dealing with SDR. This might be called a software-controlled radio.
- A fully-hardware-based digital data link is not an SDR. The “software” in “software-defined radio” does not refer to the fact that the system transfers digital data.
Now that we have two examples of what an SDR is not, here is my attempt at a definition of “software-defined radio”:
- Software-defined radio is a concept according to which RF communication is achieved by using software (or firmware) to perform signal-processing tasks that are typically performed by hardware. A software-defined radio (as in, the device itself) is an RF communication system that incorporates a significant amount of this software-based signal-processing functionality.
Some Details
That gives you the general idea; here are two points that expand on the basic definition:
- An SDR does not have to be a digital communication system. It may seem counterintuitive, but a very complicated digital (actually, mixed-signal) circuit board could be used to implement purely analog RF communication, such as the transmission of analog audio signals.
- An SDR does not have to provide both transmit and receive functionality. It might be only a transmitter or only a receiver. If it is capable of both transmitting and receiving, it might implement the Rx path in software and the Tx path in hardware. There is no reason why software has to be used for everything.
An example of a receive path in a software-defined RF data link.
Minimum Requirements
Radios, like any other electronic system, can incorporate varying degrees of software-based functionality. A question arises, then: When does an ordinary radio become a software-defined radio? How much software does it need to have?
Well, my answer is that the determination is made based not on the amount of software, but rather on the tasks performed by the software. In my opinion, if you want to call something an SDR, the software should be responsible for fundamental RF-signal-processing tasks that are traditionally performed by hardware. These include the following:
For the transmit path:
- generating a baseband waveform
- generating an IF (intermediate-frequency) waveform
- generating an RF waveform (here “RF” refers to the final, highest-frequency signal that is sent to the antenna)
For the receive path:
- sampling and demodulating the received RF signal or an IF signal
- sampling and decoding the baseband signal (this applies only to data links because, by “decoding”, I mean analyzing the baseband signal in order to determine the binary information represented by each symbol)
You might have noticed that I did not include filtering in this list. Removing unwanted frequency components—e.g., low-pass filtering a sampled baseband signal—is certainly an important aspect of RF communication; however, in my opinion, a system does not qualify as an SDR if the only major task performed by software is filtering. But don’t hesitate to disagree if you think I’m being too exclusive.
Using software and a DAC to generate an FSK baseband waveform.
The Components
I think it is safe to affirm the following: If your system does not have both a data converter and a fairly-heavy-duty processor, it is not an SDR.
Typically, the processor is a DSP, which in this case stands for “digital signal processor” instead of “digital signal processing.” This is a name given to processors that are designed to emphasize certain capabilities, such as high core frequencies or hardware that facilitates mathematical calculations. These features separate DSP chips from microcontrollers, but obviously the line can get blurry as microcontrollers become faster and more sophisticated.
The DSP needs to be quite powerful if you want to implement decoding in software because this involves some serious math, and the processor needs to perform decoding calculations fast enough to keep up with the incoming data. On the other hand, if all you are doing with the processor is generating a baseband waveform that will be sent to a DAC and up-converted by hardware, an above-average microcontroller might be adequate.
The data converter will be an ADC or a DAC (or both). You need an ADC for receive functionality and a DAC for transmit functionality. An obvious limitation here is the maximum sampling rate: RF communication involves high frequencies, sometimes very high frequencies, and the converter’s sampling rate must be high enough to provide adequate signal-to-noise ratio.
Pros and Cons
It seems to me that most RF communication systems are still implemented in hardware, and that’s not too surprising: SDRs generally require extensive software development and a complicated PCB design. In addition, the essential components—high-performance data converters and a sturdy processor—are not exactly cheap. Compare all this to a single-chip, highly integrated transceiver (such as this one) that takes care of numerous details and gives you pages of performance data so that you know approximately what your system will be capable of before you even open up your schematic editor.
So why bother with an SDR? Well, first of all, I find them intellectually energizing because they provide a vehicle for carefully analyzing RF signals and experimenting with modulation and decoding techniques. They also make custom RF communication systems more accessible to those who have limited experience with RF design.
The more practical benefit is flexibility—major flexibility. If significant portions of an RF system are governed by software, it follows that significant portions of the system’s functionality can be refined, modified, or even overhauled simply by downloading a new program file. Actually, refinements and modifications can even be incorporated into the existing software, which opens the door to highly adaptive RF communication—a system could be designed to respond to an event or a prolonged condition by automatically changing the modulation scheme or the decoding algorithm.
An SDR could switch between FSK and QPSK based on which one is currently providing the lower bit error rate.
Conclusion
I hope you now have a clear, though perhaps rather theoretical, idea of what a software-defined radio is. In terms of cost and simplicity, SDRs cannot compete with single-chip hardware-based solutions. Nevertheless, they are interesting and valuable tools for R&D projects, and they also enable advanced functionality that could be very beneficial in specialized, high-performance RF systems.
