The drone stack has more layers than the aircraft.

The ExpressLRS recovery story was about the radio link.

The Betaflight firmware post was about the flight controller.

The dRehmFlight post was about readable Arduino/Teensy flight-control code.

EdgeTX is the transmitter side.

It is the firmware that runs on the radio in your hands.

That means models, switches, mixes, timers, telemetry screens, Lua scripts, RF module setup, SD card content, sounds, warnings, and the user interface you actually touch before the aircraft moves.

EdgeTX is open-source firmware for RC radio transmitters. It is a community-driven continuation of the OpenTX family, focused on modern transmitter hardware, touchscreen/color radios, Lua scripting, telemetry, RF module integration, and target-specific builds.

EdgeTX GitHub Source Code EdgeTX Website EdgeTX Manual EdgeTX Releases EdgeTX Buddy EdgeTX Lua Documentation License: GPL-2.0

What is EdgeTX?

EdgeTX is firmware for RC transmitters.

It does not fly the drone directly.

It turns pilot input into channel output, module control, telemetry display, model logic, warnings, audio, scripts, and radio-side behavior.

In a normal FPV setup, the simplified chain looks like this:

your hands
  -> EdgeTX radio model, inputs, mixes, switches
  -> ExpressLRS or another RF module
  -> receiver
  -> Betaflight or another flight controller
  -> motors and servos

That is why EdgeTX deserves a separate post.

If the transmitter model is wrong, the aircraft can still behave wrong even when the receiver firmware and flight-controller firmware are both correct.

Modes, channel order, arming switch, throttle cut, failsafe expectations, telemetry warnings, and RF module settings all begin on the radio.

Why It Matters

EdgeTX is the layer where RC flying becomes programmable for the pilot.

On the flight controller, you configure the aircraft.

On the transmitter, you configure how you command the aircraft.

That includes:

  • radio profiles and models
  • inputs and mixers
  • curves and flight modes
  • logical switches and special functions
  • telemetry sensors and warnings
  • audio prompts and sound packs
  • Lua tools and widgets
  • internal and external module settings
  • simulator and desktop workflows through Companion

For FPV and RC users, that is not cosmetic.

A clean transmitter setup can make arming, mode switching, telemetry warnings, GPS rescue, turtle mode, trainer mode, and model switching safer and easier to reason about.

Repository Snapshot

I cloned and inspected:

repo: https://github.com/edgetx/edgetx
HEAD: 884b306592f3
describe: nightly-2-g884b306592
license: GPL-2.0

The current GitHub page described the project as open-source firmware for R/C radios, and the latest release shown there was EdgeTX “Queen Anne’s Revenge” v2.12.2, published on June 21, 2026.

The local checkout had active work around firmware fixes, key lock support, iFlight Commando 14 support, RadioMaster and HelloRadioSky variants, serial gimbal handling, switch handling, and generated target metadata.

The main repo areas are:

Path What It Contains
radio/ transmitter firmware source, board targets, HAL, GUI, telemetry, pulses, Lua, storage, tests
companion/ EdgeTX Companion desktop tooling and simulator integration
web/ browser-based WebAssembly simulator shell
docs/ MkDocs developer and build documentation
tools/ build scripts, target helpers, generated data validation, firmware utilities
cmake/ CMake modules, native/ARM/WASI toolchain helpers, dependency fetchers
fw.json release target index used by tooling
CMakePresets.json firmware, companion, simulator, and test presets

This is a large embedded firmware project, not a single Arduino sketch.

Tech Stack

The stack is broader than “C firmware”.

Layer Technology
Firmware languages C and C++
Build system CMake, CMake presets, Ninja-compatible workflows
Firmware toolchain arm-none-eabi for radio firmware builds
Native tooling Qt 6 for Companion and desktop simulator paths
Scripting Lua on the radio and simulator
RTOS and embedded libraries FreeRTOS, STM32 HAL, CMSIS, FatFs, LVGL on relevant targets
Target metadata hardware definition JSON/YAML generation and validation scripts
Web simulator Svelte, Vite, TypeScript, WebAssembly, WASI threads
Browser storage/runtime SharedArrayBuffer, Atomics, OPFS, WebGL LCD rendering
Documentation MkDocs

So yes: EdgeTX is embedded firmware.

But the repo also includes desktop and web tooling around that firmware.

That is what makes it different from dRehmFlight.

