This post is more of an answer to than a question about “why my ppm goes fritz”. Well, I'm going to take a roundabout approach to the issue, and I hope those holding a quadcopter remote control in their hands will learn a good thing.

Most RC hobbyists are well aware that analogous servos are PWM-guided. The PWM (pulse width modulation) technique is based on encoding information as pulsing waveforms. For example, a servo receives coded signals, which express rotational angle. Over years, 50Hz PWM with pulse width ranging from 1,000µs to 2,000µs has become a kind of standard for the aforementioned analogous devices. This is how it works with an ordinary servo:

Servo turning angle -60

Servo turning angle 0 (original position)

Servo turning angle 60.

This is the signal transmitted to the receiver via each channel.

It should also be noted that devices from different manufacturers with different setup parameters may have pulse length varying within certain limits. This contributes to a wider range of control signals. Thus, most flight controllers work correctly at pulse length ranging from 800 to 2,200µs.

PPM (pulse position modulation) coding is another technique that is widely used in onboard and ground systems. It is the simplest algorithm for encoding control signals, which come in from different channels, into a single one. This technique is as old as the sea and as simple as rolling off a log: pulses from several channels are packed into a frame and form a succession.

Inside a frame, the channels are divided by pauses at a frequency of 100-400µs. A so called synchro-pulse is used to determine the frame’s beginning. Its length should significantly exceed the maximal length of the channel pulse. Usually, this value amounts to >2,500µs. Because frames are communicated in cycles, each synchro-pause is followed by a pulse from Channel 1. Next come pulses from Channel 2, Channel 3, etc…

A Turnigy 9X(R) external module can be set up to PPM, as can a FrSky D8XP receiver’s output channel.

The latter has a default frame length of 18ms. However, you can update the receiver up to 27ms. After connecting it to my tester I figured out the following parameters:

1. Frame length - 18ms
2. The length of the pause between the channels - around 350µs
3. Number of channels within a frame - 8.

This is exactly what a potential problem lies in. To solve it, FrSky developed an update with frame length 27ms. The problem is:

Let’s suppose that each channel receives minimal parameters. The length of the channel pulse is 1,000µs.
000x8 = 8,000µs; 18,000 – 8,000 = 10,000µs – the length of the synchro-pause. It rightfully exceeds 2,500µs by far.

Now let’s suppose that each channel receives maximal parameters with a channel pulse length of 2,000µs . Let’s go…
2,000 x 8 = 16,000µs. Synchro-pause: 18,000 – 16,000 = 2,000µs. Oops… The pulse length is less than 2,500µs and it equals channel length. Now guess what – frames will merge together, and there will be no flight controller capable of detecting a pulse of Channel 1 or, consequently, any other channel. The result is total loss of control and a tailspin.

The update will solve this problem. Once you increase frame length up to 27ms, all 8 channels fit in there quite well. Let’s see what happens when the worst comes to worst (every channel receives a 2,200µs pulse):

27,000 - 2,200 x 8 = 9,400µs.

The length of the synchro-pause is well over 2,500µs. The result is stable work.

Now a bit of information about Turnigy9XR. A friend of mine bought a new FrSky XJT kit. It lies idle at home, and I have no time to study it. And the transmitter module was set up to transmit 16 channels. Finally, he came around to me and said that the module was unstable. We looked through the Turnigy’s settings and noticed a whole bunch of mixed modes, which we didn't want at all. However, that was the signal setup for a transmitter module.

Signal type – PPM
Number of channels – 16
Frame length – 32.5ms
Length of channel pause – 200µs

A simple calculation shows that the informational component of all sixteen channels requires a maximum of 32,000µs. The frame length exceeds the resulting value by only 500µs, which is not enough to provide a due synchro-pause. Therefore, this mode creates no basis for stable work. This is also true of OrangeRx DSM2/DSMX, which has the same issue.

Now let’s see how many channels it is possible to transmit using PPM with certain characteristics (frame - 32.5ms; pause – 200µs).

2,000µs (max. channel pause length) + 200µs (channel pause) = 2,200µs per channel.
32,500µs – 2,500µs (min. Synchro-pause length) – 200µs (a pause preceding Channel 1) = 29,800µs
29,800µs / 2,200µs = 13 channels (Turnigy has 12 or 14 channels)

Transmission of larger numbers of channels disrupts stability.

I’ve tested the OrangeRX DSM2/DSMX transmitter module. It communicates 12 channels quite easily and steadily. Well, what about FrSky XJT… how do we use it to the fullest?

Unlike the Orange transmitter module, XJT accepts both PPM and PXX (this requires more complicated PCM-coding). I won’t enlarge upon its structure, but I can say it can communicate 16 channels. This is just the solution: likewise, the ER9X update for Turnigy syncs with a transmitter module via PXX.


Manufacturers do not specify the number of channels for their PPM devices. The only thing they mention is frame length. Meanwhile, the information written above demonstrates the importance of the characteristic. If you use PPM, do not blindly expect it to comprise ALL channels, which you want to communicate to your copter. Just a bit of arithmetic will guarantee your drone’s safety and prevent unplanned expenses.

This is the translated version. You can read the original Russian article here.