# OpenRTX, open source firmware for digital amateur radios

> OpenRTX is a modular C firmware for digital amateur radios, built for DMR and with experimental M17 support, and it is distributed as per-device binaries you can flash. The project calls itself highly experimental and ships without any warranty.

**OpenRTX/OpenRTX** — Modular Open Source Radio Firmware

- Repository: https://github.com/OpenRTX/OpenRTX
- Website: https://openrtx.org
- Stars: 923 · Forks: 172
- Language: C
- License: not declared
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/openrtx-openrtx

## Firmware for ham radios, written as portable C

OpenRTX is free and open source firmware for digital amateur radio devices, designed top-down with modularity, flexibility and performance in mind. The primary language is C, and the repository layout shows a project built for multiple target platforms rather than one device.

The subject is amateur radio, and the digital modes it covers are DMR and M17. The project states plainly that it was created for research and amateur radio use only, and that the authors are not responsible for improper use of the code that might lead to unauthorized transmission, reception or patent infringements. That framing is normal for a firmware project, but it is worth reading before you flash anything: this is software that puts a transmitter on the air.

The project is explicit about its maturity. The firmware is described as highly experimental and currently under development, which the README says means it may not have all the expected functionalities. Contributions and testing are welcomed. The supported device list and the feature set per device live on the Development Status page on the project website rather than in the repository, which is the page to consult first when you are deciding whether your radio is covered.

The firmware is released without any warranty. The documentation says the code is always tested on the maintainers' own devices before publishing, but that they cannot guarantee the absolute absence of bugs or of potential side effects, and that anyone flashing a binary image does so at their own risk.

## Flashing a prebuilt image, with three ways to do it

You do not have to compile anything to use OpenRTX. Pre-built binary images for each of the supported devices are published on the releases page, and there are several ways to get one onto a radio.

The default route is the OEM firmware upgrade tool that came with the radio. Alternatively, and only for TYT MD-3x0 and MD-UV3x0 radios, there is the radio_tool program or tarxvf's web based flashing tool at dmr.tools. The restriction to those two radio families is a concrete detail worth knowing before you plan a workflow, because the generic OEM path is the one that works across the supported device list.

Detailed flashing instructions are on a dedicated user guide page on the project website, and the compilation instructions for building the firmware yourself, for hardware as well as for emulation on Linux, are on a separate page. The repository itself carries the toolchain configuration for cross compilation, in the files cross_cm4.txt and cross_cm7.txt, which correspond to Cortex-M4 and Cortex-M7 targets, plus an osx.txt file for macOS hosts.

The install sequence for a user is short: download the image for your device from the releases page, flash it with the OEM upgrade tool, and confirm the radio boots into it. The firmware itself then reports what it is doing on the device screen, which is where you find the settings menu and the mode selection.

## Nightly builds for the gap between releases

Release cadence is not the only way to get the code. Between releases, pre-built binary images containing the latest firmware updates are published as nightly builds from the master branch. Two locations are given: a page hosted by Phil DF5PMF and the OpenRTX nightly builds page on files.openrtx.org.

That arrangement suits the way this project is worked. The release list shows v0.4.5 tagged on 2026-10-04, with v0.4.4 in May 2026 and v0.4.3 in December 2025, so tags arrive every few months while commits land far more often. Nightly images mean a radio owner who wants the current work does not have to wait for the next tag, and the same images can be flashed with exactly the same procedure as a release.

The trade-off is the obvious one. A nightly image is built from a moving branch, so it carries whatever state the tree was in on the build night, including regressions that a tagged release would have avoided. The releases also carry a version string that the device displays, whereas a nightly build tells you less about exactly what you are running. The README says to read the disclaimer first before flashing anything obtained from the repository sources, and that warning is written with nightly users in mind as much as with release users.

## M17 support needs hardware you have to modify

From release version 0.3.3 onwards, the firmware provides experimental support for the M17 digital voice mode. The word doing the work there is experimental, and the next sentence sets the practical condition: making the digital mode work requires some modding. The project points to a dedicated hardware modifications page for the details.

That is the sharpest constraint in the whole project for anyone who wants M17. The firmware side is only half of it, and the hardware side is a soldering job on undocumented radios, which is why the acknowledgements thank the M17 community for bringing their libre protocol into obscure undocumented hardware in the first place.

M17 is an open digital voice protocol rather than a proprietary one, which is the point of the exercise. The list of radios currently supporting M17 is on the Development Status page under modes, so a specific model can be checked before you take a soldering iron to it.

For anyone with no interest in M17, the same page lists which devices support the other modes. OpenRTX is a DMR firmware first, with M17 as the experimental addition, and the mode support of your particular radio is the fact that decides whether this firmware is useful to you at all.

## Meson, cross compilation files and a Python toolchain

The repository layout shows a build system that treats the firmware as a set of layers. meson.build and meson_options.txt sit at the top level, CMakeLists.txt is present as well, and the source is split into lib/, openrtx/, platform/, meta/, scripts/, subprojects/ and tests/. The platform/ directory is the obvious place for the per-device differences, which is what a modular firmware for many radios needs. The tests/ directory and the CHANGELOG.rst file at the root are signs of a project with process.

The Python side of the build has its own dependency set, listed in requirements.txt:

```python
setuptools>=68.0.0
pyusb>=1.2.1
meson>=1.2.0
ffmpeg
cairosvg>=2.7.1
numpy>=1.25.2
intelhex==2.3.0
urllib3
gcovr>=7.2
```

Those entries explain a lot about the workflow. meson is the build system itself, ffmpeg and cairosvg handle the voice prompts, which are stored in a .vpc file in the repository and can be played back on the radio, numpy and intelhex deal with numeric work and firmware image conversion, pyusb talks to USB devices, and gcovr produces coverage reports from the test runs.

The voice prompt work is credited in the README to Joseph Stephen VK7JS, who implemented voice prompts, which is the kind of detail that shows the firmware is aimed at a real operator sitting in front of a radio rather than at a lab bench.

## A licence with per-component exceptions

The project states that the software is released under the GNU GPL v3, and it then lists the exceptions component by component, which is the correct way to handle a codebase that embeds other people's work. minmea is under the DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE v2, the QRCode library is under the MIT License, the code for the STM32F405 USB driver is under the MCD-ST Liberty SW License Agreement V2, and uf2conf.py and related files are released by Microsoft Corporation under the MIT licence.

The LICENSES/ directory at the top of the repository and the REUSE.toml file next to it indicate that the licensing is managed with the REUSE specification, where every file carries its own licence information rather than the project relying on a single root statement. For anyone who wants to reuse a piece of this firmware, that directory is the place to check which terms apply to the part they are interested in.

Note that the repository's own licence metadata is listed as unknown even though the README describes the terms in prose, so the file-level REUSE information is the authoritative record rather than the badge or the field in the hosting metadata.

The project also states that the code was made possible by the reverse engineering work of Travis Goodspeed and the contributors to md380tools, and it thanks Roger Clark and OpenGD77, which not only inspired the project but provided a working code example for the GD77 radio family. The credits are the historical record of where the reverse engineering came from, and they also tell you which radio families the code lineage touches.

## Where OEM firmware remains the better answer

The alternative to OpenRTX is the firmware that shipped with the radio, and for most operators it is the right choice. The OEM firmware is supported, tested by the vendor, and will keep working when the radio's own chips and radios are supported. OpenRTX offers two things the OEM firmware does not: an open source licence that lets you read and change what runs on your hardware, and modes such as M17 that the vendor will never add.

The difference in approach is the difference between a product and a project. The OEM firmware is a closed binary with a vendor behind it. OpenRTX is source you can read, port to a device the maintainers do not own, and patch yourself, at the cost of the disclaimers and the possibility of a nightly build that regressed.

There is also the hardware question. A supported radio may need no modification at all, in which case flashing a replacement firmware buys a licence and some features but adds risk to a device you depend on for emergency communication. For radios that need physical modification, the risk calculation is different again, and the decision becomes whether the openness and the M17 support are worth taking the device apart.

The practical test is the Development Status page. If your radio is listed with the features you want, OpenRTX is a genuine improvement over what the vendor shipped. If it is not listed, or if the features you want are marked experimental, the alternative remains the sensible one.

## Conclusion

OpenRTX suits licensed amateur radio operators who want to run their own firmware on a supported radio, want M17 or DMR features the OEM firmware does not offer, and are comfortable flashing hardware themselves. It does not suit anyone who needs a supported product with a warranty, or who cannot accept that the firmware is experimental and released without any warranty. Before you flash, check the Development Status page for your exact radio model and its supported features, read the disclaimer, and confirm you can meet the hardware modification the M17 support requires.

## FAQ

### What is OpenRTX and what radios does it support?

OpenRTX is free and open source firmware for digital amateur radio devices, written in C and built with meson. The list of currently supported devices and their features is on the Development Status page on openrtx.org, which also has a separate section for which radios support the M17 mode.

### How do I install OpenRTX on a radio?

Pre-built images for each supported device are on the releases page. You can flash them with the OEM firmware upgrade tool, or for TYT MD-3x0 and MD-UV3x0 radios with radio_tool or the web based dmr.tools flasher. Detailed instructions are on the user guide page of the project website.

### Does OpenRTX support M17, and what does it take?

Since release 0.3.3 the firmware provides experimental support for the M17 digital voice mode. Making it work requires hardware modifications, and the project points to a dedicated hardware modifications page with the details.

### Is OpenRTX safe to flash?

The project releases the firmware without any warranty and says that anyone flashing a binary image does so at their own risk. It states that the code is tested on the maintainers' own devices before publishing, while also saying it cannot guarantee the absence of bugs or potential side effects, and the firmware is described as highly experimental.

### What licence is OpenRTX released under?

The README states the software is released under the GNU GPL v3, with exceptions listed per component, including minmea under the DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE v2, QRCode under MIT, and the STM32F405 USB driver code under the MCD-ST Liberty SW License Agreement V2. The LICENSES/ directory and REUSE.toml hold the file level detail.

## Sources

- [Issues](https://github.com/OpenRTX/OpenRTX/issues)
- [OpenRTX/OpenRTX on GitHub](https://github.com/OpenRTX/OpenRTX)
- [Project website](https://openrtx.org)
- [README](https://github.com/OpenRTX/OpenRTX/blob/master/README.md)
- [Releases](https://github.com/OpenRTX/OpenRTX/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/openrtx-openrtx