Open-source project
opentx/opentx avatar
opentx/opentx

OpenTX 2.3: the long-lived firmware branch for RC transmitters

OpenTX custom firmware for Transmitters

2,191 stars837 forksC++GPL-2.0

At a glance

What is it?
OpenTX is custom firmware for radio-control transmitters, and the 2.3 branch of this repository is the one where development continues. The README is unusually short, so the interesting detail lives in the tree layout, the build system, and a release notes file that reads like a list of hardware problems being fixed one radio at a time.
Who is it for?
The thing worth understanding about this repository is that it is a firmware project, not an application, and the README reflects that by being a signpost rather than a manual. OpenTX 2.3.x development happens on the 2.3 branch, the last tagged release is 2.3.15 from April 2022, and commits have continued well past that, which tells you the branch is the place to watch rather than the tag.
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 80 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 October 11, 2026, and from our analysis. They are not legal advice.

Editorial analysis

A firmware project with a signpost-sized README

The repository description is four words: OpenTX custom firmware for Transmitters. That is accurate and it sets expectations. The entire README is a title, a row of badges, one sentence about ongoing development, and a list of links. The one sentence that matters is that ongoing development on 2.3.x is done in this branch, and the default branch confirms it at 2.3 rather than main. This is a maintenance branch for a version line, and treating the repository that way explains why the prose is thin.

For firmware, that is not a gap so much as a sign that the documentation lives somewhere else. The README sends you to the OpenTX wiki for information about setting up the tool chains for building OpenTX and OpenTX Companion, as well as other development related issues. It then lists a handful of destinations: the OpenTX main site at open-tx.org, OpenTx University at open-txu.org, the OpenTX user manual for the Taranis, and the OpenTX Lua reference guide. Language is C++, the licence is GPL-2.0 with GPLv2.txt sitting at the root of the tree, and the project carries just two topics, firmware and transmitter.

GitHub reports a push on 2026-07-23, so the branch is not dormant, and the repository is not archived. Stars sit at roughly 2,200 with 836 forks, and 295 open issues. The fork count is unusually high relative to stars for a firmware project, which fits a project where people maintain their own radio configurations and build variants.

What sits in the tree: radio, companion, launchpad

The top-level layout is where the project's shape becomes obvious. Three directories carry the real code. `radio/` is the firmware itself, with its own `sound/` subdirectory for the audio files a transmitter plays for warnings and prompts. `companion/` is the desktop configuration tool that talks to a radio over USB, the piece most people install before flashing anything. `launchpad/` is for the Texas Instruments LaunchPad targets, which is a separate build path from the consumer handhelds.

Alongside those sit the supporting directories: `cmake/` for the CMake modules, `jenkins/` for build automation, `tools/` for helper scripts, and `doc/` for documentation sources. A `CMakeLists.txt` at the root drives the build, and `sonar-project.properties` shows the project is wired into SonarQube for static analysis. Two smaller files tell you about the working style: `.clang-format` for C++ formatting and `.gitattributes` for line-ending handling, both of which suggest the contributors care about consistent output across platforms. `CREDITS.txt` is present at the root as well, which is the conventional place to keep contributor attribution for a GPL project.

The top level also shows the usual open-source furniture, including `.github/` for workflows, `.gitignore`, `.gitmodules` for submodule dependencies, and the license files. The unit test badge in the README points at `.github/workflows/unittests.yml`, which tells you there is a continuous integration path running tests on commits even though the README says nothing about it.

Reading 2.3.15 as a list of hardware problems

The release notes for 2.3.15, published on 2022-04-22, are the most informative document the repository has, and they read like a list of issues worked through on real hardware. The first two sections are radio-specific. Radiomaster Zorro gets support for ELRS and multi version, with a note that ELRS users need to choose internalELRS in the companion options, plus support for small size Access modules such as the R9M pro. Jumper T-Pro gets the same ELRS treatment and adds OpenTX controlled multipos function switches, with a link to the wiki page on function switches.

The third section, covering all radios, is where the protocol work shows. ELRS, Crossfire and Ghost modules now display extra information such as mixer rate or link speed during model setup. There is support for the Ghost 12bits protocol, and a fix for SBUS module timing entries not always working. Radios with a rotary encoder gain an option to invert the encoder direction in Radio Setup, throttle alerts are no longer dismissed when you nudge the rotary encoder, and the switch display on the main view is said to match the radio's physical layout better. There is also an improvement to mixer rate when the radio is used in joystick mode at 2ms, and a new USB telemetry mirror function for USB links, credited to a contributor named vimalb.

Read together, those entries say the multi-protocol radio module is the central concern of the 2.3 line. ELRS, the newer low-latency protocol, arriving alongside the established Crossfire and Ghost options is the substantive change, and the per-radio sections show that new transmitters are still being added to an established branch rather than waiting on a rewrite.

Lua is the extension surface, and it keeps getting fixes

The fourth block of the 2.3.15 notes is the Lua section, and it is worth separating from the hardware work because it describes what third-party scripts on a transmitter can do. The changes listed include a function for managed flybarred helicopter setups, a new flushAudio() function to clear the audio queue, better error message display on 128 screens, and a change where a Lua task preempts a long-running operation. None of those are headline features, and all of them are the kind of fix that only surfaces after real use on real radios.

Lua on a transmitter is a meaningful extension point because it lets the radio do things the firmware itself does not implement, from custom telemetry displays to model-specific logic. The existence of a dedicated Lua reference guide linked from the README confirms it is treated as a supported surface rather than an accident. The 2.3.15 notes treat Lua as a first-class citizen alongside the radio support, allocating it its own section, which is a reasonable signal that script authors are a significant part of the user base.

The 128-screen error display improvement is the kind of detail that tells you who the audience is. A radio with a small monochrome or colour screen needs errors rendered legibly in limited space, and that is not a concern for desktop software. When the notes mention improving throttle alert dismissal and matching switch display to physical layout, the reader is being reminded that this firmware runs on a handheld device with a screen, some buttons and a couple of knobs, often operated in bright outdoor conditions.

Version numbers, release tags, and what they do not say

There is a genuine mismatch between the version numbers a visitor expects and the version numbers the repository shows, and it is worth being precise about. The tag list holds three entries. release/2.3.15 was published on 2022-04-22 and carries full release notes. release/2.3.14 dates to 2021-07-23 and has an empty body. A tag literally named nightly was published on 2021-05-15, also with an empty body. So the most recent tagged release is 2.3.15, and the nightly tag is older than it, which is unusual enough to be worth noticing.

Meanwhile GitHub reports a push on 2026-07-23, more than four years after the last release tag. That gap is the honest reading of the project's status: the branch is still receiving work, but the release tags stopped moving. The README's own sentence, that ongoing development on 2.3.x is done in this branch, is consistent with maintenance-mode behaviour rather than a project winding down. The default branch being 2.3 rather than main reinforces that this repository is where 2.3.x lives.

Related searches for this project include OpenTX vs EdgeTX and Is OpenTx dead, which tells you what readers are actually trying to work out. The honest answer is that this repository does not address either. The README does not mention any successor firmware line, and the 2.3.15 notes give no hint of a planned successor. What the repository can tell you is that the 2.3 branch receives commits, and that 2.3.15 added ELRS support to current hardware, which is not the profile of something that stopped moving years ago.

Editorial conclusion

The thing worth understanding about this repository is that it is a firmware project, not an application, and the README reflects that by being a signpost rather than a manual. OpenTX 2.3.x development happens on the 2.3 branch, the last tagged release is 2.3.15 from April 2022, and commits have continued well past that, which tells you the branch is the place to watch rather than the tag. The hardware support in the 2.3.15 notes, ELRS alongside Crossfire and Ghost, is the concrete signal of what this branch is for, and the `radio/`, `companion/` and `launchpad/` directories are where any change you want to make will land. If you are building, the OpenTX wiki is the documented route for toolchain setup, since the repository itself only points there. And if you are trying to decide between this and a newer firmware line, note that the README does not discuss any successor, so that comparison is not something this repository will answer for you.

Frequently asked questions

What is the latest version of OpenTX?

The most recent tagged release is release/2.3.15, published 2022-04-22. A tag named nightly exists but is older, dated 2021-05-15. The repository has continued to receive pushes since then, with the last one on 2026-07-23, so development on the 2.3 branch continues without a newer release tag.

What does OpenTX do?

It is custom firmware for radio-control transmitters, written in C++ and released under GPL-2.0. It replaces the stock firmware on compatible handhelds and adds protocol support, scripting and configuration options. A desktop configuration tool called OpenTX Companion is built from the same repository.

How do you build OpenTX from source?

The repository does not document the build steps itself. It points to the OpenTX wiki for setting up the tool chains needed to build OpenTX and OpenTX Companion. At the root you will find a CMakeLists.txt, a cmake directory, and a jenkins directory for build automation.

Which radio protocols does the 2.3 branch support?

The 2.3.15 release notes describe ELRS, Crossfire and Ghost module support, including mixer rate and link speed info in model setup and support for the Ghost 12bits protocol. ELRS support was added for the Radiomaster Zorro and Jumper T-Pro, with internalELRS selected in the companion options.

Official sources

  1. Issues
  2. License: GPL-2.0
  3. opentx/opentx on GitHub
  4. README
  5. Releases
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.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/opentx-opentx.svg)](https://hysenlabs.com/projects/opentx-opentx)