Introduction to RC controller programming


If you’ve been using controllers that came with the aircraft - well, most of them anyway - to fly remote controlled aircraft and recently bought a hobby-grade controller, you’re probably swimming in terminology and concepts that are completely new to you, no matter how long you’ve been doing this. Your old controllers had few if any settings, and now you’ve got curves and exponentials and dual rates and people talking about “programming” the things! Your old controller may well have had a few buttons and no switches, and you seemingly have switches everywhere and no or few buttons, and no idea what any of this has to do with flying. This document should help you get to a basic understanding of  what’s going on with a programmable controller, and enough information about programming it to improve on your ready-to-fly (RTF) controllers, at least with deviationTx.

Why deviationTx?

deviationTx is unique - or at least nearly so - in being able to  control many popular aircraft that could otherwise only be used with the controller they shipped with. Since any good controller  will store multiple models and let you switch between them, this means you can control a heterogeneous fleet with one controller. Further, since it’s much more flexible, you can correct issues that the included controller may have, sometimes making an aircraft that’s hard to fly because it’s too responsive or too sluggish a great flyer
deviationTx also has two different GUIs. The standard GUI is similar to proprietary firmware on programmable controllers. The advanced GUI provides direct access to the internal workings of  the deviationTx mixer, making it incredibly powerful. It also makes it much harder to set up, because you have to know how the desired behavior of the aircraft controls is expressed as channel output values, and then how to use the deviationTx mixers to create those outputs. In this way, it is similar to OpenTx on the Taranis and other open source firmware available for inexpensive controllers like the HobbyKing TH9X.

What’s in this document

The goal is to introduce you to the concepts needed to make proper use of these advanced controllers, including the things that are unique to the deviationTx advanced GUI. The standard GUI will be used at first, even though it is rather limited even compared to proprietary firmware, because it might be useful for other controllers, and provides a gentle introduction to controller programming.

Controllers vs. Transmitters

In a lot of documentation and forums, you’ll see the controller called a transmitter. This is an oddity in the hobby, as some controllers have modules that can be added that are also called transmitters. Controller is understood by the general public and less ambiguous, so I’m going to use it here.

Intended audience for this document

This document is intended for new RC pilots. While I’ll try and accommodate someone who’s never flown before, you’ll be better off if you’ve used a RTF controller a bit before tackling this, so you’ll have some idea of what the controls do.

Overview of a controller

An aircraft is a complicated device, and remote control ones are even more so - as they have to deal with translating radio instructions into control manipulations. This is done via channels, though that’s a bit misleading. When you see an RC transmitter, receiver or controller advertised as “4 channels”, “6 channels” or whatever, this refers to the number of devices on the aircraft that can be controlled with that equipment. This is obvious when you see references to a “3 channel” aircraft, which typically has throttle, rudder, and elevator. A “four channel” aircraft will add ailerons. More channels get used for things like flaps, gear, lights and on more advanced aircraft flight modes.
The goal of programming a controller is to get a specific behavior for the outputs of the transmitter, which are the inputs of the model you are controlling. So let’s go over those first.


The inputs include all the controls on the controller, as well as some internal values. I’m not going to describe the physical controls in detail, as they vary between controller models, and you should already be familiar with them.


The two control that dominate an aircraft controller are the sticks. They are normally used to control the main aircraft controls: aileron, elevator, throttle and rudder. You’ll sometimes see the aileron and elevator controls referred to as cyclics, and - if they are on the same stick - the stick that controls them as the cyclic stick. These are analog inputs, and the input values represent a percentage of the full value, and so go from -100% to 100% in deviationTx. Other controller firmware might use 0% to 100%, possibly only for the throttle.
Each stick also has a pair of trims, each of which is two buttons beside or below the stick. On most controllers, they just adjust the value from that stick in each direction a bit so you get the behavior you want when it’s centered. deviationTx lets you use them for other things, but that’s an advanced usage not covered here.

