betaflight-tx-lua-scripts: Betaflight setup from the radio itself

The radio becomes the configurator

betaflight-tx-lua-scripts is a collection of scripts to configure Betaflight from your transmitter, and the description notes the important limitation, that this is currently only supported in OpenTx.

What the scripts do is put a settings interface on the handset itself. The README describes the Betaflight setup script as letting you configure Betaflight through the MSP protocol, which is the same protocol the desktop configurator speaks. The difference is that the radio is already talking to the flight controller over the telemetry link, so the script rides on that link instead of needing a USB connection and a computer.

The project is a Betaflight project rather than a community project, it is published under the GNU General Public License version 3, and the repository carries a build badge for a nightly workflow, a badge pointing at a Codespaces environment, and a link to the releases page where the versioned zip files are.

The release history is best read for its gaps. Version 1.6.0 was published on 2022-06-14, 1.7.0 on 2023-01-30, and 1.8.0 on 2026-01-23, with the last push to the repository on 2026-08-31. So the scripts are being maintained, but the visible release history has a three year gap, and the recent work has not produced a new major line.

The scope is also narrow in a useful way. There are three pieces, the setup script, the CMS screen and a background script, and nothing else in the repository is trying to be a ground station.

The requirement list is the real specification

The requirements section is long, and every line in it is a condition that has to be true before the scripts will work, so it deserves to be read as a specification rather than as a compatibility note.

Betaflight itself is first, with the recommendation to use the most recent stable release to get the best possible results. Then telemetry, which has to be enabled in the Betaflight Receiver tab and has to be supported by the transmitter and the receiver, because that is the only channel the scripts have to talk to the flight controller.

The firmware floors are then listed. OpenTX 2.3.12 or newer, EdgeTX 2.4.0 or newer, ExpressLRS 2.0.1 or newer, and the TBS Crossfire and Tracer radio and receiver at version 2.11 or newer. FrSky transmitters and receivers with SmartPort support mostly work, but the recommendation is to update the receiver firmware to the most recent version to correct known bugs in telemetry.

Two entries are the kind of detail that normally lives in a forum post. The ImmersionRC Ghost RX module needs the latest firmware and the module set to RF mode Race250, because the other RF modes have issues or do not have the telemetry that the Betaflight Lua needs. And the baud rate has to be set to 400K in EdgeTX or OpenTX for Crossfire, Tracer and ExpressLRS.

None of that is negotiable, which is why this list is the first thing to check when the scripts do not appear in the menu.

Install the obj folder, never the repository

The installation section opens with a warning in capitals, and it is best repeated here, because doing it the other way is the classic mistake.

Do not copy the contents of this repository onto your SD card. Instead, download the zip file containing the latest version from the releases page, unzip it, and drag the contents of the obj folder to the radio's SD card.

The reason is in the structure of the radio's filesystem. If you do this correctly, the SCRIPTS directory merges with your existing directories and the scripts land in their appropriate paths, and the way you know it worked is that the bf.lua file shows up in your /SCRIPTS/TOOLS directory.

That last detail is also the difference between the two methods. The repository contains the source of the scripts, the build scripts, the documentation and the screenshots, while the obj folder contains the compiled output that the radio actually executes. Copying the repository gives you a radio full of Lua source it cannot run, and an obj directory that was never built for your radio's firmware.

The first launch also has a step of its own. When the script is started for the first time after a clean install or an upgrade, it goes through its compile procedure and exits back to the tools menu when it is done, so an empty first run is expected rather than a failure.

Two scripts, and the CMS one has a sharp edge

There are two ways into the flight controller from the radio, and they are not interchangeable.

The setup script is the general one, and it is the one that configures Betaflight over MSP. The CMS script is different in kind, and the README puts the restriction in capitals as well: it is for TBS Crossfire and Tracer only. It gives access to the same configuration menu that is available in the on screen display, on the quad itself.

The CMS controls are unusual because the radio's sticks are in use, with pitch to move through the current menu, roll to enter a menu or change the selected parameter, and yaw to go left to go back and right to enter the save and exit menu. Plus and enter give a manual refresh, which you press if the script does not update.

The sharp edge is the exit key, and the warning is emphatic. Pressing exit once closes the CMS menu and exits the script. A long press will exit the script without closing the CMS menu, and as a result you will not be able to arm. The consequence of a long press is therefore a quad that will not arm until the script is run again, and the README explains it clearly enough that it is best read before you fly with it.

