HackRF: a low cost software radio platform built from hardware files and host tools
low cost software radio platform
At a glance
- What is it?
- HackRF is an open source SDR platform whose repository holds the board designs, the firmware and the host-side command line tools. It suits engineers who want a transmit-capable radio they can inspect down to the schematic, and it is the wrong choice for anyone expecting a packaged consumer receiver.
- Who is it for?
- Adopt HackRF if you need a half duplex transceiver you can reflash, script and repair, and if you accept that the host tools and the firmware are separate build targets. Do not adopt it if you want a receive-only scanner with a polished GUI, or if you need simultaneous transmit and receive on one radio.
- Can I use it commercially?
- Yes, with conditions. GPL-2.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 6 days ago.
- What is it written in?
- Mainly C, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 28, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The problem HackRF solves, and the people it is aimed at
Most radios ship as sealed boxes with a vendor driver and a fixed feature set. HackRF takes the opposite position. The repository is a full platform: hardware designs, firmware and host software in one tree, under GPL-2.0, with the principal author listed as Michael Ossmann. The stated purpose in the README is a low cost, open source Software Defined Radio platform, and the repository layout backs that up with separate firmware, hardware, host and tools directories.
The audience follows from that split. If you are writing software that needs to move samples between a computer and a radio, HackRF gives you a documented host API and a device you can reflash. If you are debugging an RF front end, the hardware directory gives you the design files rather than a datasheet summary. If you only want to listen to broadcast FM, this is a heavier path than a receive-only dongle, and the README does not present it as a consumer product.
The cost claim in the README is relative, not absolute. The README points to the Great Scott Gadgets site for information and purchasing, and it does not list prices itself. Anyone budgeting should treat the repository as the software and design half of the decision and the product page as the other half.
What is inside the repository: firmware, host tools and hardware files
The top level of the tree tells you more about the architecture than the README does. There is a firmware directory, a hardware directory, a host directory and a tools directory, plus docs, ci-scripts and a Dockerfile. That is three build targets in one repository, and they do not share a compiler.
The firmware is built with the arm-none-eabi toolchain, which the repository's Dockerfile installs as gcc-arm-none-eabi alongside dfu-util. The presence of dfu-util is the part worth noticing: firmware updates go over USB DFU, so a bad flash is recoverable with a host tool rather than a hardware programmer, provided the bootloader is intact.
The host side is C. The Dockerfile installs build-essential, cmake, pkg-config, libusb-1.0-0-dev and libfftw3-dev, which is the dependency set you would expect for a command line application that talks to a USB device and does FFT work. libusb is the transport; there is no kernel driver to install on Linux beyond udev rules, and the documentation covers those separately.
The hardware directory holds board designs. That matters for a different reason than the software: it means a HackRF is not a black box, and a failure on the RF side can be traced against the published design rather than guessed at. The README does not claim the hardware files are a manufacturing package, and it should not be read that way.
Installing the host tools and taking a first look at the device
The README does not carry an install section. It points to the documentation on Read the Docs, and it notes that the raw documentation files live in the docs folder and can be built locally with Sphinx by running make html. That is the authoritative source for build steps, and the exact commands differ per platform.
What the repository does give you is the dependency list, in the Dockerfile used for the project's hardware-in-the-loop CI. That file installs the build and library packages the project itself uses, and it is the closest thing to an official build recipe in the tree.
RUN apt-get update && apt-get install -y \
build-essential \
cmake \
curl \
dfu-util \
gcc-arm-none-eabi \
git \
libfftw3-dev \
libusb-1.0-0-dev \
pkg-config \
python3 \
python3-pip \
python3-yaml \
usbutils \
&& rm -rf /var/lib/apt/lists/*Once the host tools are built and installed, the documentation describes querying the attached radio before doing anything else, because that separates a USB or permission problem from a software problem. The README does not reproduce the exact invocation, so treat the Read the Docs pages as the source for it.
The host tools also include a receive path that writes samples to a file, and again the README does not list the flags. The output is raw IQ, not audio. You feed it to a separate demodulator, which is the point of an SDR and also the first surprise for people arriving from a scanner. The README does not document the demodulation step because it is out of scope for this repository.
PortaPack turns HackRF One into a standalone device, with a different support surface
A large share of the questions people ask about HackRF are about PortaPack, the add-on that gives HackRF One a screen and a control interface so it can run without a host computer. That is a separate project layered on top of this one, and the distinction matters when you are deciding what to install.
The host tools in this repository assume a computer at the other end of the USB cable. PortaPack does not. If your plan is a handheld device, the firmware you flash is not the firmware built from the firmware directory here, and the documentation in this repository will not walk you through the PortaPack menus. The README does not describe PortaPack at all.
This is not a criticism of the repository, which is scoped to the platform. It is a warning about where to look. Reading this tree to understand a PortaPack workflow is the wrong map.
Limitations: half duplex, USB bandwidth and the GPL boundary
The first constraint is duplex. HackRF is a half duplex radio. It transmits or it receives, not both at the same time on the same device. If your application needs a full duplex link, this platform cannot provide it, and no amount of host software will change that.
The second is the USB link. Samples cross a USB connection to the host, so sustained sample rates are bounded by that transport and by the host machine, not only by the radio. The documentation covers supported rates; anyone planning long recordings should read that section before assuming a rate will hold.
The third is the licence. The repository is GPL-2.0, and the COPYING file is at the top level. That is a copyleft licence, and it has consequences for anyone who wants to ship a modified version of the host tools or firmware inside a closed product. The repository also carries a TRADEMARK file, which is a separate matter from copyright: a permissive reading of the GPL does not give you the right to use the project's name on your own hardware. This is not legal advice, and anyone with a commercial plan should have the licence and the trademark file reviewed properly.
The fourth is support expectations, and the README is unusually explicit here. Issues labelled technical support by Great Scott Gadgets employees can expect a response time of two weeks. The README states that there are currently no expected response times for other issues or for pull requests. Plan accordingly if you are depending on upstream fixes.
HackRF against a receive-only SDR dongle
The obvious alternative for many buyers is a cheap receive-only dongle built on a mass market tuner chip. The difference is not quality, it is capability and control.
A receive-only dongle cannot transmit. HackRF can, which is why it appears in transmit-side work such as protocol research and signal generation. A dongle also hides its tuner behind a vendor driver, so the frequency range and sample rates are whatever that chip supports. HackRF publishes its design files in the hardware directory, so the front end is inspectable.
The trade is cost and complexity. A dongle is cheaper and often works after a single driver install. HackRF requires building or installing host tools, dealing with udev rules on Linux, and choosing a demodulator yourself. If your goal is listening, the dongle is the shorter path and the README does not pretend otherwise. If your goal is transmitting, or understanding the radio at the register level, the dongle is a dead end.
Maintenance, releases and what an upgrade actually costs
The repository is not archived, and the last push was on 2026-09-21, so development is current. The release history shows a versioned series: v2026.01.1 on 2026-01-05, v2026.01.2 on 2026-01-16 and v2026.01.3 on 2026-01-30. That cadence suggests patch releases within a version line rather than a constant stream of new features.
The upgrade cost is not uniform, because the repository ships two independently flashed things. Host tools upgrade like any other package: rebuild and reinstall. Firmware upgrades go over DFU, and the Dockerfile's inclusion of dfu-util shows the intended path. A firmware and host tool version mismatch is the kind of problem that produces confusing behaviour, so treat them as a pair when you upgrade.
What the README does not document is rollback. There is no stated procedure for returning to a previous firmware version if a new one misbehaves, and the release notes are not reproduced in the README. Before flashing, confirm the recovery path in the documentation rather than assuming one exists.
The licence position does not change with releases. GPL-2.0 applies to the code, the TRADEMARK file governs the name, and neither is affected by which version you build.
Editorial conclusion
Adopt HackRF if you need a half duplex transceiver you can reflash, script and repair, and if you accept that the host tools and the firmware are separate build targets. Do not adopt it if you want a receive-only scanner with a polished GUI, or if you need simultaneous transmit and receive on one radio. Before buying, check the greatscottgadgets.com product page for which board revision is current, and read the troubleshooting page on Read the Docs for the USB and driver problems that come up most often.
Frequently asked questions
What is a HackRF used for?
HackRF is a low cost, open source Software Defined Radio platform, so it is used to move radio samples between a host computer and a half duplex transceiver that can both receive and transmit. Typical work is protocol research, signal generation and inspecting the RF front end against the published hardware designs.
How do you install HackRF One?
The README does not carry install steps. It points to the documentation on Read the Docs, and notes that the raw documentation files are in the docs folder and can be built locally with Sphinx by running make html. The repository's Dockerfile lists the build and library packages the project itself uses, including libusb-1.0-0-dev, libfftw3-dev, cmake and pkg-config.
How do you use HackRF One?
After building the host tools, the documentation describes querying the attached radio first, which confirms that the device is visible and permissions are correct. A receive session then writes samples to a file, and the result is raw IQ samples rather than demodulated audio, so a separate demodulator is needed.
How do you use a HackRF PortaPack?
PortaPack is a separate add-on that gives HackRF One a screen and standalone operation, and this repository does not describe it. The host tools here assume a host computer connected over USB, so the documentation in this tree will not cover PortaPack menus or firmware.
Is HackRF better than Flipper Zero?
This repository does not cover Flipper Zero, so no comparison can be made from it. What the README does establish is that HackRF is a software defined radio platform with hardware designs, firmware and host tools in one GPL-2.0 tree.
Which is better, HackRF One or HackRF Pro?
The README does not compare board models. It points to the Great Scott Gadgets site for information on HackRF and purchasing, which is where model differences would be described.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/greatscottgadgets-hackrf)