Knobs and sliders and dials

Some advanced controllers have more analog inputs in the form of knobs, dials or sliders. These are handled the same way as the sticks when programming the controller, and are typically used for things like pointing a camera or the flaps on an aircraft.

Switches and buttons

Buttons and switches are two different types of inputs that let you switch between multiple different states. Sometimes the states are in the aircraft, and sometimes they are in the controller. Some are used to control the gear, lights and flaps and other things. And advanced pilots will be wanting to point out that flaps should be on an analog control, not a switch!  Others are used to change the behavior of the controller itself. And setting that up is a large part of what programming the controller is about.
Switches move between two or three positions, though sometimes more on advanced controllers. Each position corresponds to a state, they stay in position when you put them there. That you can tell what position they are in by feel and sight is why they are preferred in advanced controllers.
Buttons are two-position switches that reset to the original position when you let them go. Some buttons are physically switches and vice versa, but for my purposes buttons reset and switches don’t. Buttons are either momentary or toggle . Momentary buttons are either on or off, and only on while pressed. Toggle buttons change state when you press them, switching between states on every press, and can have arbitrarily many states. Obviously, you can’t tell what state they are in from the button itself. They are less expensive than switches, which is why they get used in inexpensive controllers.
Buttons and switches might be handled the same way in your software, or might not. If they are, then which you use will depend on whether or not you want that automatic reset. If they aren’t like switches, then they might not be programmable, or might be used to create some kind of virtual switch. I’m not going to discuss that, but just refer to them all as switches.


The channels output by the radio are how you control your aircraft. Setting those up to behave the way you want is the goal of programming the controller. For a modern aircraft, this can get very complicated, with some inputs controlling different things at different times. If someone has figured out how to provide that kind of flexibility in a simple manner, I have yet to see it.


The channels  all hold analog values. Again, those might go from -100% to 100% or 0% to 100%. These are best thought of as percentages, so they range from full off to full on. This will come up again when we get around to doing calculations with them.
Channels controlled by switches usually use 100% for on and -100% for off, or 100%, 0% and -100% for a three-position switch. Channels that need more values than that but aren’t fully analog will depend on the device being controlled, and are beyond the scope of this tutorial.


As noted, the channel count corresponds to the number of different devices you can control on the aircraft. The most common ones are the same as the four stick inputs - aileron, elevator, throttle and rudder, which is where the sticks get their names. Some aircraft may be missing ailerons, and gliders normally don’t have a throttle. I’m only going to talk about those four, since other analog devices are programmed the same way. Beyond them, nothing is standard.
I am going to talk about a flight mode channel, as that’s common on most modern RC aircraft. It is often the most complicated of the things controlled by a switch, so once you know how to set it up, you’ll know how to set up most of the others. It’s an input to the aircraft, and changes how the aircraft behaves, enabling auto-level or various holds on advanced aircraft, or flips on toy-grade aircraft, and headless mode or return-to-home on both. If you’re moving from toy-grade aircraft to hobby-grade aircraft, the latter should only have headless and return-to-home modes if they have GPS hardware, in which case those features work, as opposed to being a good way to lose your aircraft if it doesn’t have GPS hardware.
Some controllers also have the notion of a “flight mode”, which is controlled by switches and can then be used to change how the controller behaves like a multi-valued switch. These aren’t the same thing as an aircraft flight mode, so don’t be confused by them.
The one gotcha here is that you have to make sure the right channels from your controller are going to the right device. What is correct changes depending on the protocol and aircraft. For most proprietary controller software, all you can do is change the connections in the aircraft, as they only control aircraft that implement their protocols, which should all use the same setup. If this setup is wrong and you can’t change it in the aircraft, you’re stuck. With deviationTx and similar controllers, connecting channels to the aircraft devices is part of the controller programming, and there’s even a way to rearrange the output channels.

Controller configuration

