Best SDR for Linux: RTL-SDR vs Nooelec vs Airspy vs HackRF

I wanted my cheap 433 MHz weather sensors in Home Assistant without buying another hub. The first lesson: the best SDR for Linux is decided by the driver stack more than the dongle. A $38 RTL-SDR stick will feed rtl_433, an ADS-B decoder or an HF receiver on any distro. It only works once the kernel’s DVB-T driver lets go of it and your librtlsdr knows the tuner inside. And the RTL-SDR Blog V4 everyone recommends is now end of life, replaced by a dongle whose tuner Ubuntu’s packaged library does not recognise yet.

Original content from computingforgeeks.com - post 179442

So I’ve ranked six radios by job: 433 MHz sensors into Home Assistant, ADS-B, HF and transmit. I ran the software side in November 2026 on an Ubuntu 26.04 LTS VM in my lab with rtl_433 25.12, and every command, error and MQTT topic below comes from that box. No dongle was plugged into it, so specs come from the makers’ datasheets and stock from Amazon that same day.

Picking an SDR in thirty seconds

Start from what you’ll actually decode, because the right dongle for a weather station is the wrong one for HF or for transmitting. Here’s where I’d put my money today:

• Best overall: RTL-SDR Blog V3, about $35 to $40, check the live price
• Best gift kit: Nooelec NESDR SMArt v5 bundle, about $50 to $60 with three antennas
• Best for ADS-B: ADSBexchange Blue stick, about $50 direct from the vendor
• Best V4 replacement: RTL-SDR Blog V4L, vendor store only for now
• Best for HF: Airspy HF+ Discovery, about $169 from Itead
• Best for transmit and 6 GHz: HackRF One, about $380 to $420 in the Nooelec bundle

If you only want sensor readings in Home Assistant, stop at the first line. Every RTL2832U stick on this list decodes 433 MHz just fine, and the extra money on the Airspy or HackRF buys range, bandwidth or transmit that rtl_433 can’t use.

Testing the Linux side without a dongle

I’ll be upfront about the method, because it shapes what you can trust here. The lab box was a fresh Ubuntu 26.04 VM on Proxmox with kernel 7.0. I installed every SDR package the archive carries and checked three things with them:

• package versions for rtl-sdr, rtl-433, airspy, airspyhf, hackrf and readsb
• what each package does to the kernel’s DVB driver
• what each tool prints when it can’t find hardware

That last one is the first thing you’ll see after a bad plug-in, so it’s worth knowing the exact wording.

For the 433 MHz pipeline I fed rtl_433 real radio recordings from the project’s own rtl_433_tests repository: an Acurite 592TXR tower sensor, a LaCrosse TX141THBv2 and a Nexus thermometer. Those are captures of real transmissions, so the decoder, MQTT topics and Home Assistant discovery messages below are what a live dongle would produce. What I couldn’t measure without the hardware is reception range, noise floor or heat, so I don’t quote any. Specs come from the RTL-SDR Blog, Nooelec, Airspy, ADSBexchange and Great Scott Gadgets pages, and the Amazon price and stock for each pick linked below were checked on 5 November 2026.

Comparing the six radios side by side

These columns are the ones that changed my decision. Coverage and the HF path decide what you can hear, and the package column decides whether it works on Ubuntu 26.04 today.

Radio	Tuner / coverage	HF	Bias tee	TX	Ubuntu 26.04 package	Price band
RTL-SDR Blog V3	RTL2832U + R860, 1 PPM TCXO	Direct sampling, 500 kHz to 28.8 MHz	4.5 V	No	rtl-sdr 2.0.2	$35 to $40
Nooelec NESDR SMArt v5	RTL2832U + R820T2/R860, 0.5 PPM TCXO, 100 kHz to 1.75 GHz	Direct sampling below 25 MHz	Not listed	No	rtl-sdr 2.0.2	$50 to $60 (bundle)
ADSBexchange Blue	RTL2832U + R820T2, 0.5 PPM TCXO, LNA, 1090 MHz filter	No	Not listed	No	rtl-sdr 2.0.2, readsb 3.16	About $50
RTL-SDR Blog V4L	RTL2832U + R828S, 1 PPM TCXO	Built-in upconverter	4.5 V	No	Needs librtlsdr 2.0.3	Vendor store
Airspy HF+ Discovery	0.5 kHz to 31 MHz and 64 to 260 MHz, 0.5 ppm	Native, with pre-selectors	Not listed	No	airspyhf 1.6.8	About $169
HackRF One	1 MHz to 6 GHz, 8-bit, 20 MSPS	Native from 1 MHz	3.3 V antenna power	Half-duplex	hackrf 2026.01.3	$380 to $420

