edgetx / edgetx

EdgeTX is the cutting edge open source firmware for your R/C radio

Welcome to EdgeTX!

The cutting edge open-source firmware for your R/C radio!

About EdgeTX

EdgeTX is the cutting edge of OpenTX. It is the place where innovative ideas and cutting-edge features are developed and field-tested by the enthusiasts of our hobby. EdgeTX is a community project – ideas from the community, developed by the community, and enjoyed by the community! The community will always have a say in what EdgeTX is and what EdgeTX will be in the future. Without community feedback and involvement EdgeTX cannot exist.

Community

Discord

Facebook

Github Discussions

Navigation Links

Community Guidelines

Installation Guide

Installation Video

FAQ

Reporting Issues / Requesting features

Development WIKI

Lua Documentation Site

Flasher Info Page

Flasher Downloads

SD Card Info Page

SD Card Downloads

Sound Packs Info Page

Sound Packs Downloads

EdgeTX Build Environment Docker Images

Acknowledgements

Some icon assets provided by ICONS8.
Lua Documentation site powered with the kind support of GitBook.

edgetx's Issues

Touch interface (make more fields listboxes)

It looks like the input for 'Pwr Off delay' has a limited range of options - 0s, 1s, 2s and 3s - or at least it does on the Radiomaster TX-16s firmware. Making it a list like say 'Backlight Mode' would make it more accessible for touch.

Below is a non-exhaustive list of the various entries that seem to have ranges, so potential drop down list candidates

Radio Settings

Radio Setup

• Date - Year, Month, Day
• Time - Hour, Minutes, Seconds
• Variometer - Pitch zero, Pitch max, Repeat zero
• Alarms - Battery low
• Pwr Off delay
• GPS - Time zone
• Play delay

Trainer

• Multiplier

Model Settings

Model Setup

Internal RF (Multi) - Channel Range (start and end) + others depending on mode selected
External RF( XJT) - Channel Range (start and end) + others depending on mode selected
Trainer - Channel Range (start and end)

Color UI is left in an incorrect state when entering USB mass-storage

And not properly reloaded after USB mass storage mode is left.

Original description from @pfeerick:
"I can finally report one seemingly new mostly cosmetic bug on current bef88d2 ... go into any menu... radio setup, model setup, etc. plug in the USB, enable storage mode, unplug the USB, and admire... looks like it needs a full screen refresh, and something about navigation is lost/broken - only way to go back seems to via the touch screen, rather than RTN button."

In fact, we're quite lucky the whole thing does not crash (pure luck).

Reversed Pots on display:

Test report by @rotorman:
On the calibration screen, on TX16S, the pot S1 and S2 state are IMHO shown on the screen horizontally mirrored - turning the pots clockwise make the needle wonder to left and vice-versa. I believe it should be CW movement -> needle to the right.

[Feature Request] Mixer / Output mapping

Miami Mike described it pretty well in his blog on RCG:
https://www.rcgroups.com/forums/showthread.php?3883631-How-OpenTX-should-have-worked

pilot-lon, pilot-lan as table keys is very confusing on GPS sensor return

https://doc.open-tx.org/opentx-2-3-lua-reference-guide/part_iii_-_opentx_lua_api_reference/general-functions-less-than-greater-than-luadoc-begin-general/getvalue

By having a key that contains a minus sign, 'pilot-lon' and 'pilot-lan', referencing the valus is really cumbersome:

getValue("GPS")["pilot-lan"] needs to be used now because getValue("GPS").pilot-lan will try to substract value for variable 'lan' from a value for key 'pilot' .

Why not change the labels to 'pilot_lon' and 'pilot_lan' and simply use getValue("GPS").pilot_lan ???

Get rid of the return {run=run, background=background, init=init} closing line on any script

Can we do that?

• it is confusing, not necessary and scares people off
• make any code run in the current RUN mode, only when the screen is visible. Any code to be run in the background can be defined in a background function. No need to return it as such, just convention on the name. Or even an API function that passes code to a background routine.

LUA widget visual glitch / flicker