There are a couple of things that may need to be configured on your controller in order for it to work properly. They affect how the inputs are read, which can cause both misbehaving models and unexpected alarms. Better firmware - like deviationTx - have settings that let you check to make sure the throttle channel is zero before they connect to a model, either at power on or when you change models. This keeps the model from taking off unexpectedly when you connect. If the values are coming from the wrong stick, or aren’t being read properly, you’ll get the warning inappropriately.

Controller Mode

You may have already dealt with this, as some RTF models can be purchased with either a mode 1 or a mode 2 controller. And some RTF controllers can be converted between various modes. What each stick motion controls varies between the modes, though the throttle and elevator are vertical in all modes. If you don’t have these right, then your stick motions will produce unexpected results, and the throttle warning may wind up  applying to the elevator.
Mode 1 has the elevator and rudder on the left stick and throttle and aileron on the right stick. It is popular in Europe.
Mode 2 has the throttle and rudder on the left stick, and aileron and elevator on the right stick, swapping the elevator and throttle controls from mode 2. It is popular in North America.
Mode 3 swaps the sticks from Mode 2, and isn’t very popular.
Mode 4 swaps the sticks from mode 1, and has some popularity for fixed wing aerobatics.

So which should you use? If you’re already using a mode, stay with that one. If you’re flying with a friend or club, you should all use the same mode. Other than that, there are good arguments for all of them.

Controller calibration

deviationTx - and other open source firmware - generally needs to have all the analog inputs calibrated before you try and use the controller. This involves letting the controller read the centered value from those inputs as well as the low and high values, so it can properly translate those values into the 100% to -100% range used when you program it.
If this isn’t right, models that need initialization with extreme stick movement can fail to init properly, and modern flight controller features like stabilization and position lock may misbehave.

Single source curves

The simplest possible translation from inputs to output is just to copy it directly from one to the other, which is a 1-1 curve. For all practical  purposes, this is what most RTF controllers do. On a programmable controller, you can do a lot better.  On a good one, you will have a graphical representation of how the translation is done. For this tutorial, I’m going to be using the deviationTx emulator for the Devo 12. If you’re using OpenTx, this is similar to the companion application, except that deviationTx shows the same imagery you get on the controller in the emulator.
I’m using the emulator because that shows the state of all the inputs and output channels, and the 12 because that’s got the biggest screen of the color controllers, so it’s pretty and easy to see. If you’re using a different controller running deviationTx, you can download an emulator for it to run on Windows so you can test models on your desktop.  If you would like an emulator for another operating system, ask for it in the deviationTx forums. See the last chapter of the online manuals at for instructions on using these.
I’m going to use the standard GUI for deviationTx for this section, even though I don’t recommend using it for anything but collective pitch helicopters that still use a flybar. It has features that don’t apply to things that aren’t helicopters, and is missing features that you usually want for aircraft that aren’t helicopters that don’t have a flybar. However, programming it is similar to many proprietary systems, and the concepts needed for it will carry over to the advanced gui.
This is the emulator window in question:

The controller image is on the left, and is the page for setting the throttle curve in the standard GUI. The upper right shows all the inputs. The bottom shows the 12 output channels this model has. The big black box in the controller image is the curve display, which tells you how the throttle stick is translated into the mixer's output value. 
In this image, the analog inputs are outlined in red. In particular, the first four are, in order, the RIGHT Horizontal stick, the LEFT Vertical stick, which is the throttle in mode 2, the RIGHT Vertical stick and the LEFT Horizontal stick followed by the AUXiliary inputs on this controller. You’ll notice that the throttle has a value of -60.00%, and you can see that the Ch1 output is also at -60.00%, and there’s a blue dot on the line in the curve box at about that point.

Dual Rates