dRehmFlight is compact and educational.

EdgeTX is a production transmitter firmware ecosystem.

Supported Radios and Targets

The fw.json file in this checkout listed 42 firmware targets.

Examples include:

  • RadioMaster TX16S
  • RadioMaster TX16S MK3
  • RadioMaster Boxer
  • RadioMaster Pocket
  • RadioMaster Zorro
  • iFlight Commando 8
  • iFlight Commando 14
  • Jumper T15, T16, T18, T20, T22
  • FrSky Horus X10, X10 Express, X12S
  • FrSky QX7 Access
  • Flysky PL18, PL18EV, PL18U, NV14, NB4+
  • HelloRadioSky V14, V14LCD, V16

That target list matters.

Like Betaflight, EdgeTX is not just “build firmware”.

It is “build firmware for a specific board, revision, display, input layout, switches, storage, RF module assumptions, and feature set”.

The documented build flags make that explicit:

cmake --fresh -S . -B build-output -Wno-dev \
  -DPCB=X10 \
  -DPCBREV=TX16S \
  -DDEFAULT_MODE=2 \
  -DCMAKE_BUILD_TYPE=Debug

For a RadioMaster TX16S, the docs use:

PCB=X10
PCBREV=TX16S

That same idea appeared in the Betaflight post: hardware names are not decorative.

They decide the firmware you should build or flash.

Radio Protocols and ExpressLRS

EdgeTX is not ExpressLRS.

ExpressLRS is RF link firmware for transmitters and receivers.

EdgeTX is the radio operating system that can talk to internal or external RF modules.

The developer docs include external module protocol notes for:

  • PPM
  • PXX
  • ACCESS
  • DSM2
  • SBUS
  • Multiprotocol modules
  • Crossfire

The Crossfire/CRSF path is the important one for many ExpressLRS users, because ExpressLRS commonly uses the CRSF ecosystem for control and telemetry.

The repo also contains Companion-side ExpressLRS updater integration and CRSF/ELRS telemetry simulation UI references.

That makes EdgeTX a natural neighbor to the ExpressLRS post.

The radio can run EdgeTX while the external module runs ExpressLRS.

They solve different parts of the same control chain.

Companion and Buddy

EdgeTX is not only firmware.

The project also connects to two important user workflows:

Tool Role
EdgeTX Companion desktop application for model management, radio profiles, simulation, backups, and firmware-related workflows
EdgeTX Buddy browser-based flashing/updating workflow linked from the EdgeTX project

In the source tree, companion/ is the Qt desktop side.

It is useful because transmitter configuration can be complex enough that editing, backing up, comparing, and simulating models from a computer is often safer than doing everything on the radio screen.

The post-flight analogy would be:

Betaflight App configures the flight controller.
EdgeTX Companion configures and simulates the transmitter/model side.

They are not the same kind of app, but they play similar roles in their own layers.

The Web Simulator

The web/ folder is a browser-based EdgeTX radio simulator shell.

It uses:

  • Svelte
  • Vite
  • TypeScript
  • WebAssembly
  • WASI threads
  • SharedArrayBuffer
  • Atomics
  • OPFS storage
  • WebGL LCD rendering

The browser requirements are not trivial.

Threaded WebAssembly needs cross-origin isolation headers:

Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin

That is why the web simulator is more than a static page with JavaScript.

It is still deployable as static assets, but the host must serve the right headers for SharedArrayBuffer and WASM threads.

Cloudflare Pages can do this with a _headers file, which the repo already includes under web/public/_headers.

Local Trial

I checked the local environment:

cmake: 3.28.3
python: 3.12.3
node: 22.22.0
npm: 10.9.4
ninja: present
arm-none-eabi-gcc: not present

Then I validated the firmware target index:

python3 tools/validate-json.py fw.json

That passed:

JSON syntax is valid
fw.json schema validation passed - found 42 targets
All targets are in alphabetical order
All EdgeTX fw.json validations passed

I also regenerated the web simulator radio index:

node web/scripts/gen-radios-json.js

That generated 41 radios.json entries and skipped x9e-hall because no hardware definition JSON was found for that flavor.

For a native simulator configure, I tried:

cmake --preset simu -DPCB=X10 -DPCBREV=TX16S -DDEFAULT_MODE=2

That did not complete because Qt6 development packages are not installed locally:

Could not find a package configuration file provided by "Qt6"

