Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
This section includes Acknowledgments and Getting Started.
The latest version of this guide will always be available here. At the top of the left sidebar there is a version option if you are running an older version of EdgeTX or OpenTX and need the docs for that specific version.
Please feel free to make suggestions or corrections to the documentation on GitHub, but the prefered method of editing is to use GitBook, so all changes will need to be made by someone who is authorized as a writer there.
This guide covers the development of user-written scripts for R/C transmitters running the EdgeTX 2.5 operating system with Lua support. Readers should be familiar with EdgeTX/OpenTX, the OpenTX Companion, and know how to transfer files the SD card in the transmitter.
If you are new to Lua programming, you may also find the Lua Reference Manual of assistance
Part I is an overview of the different script types, along with basic examples of each.
Part II is a programming guide that introduces the types of EdgeTX Lua scripts and how to use them.
Part III is the EdgeTX Lua API Reference
Part IV covers advanced topics with examples
The EdgeTX team has no intention of making a profit from their work. EdgeTX is free and open source and will remain free and open source. But EdgeTX is more expensive to maintain than most open source projects. The reason is that there is a never ending flood of hardware to integrate and maintain code for. Hardware that costs.
TODO: Need to determine status of wizard in 2.2
EdgeTX Companion 2.5 is available for download here (pick the version for your operating system from Assets heading at the bottom of the page).
If you intend to use mixer scripts, when updating the firmware on your transmitter you need to make sure the lua option is checked in the settings for your radio profile (Main menu -> Settings ->Settings...) as shown below. This is not required if you only intend to run telemetry, one-time and function scripts, support for those is included by default.
Also note that the SD Structure path should contain a valid path to a copy of your transmitter's SD card contents, although that's not specific to Lua.
This functions allows for sending SPORT / ACCESS telemetry data toward the receiver, and more generally, to anything connected SPORT bus on the receiver or transmitter.
When called without parameters, it will only return the status of the output buffer without sending anything.
@status current Introduced in 2.3
This section describes various constants that are provided for Lua by EdgeTX.
module module index (0 = internal, 1 = external)rxUid receiver index
sensorId physical sensor ID
frameId frame ID
dataId data ID
value value
boolean data queued in output buffer or not.
number channel assigned to this stick (from 0 to 3)
nil stick not found
message (string) text to display
event (number) the event variable that is passed in from the Run function (key pressed)
"CANCEL" user pushed EXIT key
Use only from stand-alone and telemetry scripts.
buffer value (number)
none
rssi RSSI value (0 if no link)
alarm_low Configured low RSSI alarm level
alarm_crit Configured critical RSSI alarm level
line (unsigned number) mix number (use 0 for first line(mix))
none
number Number of seconds elapsed since 1. Jan 1970
hourFormat (number):
0 or not present play format: minutes and seconds.
!= 0 play format: hours, minutes and seconds.
none
pause (number) length of the silence after haptic feedback in milliseconds
flags (number):
0 or not present play with normal priority
PLAY_NOW play immediately
none
multiple returns 2 values:
(number) (current) flight mode number (0 - 8)
(string) (current) flight mode name
Name
Description
LCD_W
width in pixels
LCD_H
height in pixels
Return the RAS value or nil if no valid hardware found
@status current Introduced in 2.2.0
none
number representing RAS value. Value bellow 0x33 (51 decimal) are all ok, value above 0x33 indicate a hardware antenna issue.
This is just a hardware pass/fail measure and does not represent the quality of the radio link
RAS was called SWR in the past
This section describes the Lua libraries, functions and constants that are provided by EdgeTX.
This functions allows for sending telemetry data toward the TBS Crossfire link.
When called without parameters, it will only return the status of the output buffer without sending anything.
@status current Introduced in 2.2.0, retval nil added in 2.3.4
command command
data table of data bytes
boolean data queued in output buffer or not.
nil incorrect telemetry protocol.
Return the time since the radio was started in multiple of 10ms
The timer internally uses a 32-bit counter which is enough for 497 days so overflows will not happen.
@status current Introduced in 2.0.0
none
number Number of 10ms ticks since the radio was started Example:
run time: 12.54 seconds, return value: 1254
Insert a mixer line into Channel
@status current Introduced in 2.0.0, parameters below multiplex added in 2.0.13
channel (unsigned number) channel number (use 0 for CH1)
line (unsigned number) mix number (use 0 for first line(mix))
value (table) see model.getMix() for table format
none
Insert an Input at specified line
@status current Introduced in 2.0.0, curveType/curveValue/carryTrim added in 2.3, inputName added 2.3.10
input (unsigned number) input number (use 0 for Input1)
line (unsigned number) input line (use 0 for first line)
value (table) input data, see model.getInput()
none
Play a file from the SD card
@status current Introduced in 2.0.0, changed in 2.1.0
path (string) full path to wav file (i.e. “/SOUNDS/en/system/tada.wav”)
Introduced in 2.1.0: If you use a relative path, the current language is appended
to the path (example: for English language: /SOUNDS/en is appended)
none
Set Custom Function parameters
@status current Introduced in 2.0.0, TODO rename function
function (unsigned number) custom function number (use 0 for CF1)
value (table) custom function parameters, see model.getCustomFunction() for table format
none
If a parameter is missing from the value, then that parameter remains unchanged.
This section provides more specifics on the EdgeTX Lua implementation. Here you will find syntax rules for interface tables and functions.
This section introduces the types of Lua scripts supported by EdgeTX and how they may be used.
number in list: ROTENC_LOWSPEED, ROTENC_MIDSPEED, ROTENC_HIGHSPEED
return 0 on radio without rotary encoderLua makes it easy to load and unload code modules on the fly, to save memory or to provide program extensions.
The loadScript(<file>) function will load a script from a the file and return a function that is the body of the script, as described in the previous section. So you could have the following Lua script file saved on the SD card:
-- /SCRIPTS/TestScript.lua
local c = ...
local function f(x)
return x + c
end
return fYou can load and use the above file with the following code:
local chunk = loadScript("/SCRIPTS/TestScript.lua")
local f1 = chunk(1)
local y = f1(5)
-- y = 5 + 1
local f2 = chunk(3)
local z = f2(5)
-- z = 5 + 3So here we put together what we learned in the previous section. The body of the script is an anonymous function returned by loadScript and stored in the variable chunk. It returns the function f when it is called. The local variable c in the script is assigned to the first vararg passed to the call. Since a new closure is created every time we call chunk, f1 and f2 have different closures with different values of c.
Return current global variable value
Example:
-- get GV3 (index = 2) from Flight mode 0 (FM0)
val = model.getGlobalVariable(2, 0)index zero based global variable index, use 0 for GV1, 8 for GV9
flight_mode Flight mode number (0 = FM0, 8 = FM8)
nil requested global variable does not exist
number current value of global variable
a simple warning or notice
none
if set to 'session', radio session timer is reset too
if set to 'ttimer', radio throttle timer is reset too
if set to 'tptimer', radio throttle percent timer is reset tooFunction scripts are invoked via the 'Lua Script' option of Special Functions configuration page.
Typical uses of Function scripts are:
specialized handling in response to switch position changes
customized announcements
Please be aware that:
all function scripts are stopped if a One-Time Lua script is running
Function scripts DO NOT HAVE ACCESS TO LCD DISPLAY
init function is called once when the model is selected
depending on the switch associated with the Special Function, either the run function (switch = on) or the background function (switch = off) is called periodically
the script is stopped and disabled if it misbehaves (e.g. run-time error or low memory)
Scripts are located on the SD card in the folder /SCRIPTS/FUNCTIONS/<name>.lua. File name length (without extension) must be 6 characters or less (this limit was 8 characters in OpenTX 2.1).
Every script must include a return statement at the end, defining its interface to EdgeTX. This statement returns a table with the following fields:
init function (optional)
run function
background function (optional)
Lua Standard Libraries
Included
package
-
coroutine
-
table
-
since OpenTX 2.1.0 (with limitations)
os
Returns (some of) the general radio settings
@status current Introduced in 2.0.6, imperial added in TODO, language and voice added in 2.2.0, gtimer added in 2.2.2.
none
table with elements:
battWarn (number) radio battery range - warning value
battMin (number) radio battery range - minimum value
Play a tone
@status current Introduced in 2.1.0
frequency (number) tone frequency in Hz (from 150 to 15000)
duration (number) length of the tone in milliseconds
pause (number) length of the silence after the tone in milliseconds
flags (number):
0 or not present play with normal priority.
PLAY_BACKGROUND play in background (built in vario function uses this context)
freqIncr (number) positive number increases the tone pitch (frequency with time), negative number decreases it. The frequency changes every 10 milliseconds, the change is freqIncr * 10Hz. The valid range is from -127 to 127.
none
Play a numerical value (text to speech)
@status current Introduced in 2.0.0
value (number) number to play. Value is interpreted as integer.
unit (number) unit identifier [Full list]((../appendix/units.html))
attributes (unsigned number) possible values:
0 or not present plays integral part of the number (for a number 123 it plays 123)
PREC1 plays a number with one decimal place (for a number 123 it plays 12.3)
none
Pops a received SPORT packet from the queue. Please note that only packets using a data ID within 0x5000 to 0x50FF (frame ID == 0x10), as well as packets with a frame ID equal 0x32 (regardless of the data ID) will be passed to the LUA telemetry receive queue.
@status current Introduced in 2.2.0
none
nil queue does not contain any (or enough) bytes to form a whole packet
multiple returns 4 values:
sensor ID (number)
Telemetry scripts are used for building customized screens. Each model can have up to three active scripts as configured on the model's telemetry configuration page. The same script can be assigned to multiple models.
Please note: Telemetry scripts are only available on radios with telemetry screens, such as e.g. FrSky Taranis models (including Xlite), Radiomaster TX12 and and Jumper T12.
WARNING - Running a One-Time script will suspend execution of all other currently loaded Lua scripts (Custom, Telemetry, and Functions)
One-Time scripts start when called upon by a specific radio function or when the user selects them from a contextual menu. They do their task and are then terminated and unloaded. Please note that all persistent scripts are halted during the execution of One-Time scripts. They are automatically restarted once the One-Time script is finished. This is done to provide enough system resources to execute the one time script.
@param num (optional): maximum number of bytes to read. If non-zero, serialRead will read up to num characters from the buffer. If 0 or left out, serialRead will read up to and including the first newline character or the end of the buffer. Note that the returned string may not end in a newline if this character is not present in the buffer.
Reads characters from the serial port. The string is allowed to contain any character, including 0.
@status current Introduced in 2.3.8
none
This functions allows for sending SPORT telemetry data toward the receiver, and more generally, to anything connected SPORT bus on the receiver or transmitter.
When called without parameters, it will only return the status of the output buffer without sending anything.
@status current Introduced in 2.2.0, retval nil added in 2.3.4
day (number) day of month
hour (number) hours
hour12 (number) hours in US format
min (number) minutes
sec (number) seconds
suffix (text) am or pm
battMax (number) radio battery range - maximum value
imperial (number) set to a value different from 0 if the radio is set to the
IMPERIAL units
language (string) radio language (used for menus)
voice (string) voice language (used for speech)
gtimer (number) radio global timer in seconds (does not include current session)
'numsat' (number) current number of sats locked in by the GPS sensor
'fix' (boolean) fix status
'alt' (number) internal GPS altitude in 0.1m
'speed' (number) internal GPSspeed in 0.1m/s
'heading' (number) internal GPS ground course estimation in degrees * 10
'hdop' (number) internal GPS horizontal dilution of precision
PLAY_NOW play immediately
packet (table) data bytes
PREC2 plays a number with two decimal places (for a number 123 it plays 1.23)
frame ID (number)
data ID (number)
value (number)
ttimer (number) radio throttle timer in seconds
tptimer (number) radio throttle percent timer in seconds
event (number) the event variable that is passed in from the Run function (key pressed)
"CANCEL" user pushed EXIT key
Use only from stand-alone and telemetry scripts.
line (unsigned number) input line (use 0 for first line)
none
none
nil requested sensor does not exist
table with sensor data:
type (number) 0 = custom, 1 = calculated
name (string) Name
unit (number) See list of units in the appendix of the OpenTX Lua Reference Guide
prec (number) Number of decimals
id (number) Only custom sensors
instance (number) Only custom sensors
formula (number) Only calculated sensors. 0 = Add etc. see list of formula choices in Companion popup
str string. Empty if no new characters were available.
event (number) the event variable that is passed in from the Run function (key pressed)
input (number) value that can be adjusted by the +/- keys
min (number) min value that input can reach (by pressing the - key)
max (number) max value that input can reach
number result of the input adjustment
"OK" user pushed ENT key
"CANCEL" user pushed EXIT key
Use only from stand-alone and telemetry scripts.
nil requested custom function does not exist
table custom function data:
switch (number) switch index
func (number) function index
name (string) Name of track to play (only returned only returned if action is play track, sound or script)
value (number) value (only returned only returned if action is not play track, sound or script)
mode (number) mode (only returned only returned if action is not play track, sound or script)
param (number) parameter (only returned only returned if action is not play track, sound or script)
active (number) 0 = disabled, 1 = enabled
subID subID of the sensor, usually 0, valid range is from 0 to 7
instance instance of the sensor (SensorID), valid range is from 0 to 0xFF
value fed to the sensor
unit unit of the sensor Full list
precision the precision of the sensor
0 or not present no decimal precision.
!= 0 value is divided by 10^precision, e.g. value=1000, prec=2 => 10.00.
name (string) Name of the sensor if it does not yet exist (4 chars).
not present Name defaults to the Id.
present Sensor takes name of the argument. Argument must have name surrounded by quotes: e.g., "Name"
true, if the sensor was just added. In this case the value is ignored (subsequent call will set the value)
All three parameters id, subID and instance can't be zero at the same time. At least one of them must be different from zero.
number number of mixes for requested channel
number number of configured lines for given input
number Stick assigned to this channel (from 0 to 3)
nil requested logical switch does not exist
table logical switch data:
func (number) function index
v1 (number) V1 value (index)
v2 (number) V2 value (index or value)
v3 (number) V3 value (index or value)
and (number) AND switch index
delay (number) delay (time in 1/10 s)
duration (number) duration (time in 1/10 s)
sensorId physical sensor IDframeId frame ID
dataId data ID
value value
boolean data queued in output buffer or not.
nil incorrect telemetry protocol.
table model information:
name (string) model name
bitmap (string) bitmap name (not present on X7)
nil requested input or line does not exist
table input data:
name (string) input line name
switch (number) input switch index
fadeIn (number) fade in value (in 0.1s)
fadeOut (number) fade out value (in 0.1s)
trimsValues (table) table of trim values:
key is trim number (zero based)
value is trim value
trimsModes (table) table of trim mode:
key is trim number (zero based)
value is trim mode
line (unsigned number) input line (use 0 for first line)
nil requested input or line does not exist
table input data:
name (string) input line name
inputName (string) input input name
source (number) input source index
weight (number) input weight
offset (number) input offset
switch (number) input switch index
curveType (number) curve type (function, expo, custom curve)
curveValue (number) curve index
carryTrim (boolean) input trims applied
'flightModes' (number) bit-mask of active flight modes
-
string
since OpenTX 2.1.7
bit32
since OpenTX 2.1.0
math
since OpenTX 2.0.0
debug
-
none
curve (unsigned number) curve number (use 0 for Curve1)
params see model.getCurve return format for table format. setCurve uses standard lua array indexing and arrays start at index 1
`` 0 - Everything okay
1 - Wrong number of points
2 - Invalid Curve number
3 - Cuve does not fit anymore
4 - point of out of index
5 - x value not monotonically increasing
6 - y value not in range [-100;100]
7 - extra values for y are set
8 - extra values for x are set params = {}
params["x"] = {-100, -34, 77, 100}
params["y"] = {-70, 20, -89, -100}
params["smooth"] = true
params["type"] = 1
val = model.setCurve(2, params)Telemetry scripts are loaded when the model is selected.
init function is called one time when the script is loaded
background function is periodically; both when the telemetry screen is visible and when it is not.
run function is called periodically only when the telemetry screen is visible
script is stopped and disabled if it misbehaves (e.g. run-time error or low memory)
all telemetry scripts are stopped if a one-time script is running (see One-time scripts)
Scripts are located on the SD card in the folder /SCRIPTS/TELEMETRY/<name>.lua. File name length (without extension) must be 6 characters or less (this limit was 8 characters in OpenTX 2.1).
Every script must include a return statement at the end, defining its interface to EdgeTX. This statement returns a table with the following fields:
init function (optional)
background function (optional)
run function
The event parameter indicates which transmitter key has been pressed (see Key Events).
Script is executed when user selects Execute on a script file from SD card browser screen.
Script executes until:
it returns value different from 0
is forcefully closed by user by long press of EXIT key
is forcefully closed by system if if it misbehaves (e.g. run-time error or low
memory)
Place them anywhere on SD card, the folder /SCRIPTS/ is recommended. The only exception is official model wizard script, that should be put into /SCRIPTS/WIZARD/ folder that way it will start automatically when new model is created.
Every script must include a return statement at the end, defining its interface to EdgeTX. This statement returns a table with the following fields:
init function (optional)
run function
The event parameter indicates which transmitter key has been pressed (see Key Events).
A non-zero return value from run will halt the script.
local function init()
-- Called once when the script is loaded
end
local function run()
-- Called periodically while the Special Function switch is on
end
local function background()
-- Called periodically while the Special Function switch is off
end
return { run=run, background=background, init=init } val = model.setCurve(3, {smooth=true, y={-100, -50, 0, 50, 100, 80}})local function init()
-- init is called once when model is loaded
end
local function background()
-- background is called periodically
end
local function run(event)
-- run is called periodically only when screen is visible
end
return { run = run, background = background, init = init }local function init()
-- init is called once when model is loaded
end
local function run(event)
-- run is called periodically only when screen is visible
-- A non-zero return value will halt the script
return x
end
return { run=run, init=init }Return detailed information about field (source)
The list of valid sources is available:
OpenTX Version
Radio
2.0
2.1
,
2.2
, ,
@status current Introduced in 2.0.8, 'unit' field added in 2.2.0
name (string) name of the field
table information about requested field, table elements:
id (number) field identifier
name (string) field name
Return OpenTX version
@status current Introduced in 2.0.0, expanded in 2.1.7, radio type strings changed in 2.2.0, os name added in EdgeTX 2.4.0
This example also runs in OpenTX versions where the function returned only one value:
local function run(event)
local ver, radio, maj, minor, rev, osname = getVersion()
print("version: "..ver)
if radio then print ("radio: "..radio) end
if maj then print ("maj: "..maj) end
if minor then print ("minor: "..minor) end
if rev then print ("rev: "..rev) end
if osname then print ("osname: "..osname) end
return 1
end
return { run=run }Output of the above script in simulator:
none
string OpenTX version (ie "2.1.5")
multiple values (available since 2.1.7):
(string) OpenTX version (ie "2.1.5")
Get Curve parameters
Note that functions returns the tables starting with index 0 contrary to LUA's usual index starting with 1
@status current Introduced in 2.0.12
curve (unsigned number) curve number (use 0 for Curve1)
nil requested curve does not exist
table curve data:
name (string) name
Get RF module parameters
Type values:
0 NONE
1 PPM
2 XJT_PXX1
3 ISRM_PXX2
4 DSM2
5 CROSSFIRE
6 MULTIMODULE
7 R9M_PXX1
8 R9M_PXX2
9 R9M_LITE_PXX1
10 R9M_LITE_PXX2
11 R9M_LITE_PRO_PXX1
12 R9M_LITE_PRO_PXX2
13 SBUS
14 XJT_LITE_PXX2
subType values for XJT_PXX1:
-1 OFF
0 D16
1 D8
2 LR12
@status current Introduced in 2.2.0
index (number) module index (0 for internal, 1 for external)
nil requested module does not exist
table module parameters:
subType (number) protocol index
Load a Lua script file. This is similar to Lua's own loadfile() API method, but it uses OpenTx's optional pre-compilation feature to save memory and time during load.
Return values are same as from Lua API loadfile() method: If the script was loaded w/out errors then the loaded script (or "chunk") is returned as a function. Otherwise, returns nil plus the error message.
@status current Introduced in 2.2.0
file (string) Full path and file name of script. The file extension is optional and ignored (see mode param to control which extension will be used). However, if an extension is specified, it should be ".lua" (or ".luac"), otherwise it is treated as part of the file name and the .lua/.luac will be appended to that.
mode (string) (optional) Controls whether to force loading the text (.lua) or pre-compiled binary (.luac) version of the script. By default OTx will load the newest version and compile a new binary if necessary (overwriting any existing .luac version of the same script, and stripping some debug info like line numbers). You can use mode to control the loading behavior more specifically. Possible values are:
function The loaded script, or nil if there was an error (e.g. file not found or syntax error).
string Error message(s), if any. Blank if no error occurred.
Note that you will get an error if you specify mode as "b" or "t" and that specific version of the file does not exist (eg. no .luac file when "b" is used). Also note that mode is NOT passed on to Lua's loader function, so unlike with loadfile() the actual file content is not checked (as if no mode or "bt" were passed to loadfile()).
Get configuration for specified Mix
@status current Introduced in 2.0.0, parameters below multiplex added in 2.0.13
channel (unsigned number) channel number (use 0 for CH1)
line (unsigned number) mix number (use 0 for first line(mix))
nil requested channel or line does not exist
table mix data:
name (string) mix line name
This section will give some technical details for radios with a color screen.
An argument with drawing flags can be given to the various functions that draw on the LCD screen. The lower half of the flags (bits 1-16) are the flag attributes shown below, and the upper half of the flags (bits 17-32) are a color value.
Not all of the flags below should be directly manipulated from Lua, but those that are meant to be set directly by Lua, are accessible by the .
Since the flags are bits, you can add them up to combine, as long as you only add each flag one time. If you add the same flag twice, then it will add up to the next bit over, e.g. INVERS + INVERS = VCENTER. If you want to add a flag to a value where it may already be set, then use flags = bit32.bor(flags, INVERS).
RGB_FLAG decides how the color value is encoded into the upper half (bits 17-32).
If RGB_FLAG = 0, then an index into a color table is stored. This color table holds a default color (index 0), the theme colors, and CUSTOM_COLOR. The entries in the color table can be changed with the function
version: 2.4.0
radio: tx16s-simu
maj: 2
minor: 4
rev: 0
osname: EdgeTX fun, err = loadScript("/SCRIPTS/FUNCTIONS/print.lua")
if (fun ~= nil) then
fun("Hello from loadScript()")
else
print(err)
end(string) radio type: x12s, x10, x9e, x9d+, x9d or x7.
If running in simulator the "-simu" is added
(number) major version (ie 2 if version 2.1.5)
(number) minor version (ie 1 if version 2.1.5)
(number) revision number (ie 5 if version 2.1.5)
Since EdgeTX 2.4.0, sixth value added
(string) OS name (i.e. EdgeTX or nil if OpenTX)
type (number) type
smooth (boolean) smooth
points (number) number of points
y (table) table of Y values:
key is point number (zero based)
value is y value
x (table) only included for custom curve type:
key is point number (zero based)
value is x value
modelId (number) receiver number
firstChannel (number) start channel (0 is CH1)
channelsCount (number) number of channels sent to module
Type (number) module type
if the module type is Multi additional information are available
protocol (number) protocol number (Multi only)
subProtocol (number) sub-protocol number (Multi only)
channelsOrder (number) first 4 channels expected order (Multi only)
b only binary.
t only text.
T (default on simulator) prefer text but load binary if that is the only version available.
bt (default on radio) either binary or text, whichever is newer (binary preferred when timestamps are equal).
Add x to avoid automatic compilation of source file to .luac version.
Eg: "tx", "bx", or "btx".
Add c to force compilation of source file to .luac version (even if existing version is newer than source file).
Eg: "tc" or "btc" (forces "t", overrides "x").
Add d to keep extra debug info in the compiled binary.
Eg: "td", "btd", or "tcd" (no effect with just "b" or with "x").
env (integer) See documentation for Lua function loadfile().
min (number) Minimum % * 10
max (number) Maximum % * 10
offset (number) Subtrim * 10
ppmCenter (number) offset from PPM Center. 0 = 1500
symetrical (number) linear Subtrim 0 = Off, 1 = On
revert (number) irection 0 = ---, 1 = INV
curve
(number) Curve number (0 for Curve1)
or nil if no curve set
start (number) start value [seconds], 0 for up timer, 0> down timer
value (number) current value [seconds]
countdownBeep (number) countdown beep (0 = silent, 1 = beeps, 2 = voice)
minuteBeep (boolean) minute beep
persistent (number) persistent timer
name (string) timer name
source (number) source index
weight (number) weight (1024 == 100%) value or GVAR1..9 = 4096..4011, -GVAR1..9 = 4095..4087
offset (number) offset value or GVAR1..9 = 4096..4011, -GVAR1..9 = 4095..4087
switch (number) switch index
multiplex (number) multiplex (0 = ADD, 1 = MULTIPLY, 2 = REPLACE)
curveType (number) curve type (function, expo, custom curve)
curveValue (number) curve index
flightModes (number) bit-mask of active flight modes
carryTrim (boolean) carry trim
mixWarn (number) warning (0 = off, 1 = 1 beep, .. 3 = 3 beeps)
delayUp (number) delay up (time in 1/10 s)
delayDown (number) delay down
speedUp (number) speed up
speedDown (number) speed down
desc (string) field description
'unit' (number) unit identifier Full list
nil the requested field was not found
2.3
X9D and X9D+, X9E, X7, Horus

