IMPORTANT: Timing issue on CPPM output of FrSky recievers

Love the 9x? Use FRSky? Post your questions and answers here!
Post Reply
User avatar
Kilrah
Posts: 11108
Joined: Sat Feb 18, 2012 6:56 pm
Country: Switzerland

IMPORTANT: Timing issue on CPPM output of FrSky recievers

Post by Kilrah »

I've already mentioned that, but it was "lost" in the middle of a discussion and would deserve its own thread (plus I need to link someone to it ;) )

The CPPM output on all equipped FrSky D-series receivers (D8RSP, D4FR, D4RII) has a serious timing issue that can result in loss of control when used to fly an aircraft. The following was sent in an email to FrSky some time ago. They replied they already knew about that, but they said they hadn't been able to solve it yet and what they recommend at this point is "only use max 6 channels". Meh.

The problem is that the 18ms frame period they chose to base their PPM output on on the receiver side is too short to fit 8 channels holding an average value of more than 1.67ms and an “end of frame” sync pulse that is long enough.

Image
When channel values are short enough like above, no problem, the PPM signal is fine, we've got all channels and a long enough sync pulse. However, if channel values get bigger, the gap between frames (sync pulse) becomes too small, and nonexistant when channels all reach their maximum values.

Image
When all 8 channels are at maximum values (2.016ms) like above, the rest of the “sync pulse” is down to 1.87ms, which would be a valid channel.
PPM output is usually used for multicopter controller boards, gimbal systems, autopilots, OSDs and other flight control devices to avoid having to install multiple patch cables between the receiver and said board. An aircraft controller that would receive this PPM signal would lose sync, resulting in a loss of control, which is of course a serious issue. It's a "nasty" issue as it can work like a charm most of the time, then happen "randomly" in flight whenever the channel positions happen to leave a sync pulse that is too short for the connected device to consider it valid, for example if you toggle a switch that controls a channel from -100% to +100% and/or give larger stick inputs than usual.

From what I have been able to determine by measuring the signal of radios from various R/C manufacturers, it seems accepted that the minimum sync pulse width should be 4.6ms (Futaba captures below, Graupner is same). The second image is Futaba in 12CH PPM mode, which uses a variable PPM frame length, normally the usual 22ms when possible, but that grows when needed to maintain those 4.6ms for the sync pulse.

Image Image

This means that for 8 channels with extended limits, the PPM frame rate should be no shorter than (8*2.1)+4.6 = 21.4ms. Futaba and JR/Graupner both use 22ms. Just for info, I also checked what an FrSky TX module required, and found out that the DJT will stop working if the PPM signal from the radio has a sync pulse shorter than 3.8ms.

So, until FrSky solves that issue and adapt frame length, the CPPM output is NOT safe to use with 8 channels, it’s important to only send at most 6 channels to the TX module (set *9x to PPM 6CH) if one wants to use the CPPM with no risk (6*2.1 + 4.6 = 17.2ms).

User avatar
Crucial
Posts: 581
Joined: Tue Dec 27, 2011 6:56 pm
Country: -
Location: SE WI, USA

Re: IMPORTANT: Timing issue on CPPM output of FrSky reciever

Post by Crucial »

Thanks for this. I just finished building a quad copter and am using the d4fr
User avatar
Peter
Posts: 232
Joined: Thu Dec 29, 2011 8:45 pm
Country: -
Location: Zuid-Holland

Re: IMPORTANT: Timing issue on CPPM output of FrSky reciever

Post by Peter »

Thanks for the great explanation!
I heard of the problem by a frsky employee. He stated that I should use 6 channels with cppm.
It was a reaction on a different problem with the d4r-II: viewtopic.php?f=52&t=916#p13511
But as I understand now, the solution was probably unrelated to my problem. Or can you explain?
jonlowe
Posts: 51
Joined: Fri Apr 20, 2012 2:31 pm
Country: -

Re: IMPORTANT: Timing issue on CPPM output of FrSky reciever

Post by jonlowe »

Ok, just to make sure I understand all of this, as long as I am NOT using CPPM output, it is safe to use 7 or 8 normal channels on a7 or 8 channel receiver respectively, correct? This ONLY affects the CPPM output?

Thanks in advance for the claification.

Jon
User avatar
Kilrah
Posts: 11108
Joined: Sat Feb 18, 2012 6:56 pm
Country: Switzerland

Re: IMPORTANT: Timing issue on CPPM output of FrSky reciever

Post by Kilrah »

Yep, only CPPM output.

Peter, your problem seems unrelated indeed. No idea where that could come from.

User avatar
GrootWitbaas
Posts: 358
Joined: Tue Dec 27, 2011 8:57 pm
Country: -
Location: Germany