Dual rates is also something you might be familiar with.  Many of the RTF controllers have a button that cycles you through various rates: 40%, 60%, 100%, etc. Or maybe Beginner mode, Intermediate mode and Expert mode. A lower rate makes the aircraft more docile, since it won’t respond as fast, which presumably means it’s easier to fly. They are the same thing, and much more programmable with a good controller.
For the deviationTx standard GUI, this is handled on the D/R & Expo page. While these two are often configured in the same place and referred to as a pair, they have very little to do with each other.  Configuring them in one spot is a convenience.  The image of that controller page is shown below.
Here we see three curve boxes for the three flight modes, set to values of 100%, 70% and 50% as shown in the first row of values. You’ll note the title of the page says FMODE, which tells us the name of the switch that selects between the three modes shown. On the right I’ve boxed the flight mode switch input setting in red.
Switches in deviationTx are handled differently from most other firmware. Instead of a switch being a source with values of -100% and +100%, and 0% if it’s a three-position switch, it is two or three inputs whose names match the positions: FMODE0, FMODE1 and FMODE2 since FMODE is a three-position switch. Each of these has it’s own value, either 100% if the FMODE switch is in that position or -100% otherwise. The three positions of the switch correspond to the three curves, from left to right.
The Src selector is set to AIL, which is the right vertical stick here. That is at 100%, and the blue dot on all three boxes is on the far right. You’ll note that the height of the dot in each box is different, which corresponds to the output in that mode. In this case, FMODE1 is at 100% and the other two at -100%, so we’re in FMODE1, which is the middle curve. And sure enough, Ch2 is at 70%.


Like dual rates, expo - which is short for exponential, because the curve has an exponential component added to it - is also used to control how responsive the craft is, but without changing the endpoints. Here we see the D/R & Expo page with some expo added to the first and last curves.
Now the first element in the second row of boxes is 35%, not LIN. This causes the curve to be less sensitive near the center, but still going to ±100% at the ends. So the near 0% output value won’t change as fast as it does when the curve is linear, roughly matching the 70% rate. This means that near the center value, it responds like a 70% rate, but you still have the full range of values available should you need it, presumably giving you the best of both worlds.  I happen to like a 35% expo high rate and a 70% linear low rate, but that’s just me.  The last curve has a negative expo value, and you can see that it’s much steeper near the center. This makes it more responsive near the center, without overdriving at the ends. This is here to illustrate what negative expo looks like, and I wouldn’t recommend you use a negative expo low rate.
One word of warning, though - different controllers interpret the sign of the expo differently. In deviationTx, positive expo means a flatter curve. In other controller firmware, it may mean a steeper curve.

A curve

Now we go back to the throttle curve setup just to show you how flexible this translation can be.
This is a typical throttle curve for a fuel-powered helicopter in a 3d flight mode. The V shape means that the throttle output will be high at both the bottom and top of the stick motion, and lower in the center. You can see that the throttle is at -60% and the output is at 62%. As an aside, this is used for fuel-powered collective pitch helicopters because fuel engines tend to drop their RPM as the load increases. The ends of the throttle curve will correspond to pitch settings further from flat and hence an increased load, so we have to compensate for that. Electric engines don’t share that property, so the appropriate pitch curve is a flat line at 70%.
And with that, we’ve pretty much reached the limits of the deviationTx standard GUI. We could talk about switch assignments and gyro states and the like, but they aren’t relevant except for helicopters, and the last thing I want to talk about can’t be done in the standard GUI.


A mixer is something that mixes multiple input sources in some way. The deviationTx standard GUI doesn’t have any mixing capability. Proprietary firmware tends to have relatively simple mixers, allowing you to add a second input to an output channel after the input value goes through the curve. More complex things - flaperon mixing and the like - is handled by the firmware knowing how to deal with them. The deviationTx’s advanced GUI gives you access to the mechanics of the mixer, allowing you to do some incredibly complex things - but require you to know what the mixes need to be. They are beyond the scope of this tutorial.

A simple switch