If RGB_FLAG = 1, then a 16-bit RGB565 color is stored. This is used directly by the system to draw a color on the screen.
You should not change RGB_FLAG explicitly; this is handled automatically by the various functions and Lua constants. But you should be aware of the following.
lcd.setColor must have an indexed color as its first argument, because this will be the index of the color in the table being changed. Giving another color, e.g. ORANGE, as the first argument will result in nothing.
If no color is given to the flags with a drawing function, RGB_FLAGS = 0 and the color index = 0. Therefore, the default color is stored in the color table under this index, and you can change the default color with lcd.setColor(0, color).
lcd.getColor always returns a RGB color. This can be used to "save" an indexed color before you change it.
obviously returns a RGB color.
OpenTX only supports indexed colors in drawing functions, so you must first call lcd.setColor to change e.g. CUSTOM_COLOR, and then call the LCD drawing function with that indexed color. In EdgeTX, you can use either type of color for drawing functions, so you are no longer forced to constantly call lcd.setColor. You can also store any color in local variables, and then use these when drawing, thus effectively creating your own color theme.
In OpenTX, lcd.RGB returns a 16 bit RGB565 value, but in EdgeTX it returns a 32 bit flags value with the 16 bit RGB565 value in the upper half (bits 17-32). Therefore, colors in EdgeTX are not binary compatible with colors in OpenTX. But if you use the functions lcd.RGB, lcd.setColor, and lcd.getColor, then your code should work the same way in EdgeTX as in OpenTX.
Unfortunately, OpenTX has disabled the function lcd.RGB when the screen is not available for drawing, so it can only be called successfully from the refresh function in widgets and from the run function in One-Time scripts. Therefore, some existing widget scripts set up colors with hard coded constants instead of calling lcd.RGB during initialization, and this is not going to work with EdgeTX, because of the different binary format.
A pull request has been submitted to OpenTX, allowing lcd.RGB to work also during widget script initialization, and hopefully, it will be merged into OpenTX 2.3.15. If that happens, then the obvious way to solve the problem is to use lcd.RGB values instead of hard coded color constants. But in the meantime, the following RGB function can be used for setting up colors in a way that works for both EdgeTX and OpenTX.
This functions calls lcd.RGB, and if it gets a nil value (because we are running a widget script under OpenTX, and it is not called from the refresh function) then it creates the 16-bit RGB565 value that OpenTX wants.
WARNING - Do not use Lua Custom scripts for controlling any aspect of your model that could cause a crash if the script stops executing!
Each model can have several custom scripts associated with it, and these scripts are run periodically. They behave similarly to standard OpenTX mixers, but at the same time they provide a much more flexible and powerful tool. Custom scripts take one or more values as inputs, do some processing in Lua code, and output one or more values.
Please note: the firmware must be compiled with the option LUA=YES for Custom scripts to be available.
Please note: the scripts should be as short as possible, to avoid delays. It is also important to keep in mind that other loaded Telemetry and Function scripts can add to the response time, or worse: hang the system!
replacement for complex mixes that are not critical to model function
complex processing of inputs and reaction to their current state and/or their history
filtering of telemetry values
cannot update LCD screen or perform user input.
should not exceed allowed run-time/ number of instructions.
custom scripts are run with less priority than built-in mixes. Their execution period is around 30ms and is not guaranteed!
can be disabled/killed anytime due to logic errors in script, not enough free memory, etc...)
Custom scripts are loaded from SD card when model is selected
init __function is called first
run function is called periodically (about 30 times per second)
If the script output is used as a mixer source , and the script is killed for whatever reason, then the whole mixer line is disabled ! This can be used for example to provide a fallback in case Lua Custom script is killed.
Example where Lua mix script is used to drive ailerons in some clever way, but control falls back to the standard aileron mix if script is killed. Second mixer line replaces the first one when the script is alive:
Place them on SD card in folder /SCRIPTS/MIXES/. File name length (without extension) must be 6 characters or less (this limit was 8 characters in OpenTX 2.1).
Every script must include a return statement at the end, defining its interface to EdgeTX. This statement returns a table with the following fields:
input table (optional)
output table (optional)
init function (optional)
The input table defines what values are available as input(s) to custom scripts. There are two forms of input table entries.
SOURCE inputs provide the current value of a selected OpenTX variable. The source must be selected by the user when the script is configured. Source can be any value that EdgeTX knows about (inputs, channels, telemetry values, switches, custom functions etc.). Note: the typical input range is -1024 thru +1024. Simply divide the input value by 10.24 to convert to a percentage from -100% to +100%.
VALUE inputs provide a constant value that is set by the user when the script is configured.
name - maximum length of 8 characters
min - minimum value of -128
max - maximum value of 127
default - must be within the valid range specified
The output table defines only name(s), as the actual values are returned by the script's run function.
Note: the above names are only visible as source values on the radio screen when the script is running. If the model is edited in Companion, then the values show as LUA1a and LUA1b etc.
Lua is a small but powerful language. This section will explain a few of the most important concepts.
Lua was chosen for OpenTX, and hence also EdgeTX, because it is a small language designed to be highly extensible by libraries written in C and C++, so it can be integrated into other systems like EdgeTX. It is also relatively efficient, both in terms of memory and CPU usage, and hence well suited for the radios.
In addition to the provided libraries, Lua has a very elegant mechanism for loading new Lua code modules during run-time. A lot of the elegance comes from the way that the loading mechanism meshes with another concept supported by Lua: first class functions with closures.
Computer science pioneer Christopher Strachey introduced the concept of functions as first-class objects in his paper F from 1967. What it means is that functions can be treated as other variables: as arguments passed in function calls, as results returned from function calls, and a function identifier can be re-assigned to another chunk of function code, just like a variable ca be assigned to a new value.
In Lua, a function declaration is really "syntactic sugar" for assigning a variable to the chunk of code that is called when the function is invoked, i.e.
local function f(x) return x + 1 end
is the same as
local f = function(x) return x + 1 end
You can even add functions to Lua tables, i.e.
t = { f = f }
will add the above function to the table t, as a field that is also called f. Does that look familiar to the return statement required at the end of a Lua script?
Yes indeed, because a script is really an anonymous function that returns a list of functions to the system. The function declarations assign variables to chunks of function code, these variables are added to the list returned at the end of the script, and the system then calls the functions periodically to run the script. So the script itself is run one time initially, and subsequently the functions returned by the last statement are called periodically.
Another important concept that goes with first-class functions, is closures. This is the environment of the function with the variable names that the function can see. Please consider the following function counter that returns another function:
The function is returned directly without being assigned to a variable name. The closure of the function returned is the body of the function counter, containing both the arguments start and step, and the local variable x. So if c1 = counter(1, 1) then c1() will return 1, 2, 3, ... when called repeatedly, and if c2 = counter(2, 3) then c2() will return 2, 5, 8, ...
Likewise, the local variables that you declare outside the functions of your script can be used by all of the functions in your script, and they persist between function calls, but they are not visible to other scripts.
The are a little trickier, as you can register multiple instances of the same widget script, and all of these instances run within the same Lua closure. Therefore, local variables declared outside any functions in a widget script are shared among all of the instances of that script. But each call to the create(...) function returns a new widget list to the system. And since this list is unique to each instance, you can add private instance variables to it.
Please consider this function:
It takes an argument x and a list ... A vararg list is just like a list of arguments separated by commas, and you can call the function with any number of arguments greater than 1. Inside the function, you can also treat ... like a comma separated list of variables, e.g. in the above function, ... is converted to a table by {...} just like you could construct a table by e.g. {a, b, c}. The table is iterated with the ipairs function to look for an element matching the first argument x. So e.g. the following statement
if event == EVT_VIRTUAL_ENTER or event == EVT_VIRTUAL_EXIT then
can be replaced by
if match(event, EVT_VIRTUAL_ENTER, EVT_VIRTUAL_EXIT) then
You can also use ... directly as a comma separated list of values, e.g. local a, b, c = ... will assign the three variables to the three first arguments following x, or nil if none are given.
The helpful, both if you want to learn more about Lua, and if you want to search for answers to specific questions.
On radios with color display, a color may be added to the flags described above.
There are two types of color constants: one that is an index into a table holding a palette of theme colors, and one that is just a color.
These are the theme colors plus CUSTOM_COLOR, and they can be changed with the function lcd.setColor(color_index, color). Please note: if an indexed color is changed, then it changes everywhere that it is used. For the theme colors, this is not only in other widgets, but everywhere throughout the radio's user interface!
COLOR_THEME_PRIMARY1
COLOR_THEME_PRIMARY2
COLOR_THEME_PRIMARY3
COLOR_THEME_SECONDARY1
COLOR_THEME_SECONDARY2
COLOR_THEME_SECONDARY3
COLOR_THEME_FOCUS
COLOR_THEME_EDIT
COLOR_THEME_ACTIVE
COLOR_THEME_WARNING
COLOR_THEME_DISABLED
CUSTOM_COLOR
These color constants cannot be changed:
BLACK
WHITE
LIGHTWHITE
YELLOW
These should no longer be used, but they are included for backwards compatibility. The old OpenTX API had a large number of indexed theme colors, and these have been mapped to the new theme colors as follows:
ALARM_COLOR -> COLOR_THEME_WARNING
BARGRAPH_BGCOLOR -> COLOR_THEME_SECONDARY3
BARGRAPH1_COLOR -> COLOR_THEME_SECONDARY1
BARGRAPH2_COLOR -> COLOR_THEME_SECONDARY2
In addition to the key events described in the previous section, radios with a color touch screen also provide touch events to the widget scripts.
The following touch events are passed in the event argument to the widget script refresh function (when in full screen mode), just like the key events. The following touch events are provided:
Touch Event Name
Description
EVT_TOUCH_FIRST
When the finger touches down on the screen
EVT_TOUCH_TAP
If the finger leaves the screen after a quick tap
In addition to the above touch events a touchState table is passed to refresh with the following addional data fields:
touchState is nil if event is not a touch event. This can be used to test if we have a touch event or a key event.
Since Lua evaluates a nil value to false and everything else to true:
Returns the value of a source.
The list of fixed sources:
OpenTX Version
Radio
2.0
2.1
,
2.2
, ,
In OpenTX 2.1.x the telemetry sources no longer have a predefined name. To get a telemetry value simply use it's sensor name. For example:
Altitude sensor has a name "Alt"
to get the current altitude use the source "Alt"
to get the minimum altitude use the source "Alt-", to get the maximum use "Alt+"
@status current Introduced in 2.0.0, changed in 2.1.0, Cels+ and Cels- added in 2.1.9
source can be an identifier (number) (which was obtained by the getFieldInfo())
or a name (string) of the source.
value current source value (number). Zero is returned for:
non-existing sources
for all telemetry source when the telemetry stream is not received
Getting a value by its numerical identifier is faster then by its name. While Cels sensor returns current values of all cells in a table, a Cels+ or Cels- will return a single value - the maximum or minimum Cels value.
local function RGB(r, g, b)
local rgb = lcd.RGB(r, g, b)
if not rgb then
rgb = bit32.lshift(bit32.rshift(bit32.band(r, 0xFF), 3), 11)
rgb = rgb + bit32.lshift(bit32.rshift(bit32.band(g, 0xFF), 2), 5)
rgb = rgb + bit32.rshift(bit32.band(b, 0xFF), 3)
end
return rgb
endBLUE
DARKBLUE
GREY
DARKGREY
LIGHTGREY
RED
DARKRED
GREEN
DARKGREEN
LIGHTBROWN
DARKBROWN
BRIGHTGREEN
ORANGE
CURVE_AXIS_COLOR -> COLOR_THEME_SECONDARY2
CURVE_COLOR -> COLOR_THEME_SECONDARY1
CURVE_CURSOR_COLOR -> COLOR_THEME_WARNING
HEADER_BGCOLOR -> COLOR_THEME_FOCUS
HEADER_COLOR -> COLOR_THEME_SECONDARY1
HEADER_CURRENT_BGCOLOR -> COLOR_THEME_FOCUS
HEADER_ICON_BGCOLOR -> COLOR_THEME_SECONDARY1
LINE_COLOR -> COLOR_THEME_PRIMARY3
MAINVIEW_GRAPHICS_COLOR -> COLOR_THEME_SECONDARY1
MAINVIEW_PANES_COLOR -> COLOR_THEME_PRIMARY2
MENU_TITLE_BGCOLOR -> COLOR_THEME_SECONDARY1
MENU_TITLE_COLOR -> COLOR_THEME_PRIMARY2
MENU_TITLE_DISABLE_COLOR -> COLOR_THEME_PRIMARY3
OVERLAY_COLOR -> COLOR_THEME_PRIMARY1
SCROLLBOX_COLOR -> COLOR_THEME_SECONDARY3
TEXT_BGCOLOR -> COLOR_THEME_SECONDARY3
TEXT_COLOR -> COLOR_THEME_SECONDARY1
TEXT_DISABLE_COLOR -> COLOR_THEME_DISABLED
TEXT_INVERTED_BGCOLOR -> COLOR_THEME_FOCUS
TEXT_INVERTED_COLOR -> COLOR_THEME_PRIMARY2
TITLE_BGCOLOR -> COLOR_THEME_SECONDARY1
TRIM_BGCOLOR -> COLOR_THEME_FOCUS
TRIM_SHADOW_COLOR -> COLOR_THEME_PRIMARY1
WARNING_COLOR -> COLOR_THEME_WARNING
if touchState then we have a touch event.
x, y are present for all touch events.
startX, startY, slideX, slideY are only present with EVT_TOUCH_SLIDE.
swipeUp / swipeDown / swipeLeft / swipeRight may be present only withEVT_TOUCH_SLIDE.
tapCount is zero for anything but EVT_TOUCH_TAP.
EVT_TOUCH_BREAK
If the finger leaves the screen without tap or slide
EVT_TOUCH_SLIDE
Repeats while the finger is sliding on the screen
touchState fields
Description
x, y
Current touch point
startX, startY
Point where slide started
slideX, SlideY
Movement since previous SLIDE event (or start of slide)
swipeUp / swipeDown / swipeLeft / swipeRight
The field is present and equal to true if a swipe event occurred in that direction
tapCount
Counts the number of consecutive taps
table GPS position is returned in a table:
lat (number) latitude, positive is North
lon (number) longitude, positive is East
pilot-lat (number) pilot latitude, positive is North
pilot-lon (number) pilot longitude, positive is East
table GPS date/time, see getDateTime()
table Cells are returned in a table (except where no cells were detected in which case the returned value is 0):
table has one item for each detected cell:
key (number) cell number (1 to number of cells)
value (number) current cell voltage
2.3
X9D and X9D+, X9E, X7, Horus