So the local result is:

metadata validation: passed
radio index generation: ran
native simulator configure: blocked by missing Qt6
real firmware build: not attempted because arm-none-eabi-gcc is missing

That is a fair result for this machine.

EdgeTX is a serious firmware project; the documented path expects the proper build environment or the official Docker/devcontainer setup.

How to Build the TX16S Example

The project docs use a RadioMaster TX16S example.

The shape is:

git clone --recursive -b main https://github.com/EdgeTX/edgetx.git edgetx_main
cd edgetx_main
mkdir build-output

cmake --fresh -S . -B build-output -Wno-dev \
  -DPCB=X10 \
  -DPCBREV=TX16S \
  -DDEFAULT_MODE=2 \
  -DCMAKE_BUILD_TYPE=Debug

cmake --build build-output --target arm-none-eabi-configure
cmake --build build-output --target firmware --parallel

If successful, the documented firmware binary lands under:

build-output/arm-none-eabi/firmware.bin

Do not treat that as a generic flashing command.

For a real radio, you need the correct target, the correct SD card pack, and the correct flashing path for the device.

Where It Fits in the RC Stack

The recent posts now map cleanly:

Layer Project
Radio transmitter firmware EdgeTX
Radio link firmware ExpressLRS
Flight-controller firmware Betaflight
Browser/desktop flight-controller UI Betaflight App
Flight log analysis Betaflight Blackbox Explorer
Educational custom VTOL firmware dRehmFlight

That separation matters.

EdgeTX does not replace ExpressLRS.

ExpressLRS does not replace Betaflight.

Betaflight does not configure the radio model in your hands.

dRehmFlight does not try to be the whole transmitter and FPV ecosystem.

Each project owns a different failure surface.

FAQ

Is EdgeTX embedded firmware?

Yes.

EdgeTX is embedded firmware for RC transmitters.

It runs on radio hardware and handles the transmitter-side operating environment: controls, model logic, mixers, telemetry, display UI, storage, Lua scripts, RF module setup, warnings, and audio.

The repo also includes desktop and web tooling, but the core project is firmware.

How is EdgeTX different from ExpressLRS?

EdgeTX runs on the radio transmitter.

ExpressLRS runs on RF transmitter modules and receivers.

In a common setup, your radio runs EdgeTX, and your external or internal RF module runs ExpressLRS.

EdgeTX decides model behavior, switches, mixes, channel output, telemetry display, Lua tools, and module settings.

ExpressLRS handles the radio link between transmitter module and receiver.

They are complementary, not alternatives.

How do EdgeTX, ExpressLRS, and Betaflight work together?

Think of them as three separate firmware layers in one control chain:

Layer Firmware Runs On Job
Pilot command layer EdgeTX RC radio transmitter Reads sticks, switches, model mixes, Lua scripts, telemetry screens, and module settings
Radio link layer ExpressLRS TX module and RX receiver Carries control data and telemetry over the air
Aircraft control layer Betaflight flight controller inside the drone Reads receiver data and sensors, then drives motors, servos, OSD, blackbox, and failsafe behavior

The data path usually looks like this:

sticks and switches
  -> EdgeTX model/mixer/channel output
  -> ExpressLRS TX module
  -> radio link
  -> ExpressLRS receiver
  -> CRSF/UART into Betaflight
  -> flight-control loop and motor output

That is why the projects are easy to confuse but should not be mixed together.

EdgeTX does not provide the RF link by itself.

ExpressLRS does not configure your radio model.

Betaflight does not decide which radio switch is your arming switch until EdgeTX and the receiver send that channel data to it.

For a practical FPV build, you normally need all three configured coherently: the EdgeTX model, the ExpressLRS bind/link, and the Betaflight receiver/UART/mode setup.

How is EdgeTX different from Betaflight?

Betaflight runs on the flight controller inside the aircraft.

EdgeTX runs on the radio in your hands.

Betaflight reads receiver input and sensors, then drives motors, servos, OSD, blackbox logging, and flight-control behavior.

EdgeTX defines what your sticks, switches, model mixes, telemetry screens, and radio-side scripts send toward the aircraft.

If Betaflight is the aircraft control layer, EdgeTX is the pilot command layer.

How is EdgeTX different from dRehmFlight?

dRehmFlight is small, readable Arduino/Teensy flight-controller firmware for custom VTOL experiments.

EdgeTX is a production transmitter firmware ecosystem for many radio targets.

dRehmFlight teaches how receiver input and IMU data become motor and servo output on an aircraft.

EdgeTX controls the radio-side model, mixer, switches, telemetry, scripts, and RF module interface before the signal even reaches the receiver.

Are there open-source alternatives to EdgeTX?

Yes, but the practical answer depends heavily on your transmitter hardware.

Project Best Fit Notes
OpenTX Older FrSky/Jumper/RadioMaster-era radios and users already on the OpenTX workflow OpenTX is the historical parent/sibling project. Many concepts carry over, but EdgeTX is the more active default for many modern color/touch radios.
er9x / erskyTx Older 9x-style radios, some FrSky/RadioMaster/Jumper targets, and users who already know that ecosystem Long-running open transmitter firmware family with its own tools and community. It is relevant, but more niche than EdgeTX for current FPV radios.
DeviationTX Walkera Devo and some compatible multiprotocol transmitters Strong fit for supported Devo-era hardware and multiprotocol model control, but it is not a drop-in EdgeTX replacement for modern RadioMaster-style EdgeTX radios.
Proprietary radio firmware FrSky ETHOS, Spektrum AirWare, Futaba, Jeti, etc. Not OSS, but worth naming because many pilots choose them for vendor integration and support instead of source-level control.

For a modern FPV radio such as a RadioMaster Boxer, Pocket, Zorro, or TX16S, EdgeTX is usually the practical open-source default.

For older hardware, OpenTX, er9x/erskyTx, or DeviationTX may still make sense.

The important rule is: choose firmware by exact transmitter target, not by name recognition.

How is EdgeTX related to OpenTX?

EdgeTX comes from the OpenTX family and presents itself as the cutting edge of OpenTX.

Practically, that means many concepts will feel familiar to OpenTX users: models, inputs, mixes, logical switches, special functions, telemetry, SD card content, Companion workflows, and Lua scripting.

The reason people move to EdgeTX is usually active support for modern radios, color/touchscreen workflows, community-driven development, and newer features.

Do I need EdgeTX Companion or EdgeTX Buddy?

Not for every small change, but they are useful.

EdgeTX Companion is the desktop tool for radio profiles, model management, simulation, backup, comparison, and firmware-related workflows.

EdgeTX Buddy is the browser-based flashing/updating path linked by the project.

For a serious radio setup, a backup workflow is worth having.

Radio model configuration is part of the safety chain.

Does EdgeTX support ExpressLRS and CRSF?

EdgeTX includes Crossfire/CRSF-related module and telemetry support, and that is the relevant path for many ExpressLRS setups.

The key distinction is that EdgeTX is not the ExpressLRS firmware itself.

The radio firmware exposes and manages the model/module side. The ExpressLRS module firmware handles the RF link.

Can I build EdgeTX like an Arduino sketch?

No.

EdgeTX is a target-driven C/C++ firmware project built with CMake and embedded toolchains.

For real firmware builds, you need the documented build environment, target flags such as PCB and PCBREV, and the ARM toolchain.

For native Companion or simulator work, you also need native desktop dependencies such as Qt6.

Is the web simulator a normal static website?

It is static-deployable, but it is not a simple static website.

The web simulator uses WebAssembly threads, SharedArrayBuffer, Atomics, OPFS, and WebGL rendering.

That means the hosting layer must provide cross-origin isolation headers such as COOP and COEP.

The repo includes a _headers file for production hosts that support that pattern.

What should a new FPV user care about first?

Start with the practical safety items:

  • correct radio target and firmware version
  • correct model selected before powering the aircraft
  • correct channel order
  • arming switch and throttle cut
  • failsafe expectations
  • telemetry warnings
  • SD card pack matching the firmware version
  • backup of models before updating

The advanced parts, such as Lua scripts, custom widgets, trainer setup, and complex logical switches, can come later.

Final Thoughts

EdgeTX is easy to underestimate because it is not on the aircraft.

But the radio is where intent begins.

If the radio model is wrong, the aircraft can receive the wrong command perfectly.

That makes EdgeTX one of the most important open-source projects in the RC stack.

It connects the pilot, transmitter hardware, RF module, telemetry, scripts, sounds, warnings, models, and mixes into one programmable interface.

After ExpressLRS and Betaflight, EdgeTX completes the picture from the other side of the link.