Besides the four analog sticks, it’s common to have one - or more - inputs on switches. You could abuse the pitch or gyroscope channels in the standard GUI for those, but that’s more likely to be confusing than trying to use the advanced GUI.
So we’ll introduce the concept of mixers with a simple switch, which only has one input. This might be a return-to-home channel or to enable stabilization or headless mode or even to control a camera or turn on the lights. Here’s what a simple mix looks like in the advanced GUI:
Besides that big curve box - with the funny stair-step curve in it - you’ll notice the following elements. I’ve added red numbers to the imager to help you find them.
  1. The mix type of Simple in the upper left corner
  2. The input source (GEAR1).
  3. The curve type (Min/Max).
  4. The scale (100%).
  5. An offset (0).
Here GEAR1 is 100%, and the blue dot is in the upper right and the output is 100%. If you moved the GEAR switch to 0, then GEAR1 would go to -100% and the dot to the far left and the output to -100%. I tend to use Min/Maxcurves for switches to minimize the possibility of the device seeing an intermediate value. The scale setting we saw in the rates section. The value after translation via the curve is multiplied by this percentage, and then the offset is added to get the value of this mixer.  If you wanted this to switch between  0% and 100% instead of -100% and 100%, you’d use a scale of 50% and an offset of 50%. So the -100% input would translate to -100% * 50%  + 50% to get 0% output, and the 100% input would be 100% * 50% + 50% to get 100% output.

A multiple input mix

It’s fairly common to want a three-value switch of -100%, 0% and 100%. Proprietary firmware usually does this by just assigning that switch to a channel. deviationTx is a bit more complicated, but allows me to demonstrate mixing multiple inputs.
For this mix, we’re going to use two mixers. The first one is essentially the switch mix shown above, except the source is FMODE2. If you think about it, you should see that it has a value of 100% for FMODE2, and -100% for FMODE0 and FMODE1. This is right for FMODE0 and FMODE2, so we add a second mixer to fix FMODE1, which looks like:
This is similar to the above, but note the following:
  1. The mix type is now Complex, not Simple.
  2. There is a line listing the number of mixers (2), and which one is being shown (2).
  3. There is a line showing an input to activate the mixer (FMODE1), and how the value from the previous mixer is to be mixed with the value from this mixer (Replace).
The curve is set to Fixed, which means that this mixer always has  the scale value as it’s value. Since the Src is ignored, it’s value is None.  The switch is set to FMODE1, so when the FMODE switch is in positions 0 or 2 it’s value is -100% so this mixer isn’t active, and the value from the first mixer will be used. When the FMODE switch is in position 1 its value is 100%, so this mixer is active and will do what the Mux setting specifies and Replace the incoming value with the value of this mixer. Since that value is always 0%, we now get the 0% output we want for FMODE1
If you wanted to add values from sticks the way a proprietary controller would, you’d need to use a Mux of Add. Other options are available, but see the advanced tutorial mentioned in the next section for details on those.

Sticks vs. Sources

One critical addition here is the Switch setting. It's function - controlling whether or not a mixer is active - is normally restricted to a physical switch in proprietary firmware, hence the name. In deviationTx, it can be any valid source, not just one related to a physical switch.  This can get very confusing, so let's list the possible meanings for both terms.

Source can mean either  a value from an input on the controller or a mixer output, or the setting in a mixer that selects one of those values for input to the mixer curve. The context usually makes which you mean obvious.

Switch can mean any of a physical switch on the controller, one of the sources related to a physical switch, or the setting in a mixer that can disable the mixer, which selects from the same list of sourcesa s the mixer source. Not quite as clear, particularly those first two! Hopefully, knowing the possibilities will help you figure out which is being referred to.


I hope I’ve covered the basics of RC controllers. If you’re still confused and have more questions, try asking on I try and check it frequently, and there are lots of knowledgeable, helpful people there.
If you’d like to learn more about programming deviationTx, then check out the tutorial at