More about Inputs

Mike Shellim: 14 Oct 2019
Updated: 28 May 2020

In this article, we'll take a closer look at Inputs.

Like raw sources, Inputs represent sticks, knobs and sliders. The main difference is that inputs have weight and expo built in. Inputs are typically used for aileron, elevator and rudder channels.

Overview of Inputs

Inputs are managed in the INPUTS menu. There are 32 inputs available, each identified by a label of the form [I]xxx.

By default, inputs are blank. In order to do anything useful, an input must have one or more lines specifying source, weight, and diff/expo. Source is the raw control (stick, knob etc.) on which the input is based. Weight is the rate as a percentage of the raw control.

An input line can be activated or deactivated through the modes (flight modes) and switch fields. If both flight modes and a switch are specified, both must be satisfied for the input line to be active.

System created inputs

When you create a new model, OpenTx automatically sets up four inputs [I]Ail, [I]Ele, [I]Thr, [I]Rud (the other 28 inputs remain blank).

OpenTx also creates four mixers which use the inputs as sources:

You can edit - or delete - any of these inputs and mixers.

When using an input as the source of a mixer, it's good practice to leave the mixer weight at the default 100%.

Using inputs to create rate switches

Inputs may be have more than one line, each dedicated to a specific switch and/or flight mode. You can use this to implement dual/triple rates, or to set rates automatically according to the active flight mode.

Here's an example of triple rates for aileron, using switch SB:

How it works:

If OpenTx reaches the end of the list without finding a match, the input will not function at all! You can avoid this by making the last line match any condition, by leaving the switch field empty and ticking all flight modes.

Here's a second example with individual rates for flight modes 0,1, and 2. The last line has all flight modes ticked, so will apply to all other flight modes not covered in the previous lines:

By convention, we name the last line 'CATCHALL', to indicate that it 'catches' all the conditions which are not met by the preceding lines:


Defensive programming using a 'CATCHALL' line.

Having a catchall line might seem like overkill, so in this section, I'll show how a simple error can have serious consequences, and how a catchall can guard against it.

So let's repeat the opening example, but with an error in the last line; instead of SB, I've typed 'SA' by mistake:


Ail Weight(+33%) Switch(SB↑)

Ail Weight(+66%) Switch(SB-)

Ail Weight(+100%) Switch(SA↓) -- mistake: SA instead of SB!!!

The effect of this is subtle! The intention is to activate the last line when SB is down. If SA is down, this will indeed be the case. But if SA is up, the last line will not be matched, and the aileron will freeze. So whether or not you crash will depend on the position of SA...

A 'catchall' line protects against such errors by guaranteeing a match even if there are errors in the previous lines. The rate my not be what you expect, but at least the aileron will continue to function!

How to make a CATCHALL line

To create a catchall line:

Using a catchall as a default

A catchall line can also function as a default setting to simpify the input list. So in the example below, SB-up corresponds to low rate, all other positions fall through to the catchall line for a 50% rate.


Ail Weight(+33%) Switch(SB↑)

Ail Weight(+50%)