Yaapu's telemetry script puts ArduPilot data on a FrSky radio screen

A transmitter script, not a ground station

The Yaapu Telemetry project is described as an ArduPilot LUA telemetry script and widget for radios running OpenTX, EdgeTX and Ethos, and the repository description is more specific about the hardware it targets: a LUA telemetry script and widget for the Horus X10(S), X12 and Taranis X9D+, X9E, QX7 and X-Lite radios using the ArduPilot frsky passthru protocol.

That framing is worth holding on to. This is not a ground station application and it does not replace one. It is a script that runs inside the firmware of a transmitter, and it turns the radio's own screen into a second flight display. The radio already has a display, a processor and a way to talk to the aircraft, and the project uses all three.

The consequence is that the receiver side has to be arranged first. The script needs the ArduPilot flight stack to expose its data over the FrSky passthru protocol, which the README supports through FRSKY S.Port, TBS Crossfire and ExpressLRS, with setup information linked for each, and through the MavToPT project, which converts MAVLink to passthru.

That is the difference between a project that is a Lua file you copy onto a radio and a project that is a system you have to wire up on both ends. The first part is easy. The second part is where the time goes, and the wiki is the place the README sends you for it.

ArduPilot only, and the README says so plainly

There is a note in the README that is worth reading before anything else. It requires Ardupilot, that is, it does not work with INAV, betaflight or any other flight stack different from Ardupilot.

For a hobby that is a real constraint but an understandable one. The passthru protocol exposes ArduPilot's own data structures, and the script's interpretation of them, the field names, the units, the way the values are packed into the telemetry stream, is ArduPilot specific. A different flight stack would need a different mapping, and the project does not attempt it.

The same reasoning applies to the link protocols. S.Port is the original FrSky serial protocol, Crossfire is TBS's system, and ExpressLRS is a common open link protocol in the FPV world. The script works over whichever of those the radio and the aircraft already use, which is why the setup links matter: you are not choosing the script's transport, you are making your existing transport carry passthru data.

The MavToPT option, the MavlinkToPassthru project, covers the case where the aircraft side speaks MAVLink and something has to translate it into the passthru frame format the radio understands. That is the bridge for setups that were never FrSky native.

For an evaluator, the checklist is therefore: ArduPilot on the aircraft, a supported link between radio and aircraft, and a radio whose firmware the project supports.

Which archive to download depends on your radio firmware

The support list is not a single download, and picking the wrong one is the most common way to waste an evening.

For OpenTX 2.3.8 or later, the README points to the etx-otx-lua52 tag. For EdgeTX up to version 2.10, it points to the same etx-otx-lua52 tag. For EdgeTX version 2.11 or later, it points to the latest master archive. And for Ethos 1.4 or later, the widget is downloaded from the ETHOS directory in the master branch.

The reason for the split is the Lua version. The tag name says it: etx-otx-lua52 is the archive for radios running Lua 5.2, and EdgeTX 2.11 changed the Lua runtime, so the script had to be regenerated for the newer interpreter. The master branch carries the version that works on the newer firmwares, and the older tag is kept for anyone still on 2.10 or on OpenTX.

The other detail is the difference between a script and a widget. The Lua telemetry script is the part that runs on the radio and displays the data, and the widget is the additional component used on the colour LCD models. The Ethos entry points at a dedicated directory for the widget because the Ethos firmware expects it there.

The README also says the latest versions are downloadable from the clone or download button of the master branch, which is the simplest route if you are on a recent firmware and you want the current code rather than a tagged archive.

One project, several very different screens

The screenshots in the README are the clearest evidence of what this project actually is, because they span a range of displays that differ by more than a factor of twenty in pixels.

There are EdgeTX colour LCD panels at 800x480, 480x272, 320x480 and 320x240, the black and white OpenTX and EdgeTX panels at 212x64 and 128x64, and Ethos colour panels at 480x272, 480x320 and 800x480, the last two being the X18 and X20.

