Check out my first novel, midnight's simulacra!
SDR
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.
Hardware
Hosted SDRs
The following SDRs all require an attached computer; they are not standalone devices.
| Device | Tuner | BW (MHz) | Samples (M) | ADC | Tune (MHz) | Xmit? | FPGA? | Bus | MSRP |
|---|---|---|---|---|---|---|---|---|---|
| RTL-SDRv3 | R820TR2 | 2.4 sustained 3.2 peak |
8 | 25--1750 | No | No | USB2A | $20 | |
| NooElec NESDR SMArt |
R820TR2 | 2.4 sustained 3.2 peak |
0.225--0.3 0.9--2.56 |
8 | 25--1750 | No | No | USB2A | $20 |
| NooElec NESDR SMArt XTR |
E4000 | 2.4 | 8 | 65--1100 1200--2300 |
No | No | USB2A | $35 | |
| SDRPlay RSP2 | 10 | 12 | DC--2000 | No | No | USB2B | $170 | ||
| SDRPlay RSP1A | MSI001 | 6 | 14 | DC--2000 | No | No | USB2B | $100 | |
| SDRPlay RSPDuo | 2x10 | 2--10.66 | 14 | DC--2000 | No | No | USB2B | $280 | |
| HackRF One | RFFC5072 | 20 | 2--20 | 8 | 1--6000 | Half | No | USB2Aµ | $300 |
| LimeSDR | LMS7002M | 61.44 | 2.5--30.72 | 12 | 10--3500 | 1x | Cyclone IV | USB3 | $300 |
| AirSpy R2 | R820TR2 | 10 | 2.5--10 | 12 | 24--1800 | No | No | USB2Aµ | $170 |
| AirSpy Mini | R820TR2 | 12 | 6 | 12 | 24--1750 | No | No | USB2Aµ | $100 |
| AirSpy HF+ | 0.768 | 16 | DC--31 60--260 |
No | No | USB2Aµ | $150 | ||
| 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 XC6SLX150 |
USB3B | $1100 |
| Ettus B200 USRP | AD9361 | 56 | 61.44 | 12 | 70--6000 | 1x | Spartan 6 XC6SLX75 |
USB3B | $675 |
| Per Vices Noctar | 250 | 125 | 12 / 16 | DC--4000 | 1x | Cyclone IV EP4CGX22C |
4xPCIe | $2500 | |
| Mirics MSi3101 | MSi001 | ||||||||
| FunCube Dongle Pro+ | 0.192 | 16 | 150--260 410--2050 |
No | No | USB2A | $200 | ||
| PlutoSDR | AD9363 | 20 | 61.44 | 12 | 325--3800 | 1x | Z-7010 | USB2Aµ | $150 |
| SignalHound BB60C | 27 | 0.3125--40 | 14 | DC--6000 | No | USB3Bµ | $2900 |
Antennae
Low-level software
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.
Kernel
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.
Userspace drivers
As noted above, most of these drivers work on raw USB devices. You'll need set up appropriate udev rules to give users permission.
| Family | Software | Source | Tools |
|---|---|---|---|
| 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 |
Middleware layers
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:
GrOsmoSDR
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
SoapySDR
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
High-level software
Suites
- 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.
Demodulators
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
- inspectrum: offline (no capture, only recorded files), but detailed
Wideband scanners
- RTLSDR Scanner: lovely mayplotlib 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.
Transmitters
- 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.