Two things stand out. Four of the six are the same RTL2832U design underneath. They share one driver and one set of problems, and they differ mainly in the oscillator, the filtering and the HF path. The other is the V4L row: it’s the only dongle here that today’s Ubuntu LTS package can’t drive, which surprised me more than anything else in the lab.

1. RTL-SDR Blog V3

The V3 is the dongle I’d buy for rtl_433 and general listening. It’s cheap, it’s in stock on Amazon, and librtlsdr drives its R860 tuner (the renamed R820T2) with no special handling.

It pairs the RTL2832U with that R860 tuner, a 1 PPM TCXO and an SMA port. The 4.5 V bias tee switches on from software, which matters once you add an LNA or an active antenna. HF works through direct sampling from 500 kHz to 28.8 MHz, and the vendor says plainly that strong MW broadcast stations may need an extra filter. The aluminium case and thermal pad cool it passively, which the vendor says stops reception failing from heat above about 1.5 GHz.

Who it’s for: anyone starting with rtl_433, NOAA or ADS-B on a Pi or a mini PC. Skip it if HF is the main reason you’re buying, because direct sampling on the V3 is a compromise and the V4L or the Airspy do it properly. The dongle-only listing ran $37.95 with 3,138 ratings when I checked; check the live price on Amazon. The RTL-SDR Blog store also warns about clones in blue, green or silver four-screw cases, so buy from the vendor’s own listing.

2. Nooelec NESDR SMArt v5

The Nooelec bundle is the one I’d wrap as a gift. It arrives with three antennas and a tighter 0.5 PPM oscillator, so someone can plug it in and hear something that evening.

Inside it’s the same RTL2832U with an R820T2 or R860, so on Linux it uses exactly the same librtlsdr0 package and the same blacklist fix as the V3. Nooelec rates it at 100 kHz to 1.75 GHz with up to 3.2 MHz of instantaneous bandwidth, and it reaches below 25 MHz through direct sampling. The SMA port and aluminium case match the V3, and the stick sits in Nooelec’s own Amazon store with both the bare dongle and the bundle in stock.

Where it falls short: Nooelec’s page doesn’t list a bias tee, so if you plan to power an LNA through the coax, the V3 is the safer buy. The bundle was $54.95 and the bare dongle $44.95 when I looked. That’s roughly $10 over the V3 for the antennas and the oscillator; see the current bundle price.

3. ADSBexchange Blue ADS-B stick

For a dedicated plane tracker I’d buy a stick with the 1090 MHz filter and LNA built in. The ADSBexchange Blue is the one I could verify end to end.

It’s an R820T2 and RTL2832U with a 0.5 PPM TCXO, an amplifier and an on-board 1090 MHz filter. Linux sees an ordinary RTL-SDR, and readsb drives it with --device-type rtlsdr. The vendor’s own Orange stick is the same board without the filter, and ADSBexchange recommends the Blue for 1090 MHz and the Orange for 978 MHz UAT. That’s the trade-off in one sentence: the filter that keeps a nearby phone tower out of your decoder also makes the stick useless for 433 MHz sensors.

Skip it if one dongle has to do everything. The ASIN on the vendor’s page no longer resolves, and the FlightAware Pro Stick Plus isn’t available through Amazon’s API either. So this one is a direct buy at $49.99 from the ADSBexchange store. If you’d rather stay on Amazon, the V3 plus a separate 1090 MHz filter gets you most of the way.

4. RTL-SDR Blog V4L

The V4L is the dongle to wait for if you wanted a V4. On Ubuntu 26.04 it won’t work with the packaged library today, so it’s my pick only if you’re happy to install a newer librtlsdr.

RTL-SDR Blog ended the V4 because it ran out of R828D tuners, and the last third-party reels it tried turned out to be counterfeits. The V4L announcement explains the swap to the R828S: same PCB, HF upconverter, 1 PPM TCXO and 4.5 V bias tee, but a diplexed input instead of the V4’s triplexed filtering. In practice that means slightly better sensitivity and the same strong-signal behaviour as the V3. The genuine V4 listing on Amazon shows out of stock, while a third-party “SDR-V4” sits at $77.83, which I would not touch.

The Linux catch is the part I’d underline. Upstream osmocom rtl-sdr added V4 support in 2.0.0 and V4L support only in 2.0.3, while Ubuntu 26.04 and Debian 13 ship 2.0.2. The library on my lab box contains the “RTL-SDR Blog V4 Detected” string but no “Blog V4L” string, which is the model name the 2.0.3 change adds. Until your distro moves to 2.0.3, you have three ways to drive it:

• build osmocom rtl-sdr 2.0.3 from source
• build the rtl-sdr-blog fork
• use a distro that already ships 2.0.3, such as Debian testing

RTL-SDR Blog sells the V4L on its own store, eBay and AliExpress, and said in its August 2026 launch post that Amazon stock should follow in about two to three months.

5. Airspy HF+ Discovery

If HF is the point (shortwave, ham bands, utility stations), the Airspy HF+ Discovery is the receiver I’d save for. It was designed for those bands instead of reaching them through a trick. An SDR only listens, though. If the goal is to talk on those bands, that’s a licensed handheld first, and I ranked the beginner ham radio picks by how cleanly CHIRP programs them from Linux.

Airspy lists 0.5 kHz to 31 MHz on HF and 64 to 260 MHz on VHF. It has four HF pre-selector banks, an 18-bit digital down-converter, up to 768 ksps of IQ and a 0.5 ppm clock. The narrow output is deliberate: you get a slice of spectrum with a much cleaner floor, which is the opposite of the wideband RTL approach. On Linux the user-mode driver is the open-source libairspyhf, packaged in Ubuntu 26.04 as airspyhf 1.6.8, and GQRX is on Airspy’s supported software list. Airspy’s SPY Server can also stream the receiver over the network.

Skip it for 433 MHz or ADS-B, since it stops at 260 MHz. Airspy sells through dealers rather than Amazon, and the official Itead store listed it at $169.00. The sibling Airspy Mini (24 to 1700 MHz, 12-bit ADC) also handles ADS-B. readsb has no native Airspy type, though, so you’d go through SoapySDR or Airspy’s own ADS-B SPY decoder.

6. HackRF One

The HackRF One is the only radio here that transmits, and that’s the only reason I’d pay ten times the price of a V3 for it.

Great Scott Gadgets rates it at 1 MHz to 6 GHz, half-duplex, up to 20 MSPS of 8-bit I/Q over USB 2.0, with no antenna in the box. The Nooelec listing I’d link is the authorised bundle with the ANT500 telescopic antenna and SMA adapters; random “HackRF” PortaPack kits from other sellers aren’t the same thing. On Ubuntu 26.04 the hackrf package is 2026.01.3, matching the current firmware release, and it ships /etc/modprobe.d/libhackrf0.conf, the only blacklist any of these packages installed on my box.

Who should skip it: anyone who only receives. Half-duplex 8-bit sampling buys you nothing at 433 MHz over a V3, and the Airspy’s pre-selectors make it the better HF receiver. It earns its price on jobs like these, within the usual legal limits on where you may transmit:

• replaying your own garage remote
• testing a LoRa node you built
• learning GNU Radio with real TX

The bundle was $399.95 with 113 ratings; check the current price. Great Scott Gadgets has also announced the HackRF Pro (100 kHz to 6 GHz, TCXO, USB-C), sold through select retailers rather than Amazon.

Getting the DVB driver out of the way

To the kernel, every RTL2832U dongle here is a DVB-T TV tuner. The in-tree dvb_usb_rtl28xxu driver claims it on plug-in unless something stops it. I expected the Ubuntu package to do that for me, because older guides say it does. It did not. After installing rtl-sdr, dpkg -L librtlsdr0 listed an empty /etc/modprobe.d directory and nothing in it, while modprobe --showconfig still mapped USB ID 0bda:2838 straight to the DVB driver.

Install the tools first. These are the packages the rest of this guide uses, all from Ubuntu’s universe repository:

sudo apt install -y rtl-sdr rtl-433 mosquitto mosquitto-clients python3-paho-mqtt

Then write the blacklist yourself and add your user to plugdev, because the package’s udev rule gives the dongle to that group with mode 0660. My default cloud-init user wasn’t in it:

echo "blacklist dvb_usb_rtl28xxu" | sudo tee /etc/modprobe.d/blacklist-rtlsdr.conf
sudo usermod -aG plugdev $USER

Confirm modprobe sees the blacklist before you plug the stick in. The first line is the one that matters; the alias lines below it are the USB IDs the DVB driver would otherwise grab:

sudo modprobe --showconfig | grep rtl28xxu

On my box it printed the blacklist followed by 35 alias lines. These are the blacklist and two of the aliases, including the generic RTL-SDR ID:

blacklist dvb_usb_rtl28xxu
alias usb:v0413p6680d*dc*dsc*dp*ic*isc*ip*in* dvb_usb_rtl28xxu
...
alias usb:v0BDAp2838d*dc*dsc*dp*ic*isc*ip*in* dvb_usb_rtl28xxu

Log out and back in for the group change. A blacklist only stops future loads, so if the dongle was already plugged in and the DVB module loaded, reboot once. The screenshot below is the whole check on the lab VM, including the library string search that tells you whether your librtlsdr knows the V4:

If strings finds “RTL-SDR Blog V4 Detected”, a V4 will work with your packaged library. For a V4L, grep for “V4 Lite” or “Blog V4L” instead; the 2.0.3 change adds those strings, and a search for V4L in the 2.0.2 build on my box found nothing.

What each tool prints when it can’t see the radio

These are the exact messages from the lab box with no hardware attached. With a dongle plugged in, one of these usually means the DVB driver, a missing plugdev membership, or a library that doesn’t know the tuner:

Command	Message	Exit code
rtl_test -t	No supported devices found.	1
rtl_433	[SDR] No supported devices found.	2
readsb --device-type rtlsdr	FATAL: rtlsdr: no supported devices found.	exits with sdrOpen() failed
hackrf_info	No HackRF boards found.	1
airspy_info	airspy_open() board 1 failed: AIRSPY_ERROR_NOT_FOUND (-5)	0
airspyhf_info	No devices attached.	1
SoapySDRUtil --find	No devices found!	1

Watch the airspy_info row in scripts. It exits 0 even when nothing is attached, so a health check that only tests the exit code reports a missing Airspy as fine.

Wiring rtl_433 into Home Assistant

This is the part that sold me on a $38 dongle. The path is short. rtl_433 decodes the sensors and publishes to Mosquitto, a script that ships with rtl_433 turns those topics into discovery messages, and Home Assistant picks the sensors up with no YAML. If you don’t run Home Assistant yet, our guide to installing Home Assistant on Ubuntu 26.04 covers the server side.

Before touching MQTT, prove the decoder works. I ran rtl_433 against a recording of an Acurite tower sensor with signal levels turned on, which shows the frequency, RSSI and SNR you’d watch when placing an antenna:

rtl_433 -M level -M time:iso -r acurite-592txr-003.cu8 -F json

It decoded the sensor at 434.003 MHz with a 17 dB SNR, and printed the same message three times because the sensor repeats each transmission:

{"time" : "2026-11-05T19:37:14", "model" : "Acurite-Tower", "id" : 12053, "channel" : "C", "battery_ok" : 1, "temperature_C" : 26.700, "humidity" : 74, "mic" : "CHECKSUM", "mod" : "ASK", "freq" : 434.003, "rssi" : 0.632, "snr" : 17.133, "noise" : -17.134}

The LaCrosse TX141THBv2 and Nexus recordings decoded on the first try as well. Those repeats matter later, because each one reaches MQTT as its own message, so Home Assistant sees three updates per reading.

Publishing to Mosquitto

Enable the broker first. On Ubuntu 26.04 Mosquitto 2.0 listens only on 127.0.0.1:1883 by default, which is fine when rtl_433 and the discovery script run on the same box:

sudo systemctl enable --now mosquitto

With a dongle attached, run rtl_433 with SI units (the discovery script expects them) and the MQTT output. My lab run used the same flags against the replayed recording described below:

rtl_433 -C si -F "mqtt://localhost:1883,retain=0"

rtl_433 announces where everything goes. Note that the default base topic includes the hostname, box1 on my VM, so the topics change if you move rtl_433 to another machine:

MQTT: Publishing MQTT data to localhost port 1883
MQTT: Publishing availability to MQTT topic "rtl_433/box1/availability".
MQTT: Publishing device info to MQTT topic "rtl_433/box1/devices[/type][/model][/subtype][/channel][/id]".
MQTT: Publishing events info to MQTT topic "rtl_433/box1/events".
MQTT: Publishing states info to MQTT topic "rtl_433/box1/states".

My first attempt here published nothing. I’d pointed rtl_433 at the recording with -r file.cu8 -F mqtt://.... rtl_433 25.12 finished the file and exited before the MQTT connection completed, and the Mosquitto log only showed a client that connected and closed. Piping the file over stdin did the same. What worked was serving the recording through a tiny local rtl_tcp emulator and pointing rtl_433 at it with -d rtl_tcp:127.0.0.1:1234, so it ran its normal live loop. With real hardware you will not hit this, but if you test your MQTT wiring with a recording, don’t trust an empty topic tree.

The broker received an events topic carrying the whole JSON message, plus one devices topic per field:

