Software-defined radio moves the majority of radio processing into software, facilitating relatively inexpensive wide-band hardware interfaces to the electromagnetic spectrum, especially those frequencies below 3GHz. Pairing advanced SDRs with software-defined, -tuned, and -selected antennae yields dynamically optimal cognitive radio. Perhaps most famously, DVB-T television tuners built around the RTL2832U chip, available in USB-A form factor for less than $30 (particularly the Rafael Micro R820T2), can reliably provide 2MHz of RX bandwidth anywhere from ~30MHz to ~2GHz (still lower frequencies are supported via direct sampling). For $500, powerful units capable of tremendous bandwidth and range (as well as transmission capabilities) are available, and from there it's not that great a leap to building your own stingray--if the cops have 'em, so should you, doyouknowhatiamsayin?
On the more ballin' end of things, a tricked-out Per Vices Cyan will run you $290k before shipping.
Almost every SDR fundamentally works by receiving electromagnetic energy via metal antennae, running that through an amplifier ("analog gain", done to place the signal in the next stage's sweet spot), and sampling the result using an ADC. The latter will have a resolution in bits, and a sampling rate measured in samples per second (or Hz). These samples pass through a digital down converter circuit, a low-pass filter, and finally decimation, emerging as a (complex) baseband frequency range, and streaming out as I/Q (in-phase and quadrature) pairs.
- 1 Hardware
- 2 Low-level software
- 3 High-level software
- 4 RF spectrum
- 5 See Also
SDRs are available both as standalone units and attachments for a PC, where PC functionality will generally be required for processing and display. I will generally be discussing only the latter. For a nice example of a self-contained solution, see the LimeSDR Micro rather than connecting via USB, it comes with a mated Raspberry Pi 3.
The following SDRs all require an attached computer; they are not standalone devices. I have personal experience with those in green.
|Device||Tuner||BW (MHz)||Samples (M)||ADC||Tune (MHz)||Xmit?||FPGA?||Bus||MSRP|
|LimeSDR Mini||LMS7002M||30.72||30.72||12||10--3500||1x||Altera MAX 10||USB3A||$159|
|LimeSDR Micro||LMS7002M||10||10||12||10--3500||1x||Altera MAX 10||GigE||$300|
|bladeRF 2.0µ xA4||AD9361||56||61.44||12||47--6000||2x||Cyclone V||USB3B||$480|
|bladeRF x40||LMS6002D||28||40||12||300--3800||1x||Cyclone IV||USB3B||$420|
|Ettus B210 USRP||AD9361||56||61.44||12||70--6000||2x||Spartan 6
|Ettus B200 USRP||AD9361||56||61.44||12||70--6000||1x||Spartan 6
|Per Vices Noctar||250||125||12 / 16||DC--4000||1x||Cyclone IV
|FunCube Dongle Pro+||0.192||16||150--260
|XTRX CS||LMS7002M||120||0.2--80||12||30--3800||2x||Artix7 35T||2xmPCIe||$299|
|XTRX Pro||LMS7002M||120||0.2--80||12||30--3800||2x||Artix7 50T||2xmPCIe||$599|
|OsmoSDR||E4000||58.8||4.2||14||52--2200||No||Lattice FXP2||USB2A||Never sold|
|ColibriNANO||custom?||3||122.88||14||DC--55||No||Altera MAX 10||USB3A||$270|
A good antenna can have significant impact on SDR capabilities. An antenna can be made from any conducting material. Most antennae are best at a few frequency bands (though relatively frequency-independent antennae exist, including the spiral antenna (Rumsey's principle) and log-periodic (fractal)); monopole antennae are best when they're 1/4 as long as the desired wavelength, while dipoles ought typically total either 1/2 or 5/4 of a wavelength. An antenna has some degree of directivity (also sometimes referred to as gain): highly directional antennae can work with weaker signals, but must be properly aligned with the source/target. An antenna ought further be properly aligned for the desired signal's polarization, which is commonly linear (horizontal, vertical, or slant), circular (left- or right-handed), or elliptical/mixed.
The "V-dipole" configuration rotates the two sections through an angle less than the typical 180°; 120° is typically optimal for this application. V-dipole is an excellent configuration for VHF. Otherwise, most signals are vertically polarized, save ham radio, which is typically horizontal.
- SMA (SubMiniature version A): 7.9mm coax, MIL-STD-348, #6 SAE hex nut, 50Ω
- Reversed gender to make incompatible RP-SMA thanks to government nonsense
- MCX (Micro coaxial): 3.6mm coax
- MMCX (Micro-miniature coaxial): 2.4mm coax
- BNC (Bayonet Neill–Concelman): best at less than 3GHz
- Hirose U.FL: 2mm coax, snap-on, these break easily and piss me off
- RFSpace makes some awfully nice ones
The Linux SDR software ecosystem is robust, but complex. There are multiple middleware layers available, providing generic access to various hardware devices. Many user-exposed applications support both middlewares, sometimes in addition to their own native hardware support. As a result, there can be multiple ways to specify a given piece of hardware in a particular tool.
At the lowest level live the various driver libraries for SDR hardware. It is atypical for SDR hardware to require (or provide) a Linux kernel driver; most appear to be implemented wholly in userspace atop raw USB devices (exceptions include the Mirics MSi2500 and the Ettus USRP). Indeed, the primary interaction most users will have with their kernel might be removing (and possibly blacklisting) the dvb_usb_rtl28xxu DVB driver autoloaded for the RTL-SDRv3 USB dongle (the rtl2832_sdr and rtl2832 kernel objects go with this driver, and ought--despite their names--also be removed). This driver prevents the RTL from being used with rtl_sdr, the userspace RTLSDR libraries. To blacklist it, create an entry ending in .conf in /etc/modprobe:
dank@vespula:~$ cat /etc/modprobe.d/blacklist-rtl8xxxu.conf blacklist dvb_usb_rtl28xxu blacklist rtl2832_sdr blacklist rtl2832 dank@vespula:~$
note that users of initramfs might need to rebuild or modify their initramfs to include this file. Adding a blacklist entry does not remove a loaded module; for that, use rmmod dvb_usb_rtl28xxu.
As noted above, most of these drivers work on raw USB devices. You'll need set up appropriate udev rules to give users permission.
|RTL2832U||rtl-sdr from OsmoCom||https://github.com/osmocom/rtl-sdr.git||rtl_test, rtl_sdr, rtl_power, rtl_tcp, rtl_fm, rtl_eeprom, rtl_adsb|
|HackRF||libHackRF from Great Scott||https://github.com/mossmann/hackrf.git||hackrf_cpldjtag, hackrf_debug, hackrf_info, hackrf_spiflash, hackrf_sweep|
|BladeRF||libbladerf from Nuand||https://github.com/Nuand/bladeRF||bladeRF-cli, bladeRF-fsk, bladeRF-install-firmware|
|Airspy||AirSpy One from AirSpy||https://github.com/airspy/airspyone_host.git||airspy_gpio, airspy_gpiodir, airspy_info, airspy_lib_version, airspy_r820t, airspy_rx, airspy_si5351c, airspy_spiflash|
|Ettus||UHD from Ettus||https://github.com/EttusResearch/uhd.git||uhd_cal_rx_iq_balance, uhd_find_devices, uhd_siggen, uhd_cal_tx_dc_offset, uhd_image_loader, uhd_siggen_gui, uhd_cal_tx_iq_balance, uhd_images_downloader, uhd_usrp_probe, uhd_config_info, uhd_rx_cfile|
Following the proliferation of device-specific libraries, efforts have been made to unite them under one portable userspace API. Both of these layers use the hardware-specific drivers described above, and as of 2019, both can use the other as a device type. For maximum capabilities, I typically:
- Build the low-level drivers (various sources)
- Build the SoapySDR core (https://github.com/pothosware/SoapySDR)
- Build GrOsmoSDR, configured to use the low-level drivers and SoapySDR (https://git.osmocom.org/gr-osmosdr)
- Build SoapySDR modules, including SoapyOsmo (https://github.com/pothosware/SoapyOsmo)
The Open Source MObile COMmunications project is the primary caretaker of the RTL-SDR effort, which has largely replaced their own (discontinued) OsmoSDR. In addition, the Osmocom GNU Radio blocks (gr-osmocom, GrOsmoSDR) provide a hardware abstraction over many SDRs, though expressed in the idioms of GNU Radio. GrOsmoSDR was the first major open source radio abstraction, and the first place many enthusiast SDRs saw support outside of their own drivers and tools.
GrOsmoSDR uses for its device specification comma-delimited list of solitary arguments and/or argument=value pairs. A full reference must be distilled from source. Use of a Soapy driver can be indicated via adding soapy=0 to the driver spec. License: GPL3
The Pothos dataflow processing project required SDR sinks and sources, and presents a cleaner API for projects outside the GNU Radio umbrella via libsoapysdr (a GNU Radio block, gr-soapy, has been built directly atop libsoapysdr). Soapy's native hardware coverage lacks a few minor devices supported by GrOsmoSDR, but it can wrap osmocom devices with the SoapyOsmo module (as noted above, gr-osmocom can likewise wrap Soapy devices via its Soapy driver). Soapy hardware modules are dynamic libraries linked in via dlopen() on demand.
Soapy uses for its device specification a comma-delimited list of argument-value pairs, but always takes as the first pair "driver=FOO". License: Boost
This appears to be a Windows thing, so who gives a shit?
- rx_tools is a reimplementation of several of the rtl_sdr tools (rx_fm, rx_power, and rx_sdr) using Soapy for portability.
- GNU Radio, the 300-kilo orca of open source software radio. GNU Radio is not the most intuitive program ever written, but it has a nice GUI on the front, a rich wiki, active (and expert) development, and 4,000 component blocks. If GNU Radio can't do it, it probably can't be done. Whether you can figure out how to do it with GNU Radio is an entirely different question. GNU Radio has both Osmocom and Soapy native blocks, because of course it does.
- Pothos seems to be trying to be GNU Radio, but for...data processing? It's a truly expansive framework; I primarily know it as the source of (and impetus for) SoapySDR.
These programs allow one to explore a particular captured signal, either from a file or in realtime from an SDR. In addition, most allow for exploration of the RF spectrum via a waterfall plot and/or an FFT plot, as well as configuration of locally-attached (or even networked) devices. There are about 4,000 of these.
- GQRX: uses the GrOsmoSDR GNU Radio interfaces
- CubicSDR: uses the Soapy interfaces
- SDRangel: geared towards AirSpy
- sdrangelove: old project from Osmocom, seems dead
- QSpectrumAnalyzer: python, bleh
- LinRAD: advanced, mysterious. CUDA/OpenCL-enabled; appears to do its own drivers
The following are more special-purpose:
- inspectrum: offline (no capture, only recorded files), but detailed
- rtl_433: SoapySDR consumer that seeks to decode 315/433/868/915MHz transmissions
- URH: Universal Radio Hacker, good for investigating unknown protocols
- There's a solid paper from USENIX WOOT 2018
- IMSI-catcher: captures and decodes basic GSM traffic
- RTLSDR Scanner: lovely matplotlib output, only works with RTL-SDR
- gqrx-scanner: uses GQRX's remote control mechanism and adaptive channel detection
- LTE-Cell-Scanner: LTE base station detector
- spektrum: written in something called "Processing(?)"
- sorry, fam, but i don't fuck with programming languages that think they're gerunds
- rtl_power: scanner frontend for rtl_sdr; see rx_power above
- hackrf-spectrum-analyzer: fuck java, hell if i know
- hackrf_sweep: that's more like it, mows through the HackRF's 6GHz range. ugly.
- quisk: color scheme made me want to vomit, exited immediately
I've done all my transmitting thus far with GNU Radio, and honestly haven't generally known what I was doing.
The radio spectrum is managed by the International Telecommunications Union. It is typically understood to cover those frequencies up to 300GHz, though the ITU lays claim to all EM "propagated in space without artificial guide" under 3THz. Above 300GHz, the atmosphere becomes effectively opaque until the low infrared. Radio waves are generated by electrically-charged particles whenever they undergo acceleration, and are carried by photons, the gauge boson/quantum/force carrier of the electromagnetic force. All photons travel at the speed of light in their surrounding material, and have zero rest mass (but do acquire mass and momentum via movement). A wave's length decreases linearly as the frequency increases: a 300GHz wave has a corresponding wavelength of about 1mm, whereas a 30Hz wave has a wavelength of 10Mm (10 orders of magnitude in each case). Microwaves are just high-energy radio waves (roughly everything above 300MHz); they are generated in the same way.
The following historical terms are still regularly seen:
- Medium wave: 526.5--1606.5kHz (Europe), 525--1705kHz (US), channels every 9kHz (Europe) or 10kHz (US)
- Groundwaves propagate following Earth curvature, skywaves reflect off of the ionosphere
- AM radio
- Longwave: everything below 525kHz (approximately; no official definition). Sees groundwaves; skywaves are rare.
- Carrier frequencies every multiple of 9kHz, 153--279kHz
- Shortwave: 2--30MHz (approximately; no official definition). Sees skywaves.
The ITU defines 12 RF bands, starting at 1. Each band n begins at the wavelength 10n, and covers an order of magnitude of wavelength. The corresponding lower frequency is 3x108-nHz. Medium wave corresponds to the lower portion of band 6 (Medium Frequency). Longwave corresponds to bands 1 (Extremely Low Frequency) through 5 (Low Frequency), though most amateur radio takes place within band 5. Shortwave encloses the top half of band 6, along with band 7 (High Frequency).