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.
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.
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.
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).
IMPORTANT: Timing issue on CPPM output of FrSky recievers
Re: IMPORTANT: Timing issue on CPPM output of FrSky reciever
Thanks for this. I just finished building a quad copter and am using the d4fr
Re: IMPORTANT: Timing issue on CPPM output of FrSky reciever
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?
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?
Re: IMPORTANT: Timing issue on CPPM output of FrSky reciever
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
Thanks in advance for the claification.
Jon
Re: IMPORTANT: Timing issue on CPPM output of FrSky reciever
Yep, only CPPM output.
Peter, your problem seems unrelated indeed. No idea where that could come from.
Peter, your problem seems unrelated indeed. No idea where that could come from.
- GrootWitbaas
- Posts: 358
- Joined: Tue Dec 27, 2011 8:57 pm
- Country: -
- Location: Germany
Re: IMPORTANT: Timing issue on CPPM output of FrSky reciever
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
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
General trouble maker and wannabee Dev
Re: IMPORTANT: Timing issue on CPPM output of FrSky reciever
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)...
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)...
Re: IMPORTANT: Timing issue on CPPM output of FrSky reciever
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.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.
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
Re: IMPORTANT: Timing issue on CPPM output of FrSky reciever
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
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
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