Re: IMPORTANT: Timing issue on CPPM output of FrSky reciever

Post by GrootWitbaas »

So I have been "missing in action" for some time ....life happens ...but now I am almost back so here goes:
I have tested before with 8ch and limiting the channels to 74% and in this case 8 channels can fit in the 6ch space, with no extended limits. This is my current work around for the problem, but make sure to test every thing on the bench 1st. move all 8 ch to full and make sure every thing is still stable. I wanted to use the last 2 channels for aux switching on a quad, and made the switch channels only use 50% and adjusting my flight controller accordingly.
Also some feedback I had from TC was that he has never seen this using stock firmware ....I haven't tested this myself ....but if someone has a radio with stock firmware and want to test feel free to do so.
I have also mentioned this before somewhere else, but did not want to hijack the thread :D
General trouble maker and wannabee Dev
wilco1967
Posts: 33
Joined: Tue Dec 27, 2011 8:20 pm
Country: -
Location: Winterswijk

Re: IMPORTANT: Timing issue on CPPM output of FrSky reciever

Post by wilco1967 »

Hi Kilrah,

I don't have proper test equipment, but tried to replicate what your saying with my MultiWii quad and the GUI (where I can see all 8 channels).
I'm using a ER9X equipped 9x radio, and D4FR receiver.

I have 4 switches configured for Aux1..4), which could all be at +100% (2000 uS in MultiWii Gui).
When I have 4 switches all at +100%, throttle at 100%, (yaw at 0% (1500) and then give pitch or roll, I notice the MULTIWII going into error at around 1900 uS. The MultiWii led's start blinking, cycle time goes negative (overrun), and channels readings all over the place
However, the receiver led still solid on (that may not mean anything).

In ER9x, you can increase PPM FrLen from default 22.5 all the way up to 32.5 mSec). If I understand correctly, that would give more place to include all 8 channels without exceeding the timeframe.
However, it does not seem to change anything on the MultiWii .... It will go into fault at the same moment (around 1900 uS on the pitch / roll channel).

With the four aux channels (5-8) on 1500 instead of 2000, it STILL happens at the same moment...... The frame length would be significantly below the max then.... It STILL goes into error roughly at the same moment

So with my limited understanding, I would say, what I am seeing, is a MultiWii issue, more than a FrSky issue....

Not sure if this is the same as you are wittnesing, but seems related.... Worrying nevertheless....
Never encountered any problem in flight though... normally never have to throw the sticks all in the corner (I don't fly like warthox...).

P.S. Is the frame length determined by the transmitter software (Er9X in my case), or by the FrSky module ? (or both)...
User avatar
Kilrah
Posts: 11108
Joined: Sat Feb 18, 2012 6:56 pm
Country: Switzerland

Re: IMPORTANT: Timing issue on CPPM output of FrSky reciever

Post by Kilrah »

wilco1967 wrote:In ER9x, you can increase PPM FrLen from default 22.5 all the way up to 32.5 mSec). If I understand correctly, that would give more place to include all 8 channels without exceeding the timeframe.
Unfortunately not. FrSky modules don't care about the rate they receive their PPM input at, they always work with their own 9ms timing cycle. You can feed it with a 40ms frame length, the receiver will still output PPM at 18ms frame length. That's the problem.

An FrSky TX module sends servo data out over RF every 9ms. Obviously that's currently useless, as they only receive new channel data every 22ms or so. So they will jsut send the same stuff up 2 or 3 times in a row depending on how the input and output "windows" align. That's what causes the relatively long latency of the FrSky system.
FrSky have reused their internal timer for PPM generation on the receivers, but as 9ms is obviously not enough they send out a new frame every 2 cycles (18ms). They probably thought they could get away with it, but definitely not. I don't understand why they "can't fix it", all that would be needed, at least as a temporary fix, is to use 3 cycles. 27ms is no problem, OK it's slow, but at least it wouldn't be dangerous...
Then once they've sorted their act together, they could generate a PPM signal that's asynchronous. They manage to do that with the input on the TX module, so they should be able to implment it on the receiver :)
User avatar
jhsa
Posts: 19480
Joined: Tue Dec 27, 2011 5:13 pm
Country: Germany

Re: IMPORTANT: Timing issue on CPPM output of FrSky reciever

Post by jhsa »

can someone please tell them? probably agtain? and again? and again? maybe then they listen.. I would nag them but don't know what to say ;) :mrgreen:
My er9x/Ersky9x/eepskye Video Tutorials
https://www.youtube.com/playlist?list=PL5uJhoD7sAKidZmkhMpYpp_qcuIqJXhb9

Donate to Er9x/Ersky9x:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=YHX43JR3J7XGW

Post Reply

Return to “The FRSKY Forum”