Lua on Jeti transmitters

Some time ago there was surfacing rumors that Jeti would implement Lua-scripting to transmitters. I immediately thought that this is something really cool and useful since Jeti transmitters are already a little bit of “geek’s wet dream” what comes to free programming and creativity to do things. (No, Jeti TX is NOT hard to use, you can make it hard to use if you want to, and I do…)

What is Lua?

Lua (“Loo-ah”, Portuguese for “Moon”) is a scripting language, short and simple. I think the description from Lua-projects homepage says it absolutely great: “Lua combines simple procedural syntax with powerful data description constructs based on associative arrays and extensible semantics. Lua is dynamically typed, runs by interpreting bytecode for a register-based virtual machine, and has automatic memory management with incremental garbage collection, making it ideal for configuration, scripting, and rapid prototyping.

What transmitters will be using Lua?

Lua is available on all DC/DS-14/16/24 transmitters. (14/16 from firmware 4.22). Difference between 14/16 and 24 is the amount of apps at the same time (2 vs 10) and a very hard memory limitation on 14/16. Running any Lua-apps on 14/16 that uses more than 50KB of memory causes Lua to be stopped entirely. So in practice code needs to be optimized and one big step is to run compiled versions (.lc) instead of .lua scripts.

How do you use it?

Basic setup is easy. You write an application (script) and put that to SD-card. After that the application is run in your selected model. This means you can have different scripts running on different models.

You can for example have constantly updating telemetry-data, make and use graphics and images, use telemetry and voice in a new fashion, you can access SD-card with Lua and so on. One thing I really like that like there is now MX1 – MX16 there will be Lua-controls. If nothing else this opens a whole new world to making transmitter and it’s functions really “your own”!

How does Lua-script look like?

It’s fairly simple. Since Jeti’s documentation to Lua is still on works we do of course not know what are the things we can control and so on. But this should give you a a hint:

For example a screen with fading text:

local slide1={
  listItem("» 24 proportional channels",0,10000),
  listItem("» Dual band 2.4GHz & 900MHz",1000,10000),
  listItem("» Haptic feedback",2000,10000),
  listItem("» Voice commands",3000,10000),
  listItem("» MP3 playback",4000,10000),
  listItem("» Model & background images",5000,10000),
  listItem("» FM Tuner",6000,10000),  

Here’s the functions for getting information about the state of input’s, information where to load image-files and so on.

local function init()
  system.registerTelemetry(1,"Scriptable telemetry",3,printTelemetry);
  system.registerTelemetry(2,"Scriptable map",4,printTelemetryMap);
  p1,p2,p3,p4 = system.getInputs("P1", "P2", "P3", "P4")
  lastTimeMoved = system.getTimeCounter()
  for i=1,100 do
    values[i] = 0
  logolua = lcd.loadImage("Apps/img/logolua.png")
  imgmap = lcd.loadImage("Apps/img/map.jpg")
  imggear = lcd.loadImage("Apps/img/gear.jpg")
  imggraph = lcd.loadImage("Apps/img/graph.jpg")


And since we all know a picture says more than a thousand words then a video should say more than two thousand words. This is a function-demo of Lua-scripted screens (some of code above). The quality is not the point in this case, contents is.

Script-examples and function-demo video from Jetimodel, published with permission.


If there’s ever been a doubt in my mind about getting the DS-24 that doubt is gone. I just GOT to have one…

5 thoughts on “Lua on Jeti transmitters

  1. Hi, I know wexactly nothing about Lua scripts. However, I am a Jeti dealer in the UK and I am interested in how they can help solve a couple of problems.
    The first is to do with sequencers. Currently the sequencers "step" to the next action based on time. I would like an alternative where the "step" to the next action based on a telemetry command. For example on my jets, instead of the gear coming up say 5 seconds after the gear doors have opened, I would like it to come up when interlock switch on the gear doors drive a logic input into the Rx high, thus driving a telemetry control. This means that regardless of the time period, the gear will not travel unless all of the gear doors are actually open.
    the next step would be for the doors to close once more and again this should begin when all the gear legs have engaged microswitches.
    All of this should work in the opposite direction when the gear is selected down. Can this be acheived please?

    1. Interesting for sure!

      In DC/DS-24 I would say it's doable. User would assign a switch for a function "Gear", when model is in the air and user flips the switch we could first activate a Lua-control to operate the gear-doors to open. After doors are fully opened we could read the input value (I think, I need to check this if it's readable from Lua). And only if this input is in correct position we could activate second Lua-control that would raise the gears. After this the doors needs to close, and if wanted only after gears are confirmed for being up with another input.

      The "Lua-control" is a Lua-operated switch we can set from Lua-apps, this switch can be used for example to raise gears and open doors. If you want to keep possibility for physical switch then a logical switch as "Physical Sw OR Lua SW" needs to be used.

      Very interesting idea, there's a few questions I can't verify at the moment (not home at the moment) but this is definitely something I will look at just for the interest.

  2. Hello!
    I'm stuck with a pb with an old mvario (v1 non EX) in use with an old R6 duplex (non EX same age). the pb with my DC16 is i can get the telemetry via the jetibox apps but not the vario sound, so as I can't fly looking at my Tx, it's fairly useless. is there a way to get the vario value an generate a vario sound ? I know it's quite easy and cheap to make a ex compatible vario (waiting for the parts) but it won't work with my old R6( non ex) anyway . I can't find a documentation for the old communication protocole nor a way to get the value of the telemetry

    1. I assume it gives you telemetry-value ”vario”, you can then use transmitter to generate sounds as usual.

Leave a Reply

Your email address will not be published. Required fields are marked *