hackrf-one¶
Half-duplex 1 MHz - 6 GHz software defined radio, transmit capable
Vendor: Great Scott Gadgets
Status: supported — the identifiers and setup recipe are believed correct.
Not maintainer-verified: nobody on this project has run this hardware yet. The two facts are recorded separately on purpose (D-027) — a correct recipe and a tested device are different claims.
What it is¶
A wideband half-duplex software defined radio covering 1 MHz to 6 GHz, able to transmit as well as receive. With a PortaPack attached it becomes a standalone handheld with a screen and controls, usually running the Mayhem firmware.
What you can do with it¶
Receive across a very wide range with gqrx, SDR++ or SDRangel, capture and replay signals, and — because it transmits — act as a signal source for test and development work.
Setup¶
Install the packages, add yourself to plugdev, log out and back in. Plug it in and run hackrf_info; it should report the serial and firmware version. The persistent symlink appears as /dev/hackrf-
Known problems¶
Transmit capability is why this device belongs with the consent-gated rf-research profile rather than rf-security when a profile carries it — no profile installs a HackRF host tool yet (rf-research's contents are pending Q-008), so today the gate is a statement of intent, not an installed fact. USB 2.0 bandwidth limits sustained sample rates; a poor cable or an unpowered hub shows up as dropped samples rather than as an error. Flashing a PortaPack firmware that does not match the hardware revision can leave the device needing a recovery flash.
How it identifies itself¶
| USB id | What | Confirmed | Node |
|---|---|---|---|
1d50:6089 |
HackRF One | yes | libusb |
1d50:604b |
HackRF Jawbreaker (predecessor) | yes | libusb |
1d50:cc15 |
rad1o badge, which speaks the HackRF protocol | yes | libusb |
⚠ 1d50:6089 is not unique to this device (shared_across_products; also used by: hackrf-pro). CONFIRMED BY CAPTURE 2026-08-26, not by the sweep: a HackRF Pro enumerates with this same 1d50:6089 and differs only in its product string ("HackRF Pro" against "HackRF One"). Upstream says so outright, which is stronger than the inference from one capture: usb_descriptor.c guards the 0x6089 idProduct with #if defined(IS_HACKRF_ONE) || defined(IS_PRALINE) -- one descriptor, two boards, Praline being the Pro's build name. Jawbreaker (0x604B) and rad1o (0xCC15) each get their own. The generated ambiguity list does NOT contain this pair -- usb.ids names it "Great Scott Gadgets HackRF One SDR", a product name, which the generator treats as evidence that a vendor bought an id for one device. That inference is sound in general and wrong here.
Access and permissions¶
Group membership required: plugdev — added at install, applies at next login.
The generated udev rule provides a /dev/hackrf symlink, mode 0660, group plugdev, matched on the product string HackRF One because the bare identifier is ambiguous.
Firmware modes¶
- dfu — tooling:
hackrf,dfu-utilhackrf_spiflash writes firmware; the device enumerates as 1fc9:000c while in the bootloader, which is why that identifier needs its own udev rule. A PortaPack running Mayhem is flashed the same way. Nothing here flashes anything automatically.
Software that makes it useful¶
gqrx-sdr, hackrf, sdrpp, soapysdr-module-hackrf
Upstream: https://greatscottgadgets.com/hackrf/