Both topic trees need to exist for the next step, so keep the default topics instead of a custom devices= layout.

Turning topics into Home Assistant entities

The Ubuntu package already ships the discovery script, so there’s nothing to download. It subscribes to rtl_433/+/events and publishes retained config messages under homeassistant/:

python3 /usr/share/doc/rtl-433/examples/rtl_433_mqtt_hass.py -H localhost -r

It warned that no MQTT user or password was set and printed a paho-mqtt deprecation warning about callback API version 1. Neither one stopped it, and it is safe to ignore both. Both rtl_433 and this script run in the foreground, so use two terminals while you test, and a systemd service or the Home Assistant add-on below for anything that has to survive a reboot. Within a few seconds the broker held ten config topics for the two Acurite sensors, five per device:

homeassistant/sensor/Acurite-Tower-B-9884/Acurite-Tower-B-9884-UTC/config
homeassistant/device_automation/Acurite-Tower-B-9884/Acurite-Tower-B-9884-CH/config
homeassistant/sensor/Acurite-Tower-B-9884/Acurite-Tower-B-9884-B/config
homeassistant/sensor/Acurite-Tower-B-9884/Acurite-Tower-B-9884-T/config
homeassistant/sensor/Acurite-Tower-B-9884/Acurite-Tower-B-9884-H/config

T and H become temperature and humidity entities. B is a battery sensor that maps rtl_433’s 0 or 1 to 1 or 100 percent, and the UTC timestamp arrives disabled. Point Home Assistant’s MQTT integration at this broker and the devices appear on their own. If Home Assistant runs on a different machine, Mosquitto’s localhost-only default will block it. Before you hunt for a bug elsewhere, change three things:

• add a listener on the LAN address
• create an MQTT user and password
• pass them to rtl_433 with user= and pass=, and to the script with -u and -P

Running Home Assistant OS instead? The rtl_433 add-on repository packages the same decoder and discovery script.

This sits alongside a Zigbee setup rather than replacing it. Cheap 433 MHz sensors are one-way and unencrypted. I use them for weather and freezers, and I leave locks and leak valves on the protocols compared in ZHA vs Zigbee2MQTT.

Feeding ADS-B with readsb

Ubuntu 26.04 carries readsb 3.16 in universe, so an ADS-B receiver is one apt install readsb away, and dump1090-mutability is there too. The build options line is the useful part of its help output, because it tells you which radios it can open directly:

Build options: ENABLE_RTLSDR ENABLE_BLADERF ENABLE_PLUTOSDR ENABLE_SOAPYSDR

RTL sticks, including the ADSBexchange Blue, use --device-type rtlsdr. An Airspy has no native type in this build. It goes through --device-type soapysdr with the soapysdr-module-airspy package, which on my box returned “soapy: no matching devices found” as expected with nothing attached. Blacklist the DVB driver first, exactly as above, or readsb stops with the FATAL line from the table. A Raspberry Pi is plenty for one feeder; our Raspberry Pi 5 kit picks cover the board and power side.

Choosing by job, not by spec sheet

Most people asking for the best SDR for Linux really want one of four outcomes, and each maps to a different radio:

• 433 MHz sensors into Home Assistant: RTL-SDR Blog V3
• A 24/7 plane feeder: ADSBexchange Blue, or V3 plus a 1090 MHz filter
• Shortwave and ham bands: Airspy HF+ Discovery
• Transmit, replay and GNU Radio work: HackRF One
• A first radio as a gift: Nooelec SMArt v5 bundle

Running both rtl_433 and ADS-B? Buy two dongles. One RTL stick can only tune one frequency at a time, and a filtered ADS-B stick can’t hear 433 MHz anyway. Put them on a small always-on box, such as one of the mini PCs we recommend for Home Assistant. Give each one its own USB extension so they aren’t cooking side by side.

What I still don’t know

I have not run any of these dongles on real air in this lab. So I can’t tell you how far the V3 hears a cheap Acurite through two walls, or how much the Blue’s filter adds in a city. Those numbers depend on your antenna and your neighbours more than the stick, and I’d rather leave them out than borrow someone else’s. I also do not know when Ubuntu will pick up librtlsdr 2.0.3. Until it does, the V4L means building the library yourself, which is a fair price for HF and a poor one for a weather station.

The other open question is the rtl_433 file-replay behaviour with MQTT. I saw it on 25.12 with both -r and stdin, and I have not checked whether a nightly build changes it. If you’re building something on ESPHome next to this, our list of ESP32 boards for ESPHome covers the other half of a local-only sensor setup.