all Custom scripts are stopped while a One-Time script is running (see Lua One-time scripts)
run function
Maximum of 6 inputs per script (was 8 in 2.1)
CH1 [I4]Ail Weight(+100%)
:= LUA4b Weight(+100%)local input =
{
{ "Strength", SOURCE}, -- user selects source (typically slider or knob)
{ "Interval", VALUE, 0, 100, 0 } -- interval value, default = 0.
}
local output = { "Val1", "Val2" }
local function init()
-- Called once when the script is loaded
end
local function run(Strength, Interval) -- Must match input table
local v1, v2
-- Called periodically
return v1, v2 -- Must match output table
end
return { input=input, output=output, run=run, init=init }{ "<name>", SOURCE }{ "<name>", VALUE, <min>, <max>, <default> }{ "<name1>", "<name2>" }local function counter(start, step)
local x = start
return function()
local y = x
x = x + step
return y
end
endlocal function match(x, ...)
for i, y in ipairs({...}) do
if x == y then
return true
end
end
return false
endThis page describes the value that is passed to scripts in the event parameter. It is used in Telemetry and One-Time scripts, as well as widget scripts in full screen mode.
Most of the time, widget scripts show some info in a zone either in the top bar or in one of the user defined main views, and they cannot receive direct input from the user via key events like e.g. Telemetry scripts.
But widgets on the main views can also be shown in full screen mode, where they take over the entire screen area. And here they receive user input via key events, and for radios with touch screen, also touch events. Full screen mode can be entered by selecting the widget, pressing ENTER and selecting Full screen on the widget menu, or by double tapping the widget on radios with a touch screen. Full screen mode can be exited by long pressing the RETURN button, or by calling the Lua function lcd.exitFullScreen()
normal font, default precision for numeric
XXLSIZE
jumbo font
2.0.6
DBLSIZE
double size font
MIDSIZE
mid sized font
SMLSIZE
small font
BOLD
bold font
Only color displays. This is a font size on its own - cannot be combined with other font size flags.
SHADOWED
shadow font
Only color displays
INVERS
inverted display
BLINK
blinking text
LEFT
left justify
2.0.6
Default for most functions not related to bitmaps
RIGHT
right justify
CENTER
center justify
Only color displays
VCENTER
center vertically
2.5.0
Only color displays
PREC1
single decimal place
PREC2
two decimal places
GREY_DEFAULT
grey fill
TIMEHOUR
display hours
Only for drawTimer
Name
Description
FORCE
pixels will be black
ERASE
pixels will be white
DOTTED
lines will appear dotted

