Basic RC Theory…and I Mean REALLY Basic!
OK, right off the bat, this isn’t going to be an in depth annotated scholarly study of radio control theory and practices. There are many sites out there that will help you with that. We’ll limit our discussion to 2.4GHz as it’s generally applied to the FrSky and OpenTX model. What we’re doing as much as anything is building vocabulary so that when you run across terms such as “protocol”, “frame length”, or “latency”, you might have an idea of what’s being discussed.
As we move through the module, you’ll see various terms in the discussion highlighted as a link. The meaning of these terms will be found in the Glossary. The definitions will be simple and generalized. There will probably be special cases or exemptions to every one of them.
The Real, Real Basics
In the simplest of terms:
- The most basic system requires a transmitter that creates the radio signal containing the information you wish to transmit, a receiver for translating that signal at the other end, and servos to act on the receiver output.
- This signal follows a specific set of rules called a “protocol.”
- The signal is first generated by the transmitter, detected by the receiver, translated/decoded, and finally turned into an output that is fed to your servos.
- The servo changes position to reflect the value of the signal from the receiver. This, in turn, changes the position of whatever you have it hooked to. Hence, the elevator moves when the signal tells the elevator servo to change position, or the ailerons deflect when the aileron servo(s) are activated.
- The signals to specific servos are kept separate through the use of channels.
That’s all there is to it. Simple, huh? Now, let’s take it just a step further.
Moving On…Just a bit
Of course, there’s more to it:
- Your transmitter actually uses two different packages of computer code. Unfortunately, both of them are normally referred to as firmware. The transmitter firmware generates the signal to be transmitted to the receiver. The system firmware tells the transmitter firmware what to do. The transmitter firmware is normally provided by the manufacturer of the transmitter. You may be able to upgrade your firmware with an new improved version from your manufacturer. The system firmware in this case is represented by OpenTX, either the original OpenTX fork from FrSky that was shipped installed on the transmitter, or the OpenTX fork supplied by the independent development team. Below is an illustration of how the transmitter and system firmware fit together.
- When you add a mix, set up dual-rates, or make almost any other change to the basic setup of your model, what you’re actually doing is telling the system firmware what to tell the transmitter firmware.
- With OpenTX, the individual model settings (name, trims, etc.) are stored in an EEPROM file. The firmware uses the settings in the EEPROM to format the output of the transmitter firmware.
- The EEPROM can be read from the transmitter or updated as needed using OpenTX Companion.
- A complete set of data for a model is called a “frame”. The length of the frame varies, but standard frame length is approximately 22 milliseconds.
- A frame contains all of the information needed to fly your airplane. As you move the sticks, this information changes. The changes are transmitted to your airplane in the next frame and take place after the frame is acted upon by the receiver and servos.
- There is a short time delay between the time your make a change and when it is acted upon. This delay is called latency.
- Adding functions such as telemetry increases the length of the frame, thereby decreasing the number of times per second that the servo settings are refreshed. This can be a problem in some cases, especially for those who fly helicopters and 3D.
OK, it looks like we’re ready to move on and see if we can’t sort out what all the fuss is about with OpenTX Companion and how it fits with OpenTX (the firmware).