Test report by @rotorman:
Running (my MavSDK enhanced) Yaapu LUA screen (https://www.rcgroups.com/forums/showthread.php?3840599-Blog-6-Modified-Yaapu-telemetry-widget-to-support-MavSDK-native-MAVLink-on-OpenTX), I see elements sometimes flicker to foreground that should be on background behind other elements drawn on top - likely an issue with graphics library.

[Feature Request] mixer minimum of 25hz

Allow the mixer to go to a minimum freq of 25hz,

Please add T18 / TX18S build

There is no firmware build ATM for T18/TX18S, please consider adding these models.
some models of T18 /TX18s have touch screen, some models don't... maybe it will be better to divide in two models

allow io.stderr:write(message) to output debug info

io.stderr is the default output for debug messages. Can we enable it to be used to output all debug info to the deug window on companion simulator, instead of the io.ouput that is supposed to be the default output (which would be the LCD??)

Then also allow to set the debug output to either a file or the debug window as an option?

Flashing bootloader from EdgeTX fails (at least with RM TX16S)

Flashing EdgeTX radio bootloader binary from running EdgeTX presently fails (at least with RM TX16S and with efdf76a).

As you can see in the video below, it gives SD card error (video 0:15 mark), although when flashing the same bootloader.bin with STM32CubeProgrammer and then flashing the radio binary (efdf76a) using this bootloader from the same card, all works. Otherwise also, no errors with this specific microSD card.

https://www.youtube.com/watch?v=GHqrVRQjqs8

As you can also see, after pressing RTN, Flash successful is wrongly output (0:20 mark). When trying to boot into bootloader (trims T1+T4 together, power-on), bootloader does not start, thus flashing was unsuccessful (0:33 mark). Have to pull battery/cut power to shut off.

Return button keeps change

observed on a Jumper T16:

when doing changes to settings and one is returning by pressing the RTN button, then the changes are accepted nevertheless! They should be accepted only upon a press of return.

This is pretty annoying since it is essentially impossible to jump out from wrong changes.

Selecting Image file for Model when no images on SD card causes radio to go black and lockup

When editing a model, if you have no images on SD Card, and you try to select one, the radio goes black and hangs forcing reboot after deplaing dialog "No Files on SD Card".

Video can be seen: [Here]https://youtu.be/PKR3vtQaq_Q

Add an indicator icon for haptic vibration to the radio screens.

This is another issue that I raised in the OpenTX GitHub forum which was ignored and eventually marked stale.

When you set up haptic vibrations in Companion, either on the Radio settings Setup tab, or with a special function, or through a Lua script, there's no indication in Companion simulator when haptic vibrations are active.

A little animated icon on the radio home screen would work. It would not only indicate haptic activity as it happens in Companion simulator, it would also indicate on the actual radio screen that the system is at least trying to create vibration. In that case, when vibration doesn't actually happen the user would know that the radio has a hardware problem.

MDL Button long press doesn't go back

observed on a Jumper T16:

previously it was possible to navigate forward and backwards by pressing e.g. the MDL button short or long.

The pressing long and go backwards features is not possible anymore now.

Make the LUA output page one of the mains screens

Give it a PLACE, please.

• Make only ONE entry on a model setup to load only ONE script, and give it a FIXED place in the radio MAIN menu.

• Show 'NO SCRIPT LOADED' if no script is loaded to emphasize it is there!

• So no long page press to start, no pagination between different scripts, no hidden away location to configure the scripts on a telemetry page, no popups when the script page is in view.

Can we get rid of the last functional legacy terminology of MODE and RETA definitions?

In principle the four sticks are not predestined for Rudder, Elevator, Throttle and Ailerons, as we can use the radio equally well for drones, that don't even have ailerons for example.
The alternative of Yaw, Pitch, Throttle and Roll doesn't work either in all cases, since that doesn't make sense for drones. There is no 'correct' choice possible.

So after some consideration I think the stick inputs should nonetheless be renamed to use the desired motion of a simple plane using these control inputs, rather than naming them after the control surfaces that on a basic plane would generate that motion. We should reserve those for the actual outputs, that would transfer the control inputs to the desired movements of the control surfaces, who would in turn lead to the desired motion.
Mixes would then allow to make corrections, necessary due to the physical limitations/behavior of the craft, to create an as pure as possible transfer of desired motion to actual motion. Think of mixing some roll to rudder, next to the direct roll to aileron 'mix', so that roll input would create a pure roll of the craft, and no barrel roll.

The above would have impact on several things:

If you create a default model, that is, with the wizard or just without an SDcard using the radio default settings, the mix flow is currently the following:
stick source -> inputLine with trim ON and names -> mixerLine with trim ON -> outputLine without names
The ordering will follow the radio setting, so RETA, RAET, whatever, from input to output. It is NOT taking the mode into account.

There are several things I don't like with this. It seems a bad compromise to me of straightforward technical mixer setup from input to output with the legacy remains or appearance of a functional plane setup.
I would propose to either do a PURE technical setup, or do a correct functional setup.

PURE technical setup, no inputLines needed:
stick source -> mixerLine with trim ON -> outputLine
mixerLines ordered based on the stick sources, following the RETA definition in the Radio settings. No names, labels or nothing. Here you can see how the current definitions would actually link the Rud, Ele, Thr and Ail input sources to the output control surfaces Rudder, ELevator, Throttle and Aileron. It was how it was when we had no computer mixers.

Correct functional setup:
I assume the stick sources are renamed hardcoded to Yaw, Pitch, Throt and Roll.
People can still label them as Rud, Ele, Thr and Ail if they want to stick with legacy names, or name them Yaw, Forward, Throttle and LeftRight when flying drones.
That labeling should by the way be by preference be on a MODEL level, not on radio level. I would omit it all together, and stick with only Yaw, Pitch, Throt and Roll.

So for the RADIO created default model (no wizard) I would use then
stick source -> inputLine with trims -> mixerLine -> outputLine with name
So no naming on the inputLines, and certainly no confusing trim ON on the mixerLines. The inputLine order would follow the MODE, so

1. Yaw, Pitch, Throt, Roll
2. Yaw, Throt, Pitch, Roll
3. Yaw, Pitch, Throt, Yaw
4. Roll, Throt, Picth, Yaw
   The mixerLines would follow the RETA definition on the radio setup. The outputLines are named accordingly to prevent confusion. The mixers would do the exact mapping. The mixer for the Elevator would have a weight of -100%, so that all control surfaces would comply with the very important notion of the mixer output being positive for desired positive output surface deflection on corresponding stick input.

Why is this important?

First of all, for newcomers, This dual use of the same names for inputs and outputs is confusing. Als, using the trim flag is SUPER confusing being present on both inputs and mixers, where they have no role on the mixes in a setup where the source of the mix is an inputline.
Second, if we want to start newcomers to understand the basics, better have it correctly applied from the start. Using the desired behavior as label for the control inputs and the naming resulting outputs after the surfaces you want to control is standard practive in all control system setups.

I will attach some screenshots to clarify.

I know this is not a High Prio request, but I think you must not underestimate the impact it might have to get newcomers to understandthe basics of OpenTX.

No script for NV14 building

There is no script for NV14 building. I will see if I can add one. Please help to verify if I made any mistakes. Thanks.

[Feature Request] Support normal and expert mode

I would really be thrilled if the following option would become available from the is GUI.

Normal and expert mode.

What in normal mode?

Simplified radio setup for only things that you would want to change regularly, like RTC, owner name, mode and calibration.
Only nput's labelled as normal, with limited options, like source, weight, expo
Only mixes labeled as normal, with limited options, like add/multiplying,/replace, source, weight, expo and switches
No logical switches (but they are named and can be used as sources
Special functions limited to the normal labelled ones, with a limited set of options, mainly voice commands
Only the available outputs as in mike's proposal.
For all values on those limited parameters, allow every source. Allow for proper 6 or 8 char naming of all sources, if necessary by an external lookup table.

Now in the expert mode, all becomes available without limitations.

In this way, you could create templates with expert mixer blocks created in expert mode. They can be labeled for use in normal mode. Now I can just take normal mode, assign expert mixes to the outputs that where defined and labelled in the expert mode.(outputs redesign from Mike)

Or Expose the main expert mixes by having them as source on 4 normal mixes for the available 4 outputs.

Want to add stuff to these expert mixes? Just select the sources on four normal muxes to be ailerons, rudder, elevator and flaps expert mixes.
Add rudder input or the rudder expert mix on a second line as source after the aileron expert mode sourced normal aileron mix to add rudder to aileron mix in NORMAL mode.
Select the output to be sourced by your new normal mode mixed channel.

GVARS need to be able to be managed much easier. A list with named GVARS showing the values of the active flight mode to be edited. Also only the normal labelled ones, that can be used as adjusters for the params of the expert mixes.

So basically:

1. in normal mode, limit the options in the GUI and the objects defined as normal, but with the expert objects referencable
2. Allow all in expert mode.
3. Support readable naming on all objects.
4. Have fun and just fly

ViewMain looses focus under certain circumstances

When playing with the UI, it can happen that the main view looses the focus to the widget layout, thus effecting to block key inputs and thus makes the main menu inaccessible until a touch event resets the focus, which problematic on radios which do not have touch input.

This has been reported by @rotorman.

Here is the serial debug log:

+00000ms: 34.52 MainWindow::run took 84ms<\r><\n>
+00000ms: 34.62 # Layout2P1 refresh: Layout [480, 0, 480, 272]<\r><\n>
+00000ms: 34.62 Refresh rect: left=480 top=0 width=480 height=272<\r><\n>
+00000ms: 34.63 MainWindow [0, 0, 480, 272]<\r><\n>
+00000ms: 34.64 MainWindow::run took 13ms<\r><\n>
+00000ms: 34.87 # Layout2P1 refresh: Layout [0, 0, 480, 272]<\r><\n>
+00000ms: 34.87 Refresh full screen<\r><\n>
+00000ms: 34.87 MainWindow [0, 0, 480, 272]<\r><\n>
+00000ms: 34.87   ViewMain [0, 0, 480, 272] (*)<\r><\n>
+00000ms: 34.87 ### ViewMain::paint(offset_x=0;offset_y=0) ###<\r><\n>
+00000ms: 34.88     TopBar [0, 0, 480, 45]<\r><\n>
+00000ms: 34.89       Widget [49, 3, 70, 39]<\r><\n>
+00000ms: 34.89     Layout [0, 0, 480, 272]<\r><\n>
+00000ms: 34.89 # painting -> Layout [0, 0, 480, 272]<\r><\n>
+00000ms: 34.89       ViewMainDecoration [0, 0, 480, 272]<\r><\n>
+00000ms: 34.89         Window [5, 255, 177, 17]<\r><\n>
+00000ms: 34.89         Window [215, 255, 50, 20]<\r><\n>
+00000ms: 34.90         Window [298, 255, 177, 17]<\r><\n>
+00000ms: 34.90         Window [0, 56, 17, 88]<\r><\n>
+00000ms: 34.90         Window [463, 56, 17, 88]<\r><\n>
+00000ms: 34.90         Window [0, 146, 17, 88]<\r><\n>
+00000ms: 34.90         Window [463, 146, 17, 88]<\r><\n>
+00000ms: 34.91         Window [5, 238, 177, 17]<\r><\n>
+00000ms: 34.91         Window [298, 238, 177, 17]<\r><\n>
+00000ms: 34.91         Window [17, 56, 17, 177]<\r><\n>
+00000ms: 34.91         Window [446, 56, 17, 177]<\r><\n>
+00000ms: 34.91         StaticText "" [182, 235, 116, 20]<\r><\n>
+00000ms: 34.92 MainWindow::run took 46ms<\r><\n>
+00000ms: 34.97 Layout [FormGroup] [0, 0, 480, 272] setFocus(0)<\r><\n>
+00000ms: 34.97 ViewMain [0, 0, 480, 272] onFocusLost()<\r><\n>
+00000ms: 34.97 [ViewMain] Focus lost<\r><\n>
+00000ms: 34.97 Refresh full screen<\r><\n>
+00000ms: 34.97 MainWindow [0, 0, 480, 272]<\r><\n>
+00000ms: 34.97   ViewMain [0, 0, 480, 272]<\r><\n>
+00000ms: 34.97 ### ViewMain::paint(offset_x=0;offset_y=0) ###<\r><\n>
+00000ms: 34.99     TopBar [0, 0, 480, 45]<\r><\n>
+00000ms: 34.99       Widget [49, 3, 70, 39]<\r><\n>
+00000ms: 34.99     Layout [0, 0, 480, 272] (*)<\r><\n>
+00000ms: 34.99 # painting -> Layout [0, 0, 480, 272]<\r><\n>
+00000ms: 34.99       ViewMainDecoration [0, 0, 480, 272]<\r><\n>
+00000ms: 34.99         Window [5, 255, 177, 17]<\r><\n>
+00000ms: 34.99         Window [215, 255, 50, 20]<\r><\n>
+00000ms: 35.00         Window [298, 255, 177, 17]<\r><\n>
+00000ms: 35.00         Window [0, 56, 17, 88]<\r><\n>
+00000ms: 35.00         Window [463, 56, 17, 88]<\r><\n>
+00000ms: 35.00         Window [0, 146, 17, 88]<\r><\n>
+00000ms: 35.00         Window [463, 146, 17, 88]<\r><\n>
+00000ms: 35.01         Window [5, 238, 177, 17]<\r><\n>
+00000ms: 35.01         Window [298, 238, 177, 17]<\r><\n>
+00000ms: 35.01         Window [17, 56, 17, 177]<\r><\n>
+00000ms: 35.01         Window [446, 56, 17, 177]<\r><\n>
+00000ms: 35.01         StaticText "" [182, 235, 116, 20]<\r><\n>
+00000ms: 35.02 MainWindow::run took 50ms<\r><\n>
+00000ms: 35.02 Layout [FormGroup] [0, 0, 480, 272] received event 0x1003<\r><\n>
+00000ms: 35.07 Layout [FormGroup] [0, 0, 480, 272] received event 0x1003<\r><\n>

LUA - model.setFlightMode() problem with trimValue #8373 on OpenTX

So we need to have some guidance here.

So what do we do with OpenTX bugs, probably not solved in OPenTX, like the above?

I would rather shoot on a moving target, than trying to pull a dead horse. But its up to you guys.

Enhancement - some menus don't jump to first entry

As a concrete example, with a TX16S, if you go to the 'select models' screen, and press enter, the popup menu (select model, create model, duplicate model, delete model - or just create model and duplicate model if you select the active model) will appear, but you will need to roll the scroll wheel to highlight the first item on the menu. Which gets annoying if you scrolled to select your model, and then have to roll the scroll wheel to highlight select rather than just press enter the second time.

Whilst it would be counter-intuitive for a touch screen only interface, given that most of the transmitters are a hybrid of both button and touch-screen interaction - or can be - the first item should be 'jumped to' automatically. Somewhat similar to a combo box that will highlight the currently selected item automatically (i.e. Radio Setup -> Mode -> jumps to the currently selected 'NoKey' when the list shows).

It's possible this is on the only menu that does this... I'll edit this if I encounter another.

So far, it is:

• Select model -> menu for active or inactive model
• Insert USB lead -> USB menu
• Widget setup -> setup widgets (top menu or panel) -> touch a box for a widget -> actions menu (minor secondary issue - when selecting a empty widget box, menu background sizing suggests there would be two entries, but there is only one)
• Following on from last point -> the widget selection menu shown when you choose 'select widget'
• Model setup => Inputs, Mixes, and Outputs, Curves, Global Variables, Logical Switches, Special function line item menus (once entry exists)

Rolling release

Betaflight Configurator Nightlies looks like a perfect method to offer EdgeTX rolling releases.. could that be done for EdgeTX builds? 🤔

How best to handle MULTIPLY on the first mix line?

Back in February of 2017 I brought up the fact that in OpenTX 2.1.9, the first line of a mix could be set to MULTIPLY, which would completely disable that line due to the lack of anything above to multiply it by, and there would be no visible cause for the resulting dead mix line because the multiplex setting of the first line in a mix wasn't displayed.

I argued for automatically treating that first mix line as a starting value and not even providing a multiplex option for it, since ADD and REPLACE should have identical behavior* and MULTIPLY is pointless, but the developers chose instead to keep the MULTIPLY setting but display a "MULT!" warning. (When you set a first mix line to MULTIPLY and see "MULT!" that's the result of one of my contributions.)

Is the developers' choice the ideal solution? I won't argue one way or the other at this point but it's something you guys might want to consider.

Footnote: ADD and REPLACE don't have identical behavior in some cases where the Slow function is used, but that's a quirk in the Slow function that I intend to address separately.

Return autedetect of basic sensors

Please create a list of 'normal' sensors in a fixed order as we had on 2.1 on fixed positions to be populated on model select.

Whenever more than one sensor is found with the same name, define all as expert sensors, and pop up a warning that expert sensors are used in the model.

This avoids the dangerous situation of sensors being mixed up at start or after rediscovery, after changing hardware sensor configuration.

Powering down with usb connected -> weird state

when powering down with a usb connected, it ends up in a weird state, and the transmitter does not actually switch off

it IMHO either should not allow powering down when the usb is connected, or terminate all properly

In OpenTX you can't turn the backlight on to read a model note because it won't turn on until you dismiss the note.

I posted this on the OpenTX GitHub forum in June of 2019 and there was no response. It was eventually marked stale, and the problem still exists in OpenTX 2.3.11.

If you have the backlight set up to turn on and off with a special function, and you have a model note set up to appear when you turn the radio on or select a model, you can't turn the backlight on until you dismiss the model note. It's a classic Catch-22!

Tools incorrectly populated

this can happen every once in a while
seems to be more likely when on is pressing various keys fast

Correct API table behaviour

Lua is passing tables BY REFERENCE in function calls.

This means that you can change the values in a table by passing it to a function, without having to return anything from that function.

I suggest to use one table structure as only parameter to pass to any API function, apart from the object identifier.. The API should take that table and change any key-value pairs that are to be updated and update them.

So if send an empty table to the function Mixerline for Mixerline 20, it would get populated with the actual attributes as key-value pairs of that mixer. A value can be a table, as in standard lua.

If I would provide some key-value pairs in that same table, the function Mixerline would need to update the attributes on the Mixerline, and adjust the key-value pair in the table to the new value. If an out of range value would be provided, it would get corrected to the most appropriate value, that would be set both on the mixer as in the referenced table. More than max would become max, less than min would become min.

As a second enhancement, one could even make the objects and attributes available as a table structure, so that you can just reference to any value in lua, and it is directly linked to the object attribute.

This would allow to get rid of ALL special LUA API functions!!

No TopBar Icons

Hi,

I just have given EdgeTX initial run.
Tried builds tx16s-9691cc9 and tx16s-f97843c from 25th of May

1. Went to https://downloads.open-tx.org/2.4/nightlies/sdcard/ to get updated SD card content

• all files are named V0026
• there is no file for RM TX16S
  Downloaded the one for Jumper T16 as closest one

2. After power up with EgdeTX I can't see single icon on Top Bar including Logo.
   EdgeTX seems to work as expected only icons are not displayed

3. There is no way to change Theme (maybe intentional) so assumed Default is used, Then checked /THEMES/DEFAULT/ folder in downloaded zip and there are only 4 files (including two mask_****.png)
   Copied missing files from /THEMES/DARKBLUE/ but still TopBar icons are not visible.

Bug or I'm doing something wrong?

Bug: Selecting XJT then PPM crashes *something* on TX16s

When changing External RF from XJT to PPM, the power LED and screen backlight go out, then the power led and backlight comes back on with the screen blank. Pressing 'RTN' etc appears to do nothing. When pressing and holding the power butting the power delay squares come on, and the Tx turns off. This is all with no module fitted. Equipping a Frsky XJT module does not make any observable difference.

Does not occur when changing from OFF to PPM, and does not appear to happen when going to any other Mode. It also does not happen when going from XJT to any other mode (ie GHST, DSM2). But if you then change from that intemediate mode to PPM, it will happen.

In other words

OFF -> PPM -> XJT ok
OFF -> XJT -> PPM bad
OFF -> XJT -> GHST ok
OFF -> XJT -> GHST -> PPM bad
OFF -> PPM -> XJT - > DSM2 -> PPM bad

It could be a red herring, [EDIT: I believe it is... OTX 2.3.10 doesn't exhibit this behaviour on the same TX] but I do not believe this to be new, but related to a preexisting OpenTX bug which affected the 9XR-PRO, but I had not noticed on the TX16s as yet.

tx16s-edgetx-60726891, #85ebb168

LUA touch API

As 2.4 brings touch screen support, we need to come up with an API design to allow for touch screen features to be supported in LUA scripts as well, thus allowing a lot of new features based on scripts.

First of all, we need requirements, then we can figure out how to implement them.

Fix the trim problem that has always existed in OpenTX

Somewhere in the OpenTX source code for trims you'll find a constant of 250 that was almost certainly meant to be 256. The result is that the trim limit, which was presumably intended to be 25%, is instead 24.4140625%.

For details please see opentx/opentx#4489 on the GitHub OpenTX forum, and
https://www.rcgroups.com/forums/showthread.php?p=47139791&postcount=41 on RCGroups.

[Feature Request] Create a common input layout for all radios

Currently, every radio has a different number of switches defined, trims, etc.

This is of course defined by hardware available.

Yet, if there would be one virtualization of all radios, where you can map all physical switches to the common radio model, and assign physical inputs or fixed values of up,mid and down, or even percentage values, to all those inputs at will, all models and scripts would become interchangeable between radio models.

We need this to increase interoperability of models and scripts, so we can finally start community effort on sharing these.

See https://www.justfly.solutions/index.php/full-repository

Touch interface - back button

The back button for a lot of menus is currently overlaid over the logo in the right corner... sort of.

I actually think it should be kept where it is, but make it bigger and blank that logo off completely. Then it becomes "press the logo" (and/or top row) of the screen for options, and then when in the menus press that same spot to go back.

tx16s-edgetx-60726891, #85ebb168

Graphical Plane/Wing/Quad Setup

As the Title suggests, a Graphical Plane/Wing/Quad setup when creating a new Model with easy to understand graphics.

-Choosing Aircraft type

Airplane

• -Choosing number of servos/Airplane Type
• -Assigning Channels to servos
• -Choosing Switches you want to have
• -Automatic mixer generation for easy Model creation
• -Dual/Triple Rates (maybe 100/60/40?) assignable to Switch

Wing

• -Choosing number of servos
• -Assigning Channels to servos
• -Choosing Switches you want to have
• -Automatic mixer generation for easy Model creation
• -Dual/Triple Rates (maybe 100/60/40?) assignable to Switch

Quad

• -Choosing Channel-Order (TAER, AETR etc.) and Mode 1/2/3/4

• -Choosing Switches for Functions like Arming/Angle/etc.

• The Switches should all be named automatically if you create a model this way

TX16S, adding new view with non-default layout, top 2 configuration elements not reachable with roller anymore

Tested on TX16S with 88e62e1.

When adding a new view with non-standard layout, after changing the layout type, top two elements (Layout type itself and Button Setup widgets) are not reachable anymore with roller.

https://www.youtube.com/watch?v=J1fT4ibWUNA

When not changing the layout type, the top two menus remain accessible as can be seen from 0:09 to 0:19. By changing the layout to anything non-default (0:21), the user can one time scroll through Setup widgets downwards, but not up back again. The upmost element reachable with roller is now Top bar and the roller jumps by further scrolling upwards to bottom-most element Remove screen. Scrolling the other way, also does not make the Setup widgets and Layout accessible (0:23 - 0:38).

Cool ideas for SPI flash on X10 derivates?

Many have wondered why the SPI flash is not used in OTX/ETX. IMHO, it is more for the lack of nice ideas than anything else. As pointed out here, most things are "prepared", but not used at all:
https://www.rcgroups.com/forums/showthread.php?3859585-Blog-14-RadioMaster-TX16S-SPI-Flash-readout

So now, what could we make out of it? Does it even make sense to try it out?

@rotorman Already did some work on it:
opentx/opentx#8365

[Feature Request] Enable touch control of rc channels

With the enabling of the touch screen it would be great to allow touch inputs to be processed in a way that allows them to be used as if they were physical switches.

An example may be of an on screen "button" that enables pre-arm of a quad rather than using a physical switch.

I can think of a few options - make a logical switch equal an on screen button, or use Lua to create a widget that would do the same thing

Manage sdcard content better

Sdcards are HUGE nowadays, so let's not optimise storage capacity. No need for that.

That allows to have the radio use a directory as curdir, instead of the root. Than we can switch between firmware versions on the radio, by keeping different folders for different firmware versions.

This also allows for non_version specific folders for non_version related content, such as named voice files, images, log files and model note files.

Finally, this would also allow for radio type specific folders, so we would have one sdcard content set only for all radios, that is automatically supporting backwards compatibility by just including the folder structure and content for versions over time.

Also, predefined templates to be used for easily restoring model files adapted for radio specific configurations would become possible.

One to rule them all...

Can no longer scroll menu using touch screen

When adding a widget to top widget bar on screen, scrolling the menu on the touch screen no longer works. Scrolling from the jog wheel still works.

Please see video example https://youtu.be/J5hxsmTakZI

Unable to force shutdown when receiver still connected

Test report by @rotorman:
When telemetry link is active (RSSI bar shows signal), cannot nicely shut down the radio. No dialog to confirm shut-down, or possibility to exit the Shutdown screen. Deadlock, need to hard-cut power/pull battery.

Make the LUA PRINT command output on the radio LCD, instead of the debug window

Make the PRINT command working on a dedicated screen

• People are thrilled when they can just make a 'HelloWorld.lua', containing the line "print("Hello world")" and have it executed.

After every print command shift the lines down one row, and keep them in the 'print buffer'.
Every line that 'falls off the screen" get's removed from the buffer.

Bug - Emergency Mode if power off whilst 'failsafe not set' screen active

RM TX16S, 945fc95

Whilst testing #74, I made the mistake of trying to power off the unit whilst the 'failsafe warning: failsafe not set' screen was showing (internal multimod set to frsky, receiver not powered). The shutdown delay screen shows, but before any segments start to show, the screen goes back, then the transmitter goes into emergency mode.

EdgeTX Logo briefly visible between multiple warning messages at boot-up

During startup, when multiple warning messages are shown (here e.g. throttle and SD card), briefly EdgeTX logo is visible, when the display switches from one warning message to other. The following video shows this at roughly 9 second mark:
https://www.youtube.com/watch?v=TEQGIJDvzvU

In OpenTX, when reading the value of an input the effect of trim is omitted.

Set up a "Numbers" telemetry screen that monitors a stick input and you'll see that the effect of trim is omitted. There's no way to directly monitor the value that an input sends to a mix while it has a non-zero trim setting.

The lack also exists in Lua: Input1 (lua script).txt

I don't know if the OpenTX developers would be interested in fixing this because it's been this way at least since 2.1.9 and has probably always worked like this, but it would be nice to see it done right in EdgeTX.

How about simplifying and improving the API for model settings

I have a proposal for an, in my opinion and based on my experience, better way of updating/retrieving model settings. We can even start introducing it without killing the legacy code, but in the end nobody will use that anymore if this is going to work as intended (we can keep legacy in for a long time, I assume).

Basic idea is to create a combination of the get and the set functionality in one function, and using a referenced table passed to that function.

Instead of using model.getObject(id) that returns a table, and model.setObject(id,table) that will set the values, I propose to use model.object(id,table) where the table is passed by reference, and returned as a result as well.

• The keys-values provided in the table will update the model settings to the new values, if within range.
• The key-values that could not be updated on the model, will be populated with the current values of the model.
• Any missing key-values will be added with the current model values.
• A new table is created if there was no table passed.
• The table in the arguments passed to the function will also be returned as a function result to allow quick population of settings arrays in the init of any script.

An extensive explanation with pseudo code examples is given here: https://www.rcgroups.com/forums/showthread.php?3903011-How-I-would-set-up-the-EdgeTX-LUA-API#post47195415

Bug: Touch Screen - Top bar setup widgets - can't get back

Earning my keep, breaking stuff...

1. Top bar
2. Screens setup
3. Setup widgets
4. Select any of four boxes
5. Select widget
6. Select any widget
7. Press some other part of of the screen other than a top bar widget
8. Press return until the cows come home with no luck
9. Press on one of the top bar widget boxes
10. Press away from the options
11. Pressing return will now work

Showing stuff is working, and not working... with a interruption in the middle... first 'crash' I've had so far... early days...
https://youtu.be/DZvhjHDHnAA

There may appears to be a similar state related bug... otherwise I'd open another issue. At step 3, you can still get into any of other menus by pressing the top bar (other than a widget box), meaning you can go into the menus whilst in edit mode...

Sorry for the off-angle video... was looking at the Tx screen, not the phone...
https://youtu.be/ABwXsHME0fY

tx16s-edgetx-60726891, #85ebb168

Enhancement: Bootloader progress bar outline colour

The bootloader screen is dark, and the outline for the progress bar is black... basically hard to see on a colour_lcd screen TX. Maybe the outline could be a different colour? Grey, or maybe even white, given there is other white text?

I would make a PR with a colour change, but after going to /radio/src/targets/common/arm/stm32/bootloader/ I couldn't find where anything related to the progress bar actually was! lol

Introduce a 'normal' empty page to allow for telemetry scripts.

As a first move to killing widgets, create an option to make any screen you define on a colour radio to be a script screen, with only the script name as option.

All key and touch events should be available, even page, menu and system buttons.

Create a proper 'change event' function that is executed from the script BEFORE the main GUI uses the event.

It's up to the scripters to make sure they don't lock up the GUI.

COME ON, a little confidence in the 'lua people'.

(Just don't allow an autostart on that screen, or better, have an escape sequence to boot into the screen setup without running the scripts/widgets first by having menu pushed on startup)