That range is the real engineering constraint. A telemetry layout that works on an 800x480 panel and a 212x64 monochrome screen cannot be the same layout, and the script has to detect which display it is running on and draw something appropriate. On the small monochrome screens the original OpenTX telemetry display conventions are still the idiom, and a flight mode, a timer and a couple of numbers have to fit in a strip of text.

The repository layout reflects the same split. There is an OTX_ETX directory for the OpenTX and EdgeTX script and widget, a separate ETHOS directory for the Ethos versions, and a TOOLS directory. Alongside them are three changelog files, ethos-changelog.txt, opentx-edgetx-bw-lcd-changelog.txt and opentx-edgetx-color-lcd-changelog.txt, which is a good sign about how the project is run, because the black and white display users, the colour LCD users and the Ethos users are effectively three different audiences with different feature sets and different upgrade cadence.

Where this telemetry script is the wrong tool

Three cases, and the first is about flight stacks rather than radios.

If you fly INAV, Betaflight or any other stack, this project does not work for you, and the README says so without hedging. The passthru data it consumes is ArduPilot's, and there is no compatibility layer for others. A pilot with a modern multirotor stack will usually find the radio firmware's own telemetry or a dedicated ground station a better fit, because those do not require the aircraft to speak ArduPilot.

The second is the firmware split. The script supports a wide range of radios, but not with one file. OpenTX 2.3.8 and EdgeTX up to 2.10 need the older tagged archive, EdgeTX 2.11 and later need the master branch, and Ethos 1.4 and later need the widget from the ETHOS directory. That is three distributions to keep track of, and a pilot who reads the wiki for a different radio than the one in front of them can end up with a script that does not start.

The third is scope. This is a telemetry display, not a ground station, not a flight planner and not a link configuration tool. If what you want is to plan a mission, set waypoints, or log a full flight with a proper trail, you want software that talks to the aircraft over MAVLink, and a transmitter script that reads a byte stream is not going to become one.

A fourth point is worth naming even though it is not a limitation of the code. The script's value depends on your radio and aircraft being set up for passthru, and that setup is the part the wiki exists to explain.

Licence, releases and how to evaluate it

The licence is GPL-3.0, with the LICENSE file at the repository root. For a script you copy onto your own transmitter, GPL-3.0 is unremarkable in practice, and it also covers the widget and the tools directory.

The release picture is a little unusual, because what is tagged is not a released package but a set of ready-made archives. The recent tags are etx-otx-lua52, described as OpenTX and EdgeTX running Lua 5.2, from 2025-07-03, etx-otx-ethos-latest for all radios at their latest versions from 2025-03-27, and OTX-ETX_Color-LCD_ver_2.0.0_beta3, a colour LCD radio version, from 2023-03-07.

So the versioning is per radio generation rather than per feature release, and the tags exist so that someone can download the archive that matches their setup. The last push was on 2026-06-25 and the repository is not archived.

Two things are worth checking before you commit an afternoon to it. The first is the wiki, because the README's own instruction is to please read the wiki for more info, and the wiki is where the passthru setup for S.Port, Crossfire and ExpressLRS is documented. The second is the changelog for your display type, since the three changelog files mean the black and white, colour LCD and Ethos variants move at different times.

The project says it is free and will always be, and asks for donations rather than charging, which is a reasonable arrangement for something the community depends on for every flight.

Editorial conclusion

FrskyTelemetryScript suits a pilot who flies ArduPilot on a FrSky radio and wants attitude, GPS and flight data on the transmitter itself instead of on a phone or a ground station screen, and the range of radio firmwares and link protocols it covers is unusually broad. It is the wrong tool if you fly INAV or Betaflight, if your radio runs EdgeTX 2.10 or older and you have no way to install from a tagged archive, or if you need a full ground station rather than a transmitter display. Verify first which archive matches your radio, since the README splits EdgeTX 2.10 and earlier from 2.11 and later, and check that the link protocol you fly is one the passthru setup supports, because that is where the setup work actually is.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. yaapu/FrskyTelemetryScript on GitHub