if the key continues to be pressed, then after a while a LONG event is generated
if the key continues to be pressed, then a REPEAT events are being generated
when the key is released a BREAK event is generated
Couple of examples:
a short press on key would generate: FIRST, BREAK
a longer pres on key would generate: FIRST, LONG, BREAK
even longer press: FIRST, LONG, REPEAT,REPEAT, ..., BREAK
This normal key event sequence can be altered with the killEvents(key) function. Any time this function is called (after the FIRST event) all further key events for this key will be suppressed until the next key press of this key. Examples:
kill immediately after the key press would generate: FIRST
kill after the long key press would generate: FIRST, LONG
The event parameter in the Telemetry and One-Time scripts run function actually carries two pieces of information:
key number
type of event
The two fields are combined into one single number. Some of these combinations are defined as constants and are available to Lua scripts:
Key Event Name
Comments
EVT_MENU_BREAK
MENU key release
EVT_PAGE_BREAK
PAGE key release
EVT_PAGE_LONG
MENU key long press
EVT_ENTER_BREAK
ENT key release
EVT_ENTER_LONG
ENT key long press
Radios with rotary encoder (X7 and Horus) have also:
Key Event Name
Comments
EVT_ROT_BREAK
rotary encoder release
EVT_ROT_LONG
rotary encoder long press
EVT_ROT_LEFT
rotary encoder rotated left
EVT_ROT_RIGHT
rotary encoder rotated right
Given the large number of radios supported by OpenTX, and the large difference in keys available on those, a set of VIRTUAL KEYS has been defined and are mapped to best fit available hardware
Virtual Key Event Name
Comments
EVT_VIRTUAL_NEXT_PAGE
for PAGE navigation
EVT_VIRTUAL_PREV_PAGE
for PAGE navigation
EVT_VIRTUAL_ENTER
EVT_VIRTUAL_ENTER_LONG
EVT_VIRTUAL_MENU
Each model can have up to five main views, with up to 8 widgets per screen, depending on their size and layout. Each instance of a widget has his own options table.
Please note: Widget scripts are only available on radios with color screens, e.g. FrSky Horus models, Radiomaster TX16 and Jumper T16.
All widget scripts on the SD card are loaded into memory when the model is selected; even widgets that are not used. This has the side effect that any global functions defined in a widget script will always be available to other widget scripts. It also means that any script on the SD card will consume part of the radio's memory - even if it is not being used. Therefore, it is important to either keep widget scripts small, or to use Lua's loadScript() function to load code dynamically.
They can be added to the top bar or a main view through the telemetry setup menu. When a widget has been added to a screen, then the widget functions are called as follows:
create is called once when the widget instance is registered (started).
update is called when widget settings are changed by the user.
background is called periodically when the widget instance is not visible. Note: this is different from the way that telemetry scripts are handled.
refresh is called periodically when the widget instance is visible. Note: if you want background to run when the widget is visible, then call it from refresh.
A widget script is stopped and disabled if it misbehaves (e.g. too long runtime, run-time error, or low memory)
All widgets are stopped while a One-Time script is running (see ).
Widgets are located on the SD card, each in their specific folder /WIDGETS/<name>/main.lua (<name> must be in 8 characters or less).
Every script must include a return statement at the end, defining its interface to EdgeTX. This statement returns a table with the following fields:
name string
options table
create function
update function
background function (optional)
refresh function
The name must be max. 10 characters long.
options is passed to create and then stored in Lua. Changing it has no effect on EdgeTX.
If options is changed by the user in the Widget Settings menu, then update will be called with a new options table, unaffected by any changes made by Lua code to the old options table.
Maximum five options are allowed, with names of max. 10 characters, and no spaces.
If local variables are declared outside functions in the widget script, then they are shared between all instances of the widget.
Therefore, local variables that are private for each instance should be added to the widget table in the create function before returning the widget table to EdgeTX.
When the widget is in full screen mode, then event is either 0, a , or a .
If event is a , then touchState is a table. Otherwise, it is nil.
When the widget is not in full screen mode, then both event and touchState are nil.
The size of the widget's screen area is as follows:
Full screen mode: LCD_W by LCD_H
Not full screen mode: zone.w by zone.h
This chapter will show you some ways that large script projects can be fitted into the limited memory of our radios.
Regarding memory, the situation is a bit different for the radios with black/white or grey scale screens and telemetry scripts, and the radios with color screens and widget scripts. The telemetry script radios only have 128-192 KB RAM memory - that is very small! The widget script radios have 8 MB RAM memory. But the way that widgets are designed means that all widget scripts present on the SD card will be loaded into memory, whether or not they are actually used. Therefore, different strategies should be applied to save memory for the two different types of radios and scripts.
Radios with black/white or grey scale screens and telemetry scripts such as e.g. FrSky Taranis, Xlite, Jumper T12 and Radiomaster TX16 have extremely small RAM memories, and therefore it may be necessary to divide up your script into smaller loadable modules.
local name = "WidgetName"
-- Create a table with default options
-- Options can be changed by the user from the Widget Settings menu
-- Notice that each line is a table inside { }
local options = {
{ "Source", SOURCE, 1 },
-- BOOL is actually not a boolean, but toggles between 0 and 1
{ "Boolean", BOOL, 1 },
{ "Value", VALUE, 1, 0, 10},
{ "Color", COLOR, ORANGE },
}
local function create(zone, options)
-- Runs one time when the widget instance is registered
-- Store zone and options in the widget table for later use
local widget = {
zone = zone,
options = options
}
-- Add local variables to the widget table,
-- unless you want to share with other instances!
widget.someVariable = 3
-- Return widget table to EdgeTX
return widget
end
local function update(widget, options)
-- Runs if options are changed from the Widget Settings menu
widget.options = options
end
local function background(widget)
-- Runs periodically only when widget instance is not visible
end
local function refresh(widget, event, touchState)
-- Runs periodically only when widget instance is visible
-- If full screen, then event is 0 or event value, otherwise nil
end
return {
name = name,
options = options,
create = create,
update = update,
refresh = refresh,
background = background
}EVT_EXIT_BREAK
EXIT key release
EVT_PLUS_BREAK
+ key release
EVT_MINUS_BREAK
- key release
EVT_PLUS_FIRST
+ key press
EVT_MINUS_FIRST
- key press
EVT_PLUS_REPT
+ key repeat
EVT_MINUS_REPT
- key repeat
EVT_VIRTUAL_MENU_LONG
EVT_VIRTUAL_NEXT
for FIELDS navigation
EVT_VIRTUAL_NEXT_REPT
for FIELDS navigation
EVT_VIRTUAL_PREV
for FIELDS navigation
EVT_VIRTUAL_PREV_REPT
for FIELDS navigation
EVT_VIRTUAL_INC
for VALUES navigation
EVT_VIRTUAL_INC_REPT
for VALUES navigation
EVT_VIRTUAL_DEC
for VALUES navigation
EVT_VIRTUAL_DEC_REPT
for VALUES navigation
The table shared contains data that is shared between the main telemetry script and the loadable screens. Notice that the functions shared.changeScreen and shared.run are also shared this way.
Code is loaded by shared.changeScreen with the loadScript function, which returns the loadable script as a chunk of code. The code is executed with shared as the argument, and the loadable script adds a new run function to the shared table. shared.run is called by run in the main script.
Radios with color screens and widget scripts such as e.g. FrSky Horus, Jumper T16 and Radiomaster TX16 have fairly large RAM memories, but since all widget scripts present on the SD card are always loaded into memory, they could run out of memory if many big widget scripts are present on the card - even if they are not being used by the selected model. Therefore, large widget scripts should be divided into a small main script and a large loadable part. One way to accomplish this is the following.
The create function loads the file loadable.lua in the folder /WIDGETS/<widget name>/, and calls it immediately as described in the previous section. It passes zone and options as arguments to loadable.lua. This scripts adds the functions refresh, update and (optionally) background to the widget table:
zone and options are stored in the closure of loadable.lua, therefore they do not need to be added to the widget table, as is commonly done.
Obviously, the bulk of the widget's code goes in loadable.lua, and is only loaded if the widgets is in fact being used. Therefore, if the widget is not used, only the small amount of code in main.lua is loaded into the radio's memory.
For an example of a widget that uses the above design pattern, please have a look at the EventDemo widget that is included on the SD card with EdgeTX for color screen radios.
-- Main telemetry script
local shared = { }
shared.screens = {
"/SCRIPTS/Test/menu1.lua",
"/SCRIPTS/Test/menu2.lua",
"/SCRIPTS/Test/menu3.lua"
}
function shared.changeScreen(delta)
shared.current = shared.current + delta
if shared.current > #shared.screens then
shared.current = 1
elseif shared.current < 1 then
shared.current = #shared.screens
end
local chunk = loadScript(shared.screens[shared.current])
chunk(shared)
end
local function init()
shared.current = 1
shared.changeScreen(0)
end
local function run(event)
shared.run(event)
end
return { run = run, init = init }-- /SCRIPTS/Test/menu1.lua
local shared = ...
function shared.run(event)
lcd.clear()
lcd.drawText(20, 10, "Screen 1", MIDSIZE)
if event == EVT_VIRTUAL_NEXT then
shared.changeScreen(1)
elseif event == EVT_VIRTUAL_PREV then
shared.changeScreen(-1)
end
end-- /SCRIPTS/Test/menu2.lua
local shared = ...
function shared.run(event)
lcd.clear()
lcd.drawText(20, 10, "Screen 2", MIDSIZE)
if event == EVT_VIRTUAL_NEXT then
shared.changeScreen(1)
elseif event == EVT_VIRTUAL_PREV then
shared.changeScreen(-1)
end
end-- /SCRIPTS/Test/menu3.lua
local shared = ...
function shared.run(event)
lcd.clear()
lcd.drawText(20, 10, "Screen 3", MIDSIZE)
if event == EVT_VIRTUAL_NEXT then
shared.changeScreen(1)
elseif event == EVT_VIRTUAL_PREV then
shared.changeScreen(-1)
end
end-- main.lua
local name = "<widget name>"
local function create(zone, options)
-- Loadable code is called immediately and returns a widget table
return loadScript("/WIDGETS/" .. name .. "/loadable.lua")(zone, options)
end
local function refresh(widget, event, touchState)
widget.refresh(event, touchState)
end
local options = {
-- default options here
}
local function update(widget, options)
widget.update(options)
end
local function background(widget)
widget.background()
end
return {
name = name,
create = create,
refresh = refresh,
options = options,
update = update,
background = background
}-- loadable.lua
local zone, options = ...
-- The widget table will be returned to the main script.
local widget = { }
function widget.refresh(event, touchState)
-- refresh code here
end
function widget.update(opt)
options = opt
-- update code here
end
function widget.background()
-- background code here
end
-- Return to the create(...) function in the main script
return widgetThis section will discuss how interactive scripts receiving user inputs via key and touch events can be created.
The two Lua widgets EventDemo and LibGUI are provided on the SD card content for color screen radios. EventDemo is just a small widget showing off how key, and especially touch events, can be used. LibGUI contains a globally available library, and a widget showing how the library can be used by other widgets. This section will discuss these two widgets for color screen radios, but generally, what is stated about key events here also applies to the run function in Telemetry and One-Time scripts.
This widget uses the design pattern for saving memory by loadable files discussed in the so all of the action takes place in the file
refresh This is a widget that comes with a global library. Since all widgets are loaded whether or not they are being used, global functions declared in the body of a widget script will always be available. It is not necessary to setup the widget to use the library, and the only purpose of the widget is to show how LibGUI can be used to create apps.
The library is implemented in the loadable file /WIDGETS/LibGUI/libgui.lua. The widget that demonstrates how to use the library is implemented in the loadable file /WIDGETS/LibGUI/loadable.lua. The file /WIDGETS/LibGUI/main.lua contains a global function that loads the library and the standard functions needed for a widget.
The global function loadGUI() returns a new libGUI object. This object can be used to create new GUIobjects, which are used to create screens with elements like buttons, menus, labels, numbers that can be edited, and timers.
libGUI has the following properties controlling general settings for the library.
These are default drawing flags to be applied if no flags are given at creation of screen elements.
Note: these flags should not contain color values, as colors are added by the following.
This is a table of colors used for drawing the GUI elements. The following colors are available:
Color
Default value
Used for
text
COLOR_THEME_PRIMARY3
Text on labels, menus etc.
focusText
COLOR_THEME_PRIMARY2
Text on buttons and numbers/timers being edited.
buttonBackground
COLOR_THEME_FOCUS
Background on buttons and numbers/timers being edited.
editBackground
Notice that all of the default colors are theme colors. This will make the GUI screens use the contemporary color theme.
This is a small utility function that returns true if the first argument x matches any of the following arguments. It is useful for comparing values of event, e.g. if we want to test if the user pressed either of the following buttons, we can use:libGUI.match(event, EVT_VIRTUAL_ENTER, EVT_VIRTUAL_EXIT, EVT_VIRTUAL_MENU)
This is the main function that creates a new GUI object. If an application has different screens, then a GUI object is created for each screen.
A function f() to draw the zone of the screen in widget mode. It takes no arguments.
A function f(event, touchState) to draw the screen background in full screen mode. The GUI elements are drawn afterwards on top.
A GUI (or another table with a function run(event, touchState). When this is set, the GUI will first be drawn, and then it will call prompt.run(event, touchState) instead of running itself. That way, the prompt can implement a modal prompt window.
Redraws the screen and processes key and touch events. It can directly replace a widget's refresh function, or it can be called by refresh.
Sets a function f(event, touchState) to handle an event. If no GUI element is being edited, then this can trap events before they are passed to the GUI, e.g. to press EXIT to go back to the previous screen. If f is nil, then the event handler is removed.
The screen elements are drawn in the order that they are added to the GUI, and touch events are sent to the first element that covers the touched point of the screen. GUI elements therefore should never overlap.
There are some common properties that can be set for all or most of the GUI elements.
element.disabled = true prevents the element from taking focus and receiving events, and disabled buttons are greyed out.
element.hidden = true in addition to the above, the element is not drawn.
element.title can be changed for elements with a title.
element.value can be changed for elements with a value.
element.flags drawing flags for the element's text. If no flags were given at element creation, it defaults to GUI.flags.
elements.blink will make non-button elements blink
elements.invers will make non-button elements draw in inversed colors.
The various screen elements are added to the GUI with the functions described below. The functions all add the element to the GUI and returns a reference so the element subsequently can be accessed by the client.
Add a button to the GUI.
When tapped, it calls callBack(self) so a call back function can tell which button activated it.
Add a toggle button to the GUI.
The value is either true or false.
When tapped, it calls callBack(self) so a call back function can tell which toggle button activated it, and what self.value is.
Add an editable number to the GUI.
The value can be either a number or text. By setting the value to a text, it can be shown that the number is not present e.g. by "- -" or similar.
When tapped, the number will go to edit mode. In edit mode, events are passed to callBack(self, event, touchState). Thereby, the call back function can use events to edit the number, e.g. sliding a finger up and down can increase and decrease the value. You can look in the LibGUI widget's loadable file for an example of this.
Add a timer to the GUI.
If no value is present, then the model timer tmr will be shown. If value is a number, then it indicates the time in seconds, and it will be shown as MM:SS. The value can also be text, e.g. "- - : - -" to show that the timer is disabled.
When tapped, the timer will go to edit mode, as described above for number.
Add a text label to the GUI.
The label does not respond to any events, but its title and flags can be changed.
Add a scrollable menu to the GUI. This function returns a table with each of the menu's line elements.
visibleCount is the number of visible menu items.
items is a table with the menu item texts.
When a menu item is tapped, it calls callBack(self). Each menu element has a field self.idx giving the index in the menu, and this can be used by callBack to see which menu item was selected.
Notice that the menu's width is decided by the item texts and the font flags, and the height is decided by visibleCount and the font flags.
-- This code chunk is loaded on demand by the widget's main script
-- when the create(...) function is run. Hence, the body of this
-- file is executed by the widget's create(...) function.
-- zone and options were passed as arguments to chunk(...)
local zone, options = ...
-- The widget table will be returned to the main script
local widget = { }
function widget.refresh(event, touchState)
if event == nil then -- Widget mode
-- Draw in widget mode. The size equals zone.w by zone.h
else -- Full screen mode
-- Draw in full screen mode. The size equals LCD_W by LCD_H
if event ~= 0 then -- Do we have an event?
if touchState then -- Only touch events come with a touchState
if event == EVT_TOUCH_FIRST then
-- When the finger first hits the screen
elseif event == EVT_TOUCH_BREAK then
-- When the finger leaves the screen and did not slide on it
elseif event == EVT_TOUCH_TAP then
-- A short tap gives TAP instead of BREAK
-- touchState.tapCount shows number of taps
elseif event == EVT_TOUCH_SLIDE then
-- Sliding the finger gives a SLIDE instead of BREAK or TAP
if touchState.swipeRight then
-- Is true if user swiped right
elseif touchState.swipeLeft then
elseif touchState.swipeUp then
elseif touchState.swipeDown then
-- etc.
else
-- Sliding but not swiping
end
end
else -- event ~= 0 and touchState == nil: key event
if event == EVT_VIRTUAL_ENTER then
-- User hit ENTER
elseif event == EVT_VIRTUAL_EXIT then
-- etc.
end
end
end
end
endCOLOR_THEME_EDIT
Background when a value is being edited.
active
COLOR_THEME_ACTIVE
Background on active toggle buttons and the border around selected elements.