There is also an optional background script, which offers real time clock synchronisation and RSSI through MSP. The RSSI value is only sent if no other RSSI source is detected, which is the behaviour you want when the radio already reports link quality and the flight controller does not need a second opinion.

The colour radio interface was rebuilt on EdgeTX widgets

The most recent visible change to the project is an interface rewrite for colour radios, and it is a good example of a script adapting to its host.

On a colour radio running EdgeTX 2.11.7 or 2.12.1 or newer, the script uses the radio's own LVGL widgets, dropdowns, toggles and number editors, in a standard EdgeTX page, with the page navigation in the header. The readme is emphatic that everything else is the same script, the same settings, the same pages and the same protocol, and that colour radios on other firmware versions and every monochrome radio keep the layout they have always had.

The controls therefore differ by radio. On the older layout, plus, minus and the rotary encoder move the selection, the page key moves to the next page and a long press to the previous one, enter accesses the selected element and a long press opens the function menu, and exit goes back or exits. On the new EdgeTX pages, the rotary encoder moves between controls and enter edits one and again accepts it, the page key moves in both directions with the header arrows doing the same, and there is no function menu at all. Instead, Save page is the last row of every settings page, and the actions that concern the flight controller rather than the page, reboot, accelerometer calibration, and the VTX table and board information downloads, are listed on the main menu under Flight Controller.

That last restructuring is the interesting part. Removing the function menu removes a level of nesting, and it puts the destructive actions somewhere a user cannot reach by accident while adjusting a parameter.

Saving is manual, and the VTX table has its own rules

Two behaviours catch people out, and both are documented.

The first is that changes do not take effect until a save is manually initiated. You change the parameters you want, then send them back to the flight controller, by selecting Save page on a colour radio with the new EdgeTX versions, or by long pressing enter to open the function menu and choosing save page on a monochrome radio or an older colour one. Leaving a page without saving discards the changes on it, which is the safe default and also the surprising one.

The second is the VTX table, which is a special case because the video transmitter settings are not simple parameters. If your VTX supports the SmartAudio or Tramp protocols, then bands and channels are managed using VTX tables, and this has been the case since Betaflight version 4.1.0. The script downloads and stores the current VTX table for every model the first time that model is connected, and if you change the table you have to reload it, through Download VTX Tables under Flight Controller on the main menu on the new colour radios, or the vtx tables option in the function menu elsewhere. Depending on the size of the tables and the telemetry protocol in use, the download can take a while.

There is one escape clause. If the VTX feature was not included in your Betaflight firmware build, the download is skipped and the VTX menu item is not available, and the initial setup of the VTX and the tables has to be done with the desktop Configurator instead.

The build is a shell script and a zip

The build system is minimal, which suits a project whose output is a directory of Lua files.

The Makefile has three targets. The default target runs the files target, which calls bin/build.sh. The clean target removes the contents of the obj directory, and the release target depends on both clean and files, then creates a release directory, derives a file name from the most recent git tag with git describe, and zips the obj directory into it. The repository layout matches: a src directory with the sources, a bin directory with the build script, a docs directory with the documentation and the images, and a screenshots directory.

The obj directory is the artefact, and the installation instructions in the README treat it as the only thing you copy to the radio, which is the design decision that keeps the repository layout and the radio layout separate.

The supporting files are the usual ones for a project of this kind, a licence file, a code of conduct, a contributing guide, a Travis configuration from the earlier days and a devcontainer directory for working on the scripts in a container.

The scripts themselves are Lua, and the project name carries the constraint that defines it, TX, for the transmitter, because the same MSP configuration surface is also reachable from other tools and the point of these scripts is that you do not need any of them.

Editorial conclusion

betaflight-tx-lua-scripts fits a pilot who wants to adjust their flight controller settings without unplugging the quad and without a laptop, because the script drives the same MSP protocol the configurator uses, from a handset that is already in the pilot's hands. It is the wrong choice if your radio is a monochrome unit and you want the newer EdgeTX widget layout, since that interface exists only on EdgeTX 2.11.7 and 2.12.1 or newer, and it is the wrong choice if you fly on ExpressLRS or Ghost without setting the baud rate and the radio mode correctly, because telemetry is the only channel these scripts have. Before you install anything, work through the requirement list, because the firmware versions, the telemetry switch and the receiver settings are what decide whether the scripts can talk to the flight controller at all.

Frequently asked questions

Official sources

1. betaflight/betaflight-tx-lua-scripts on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases