Developer

Why FRSky CPPM signal is so disappointing. [UPDATED]

3689479322?profile=original

[ Update at the end ]

You bought a brand new FRSky with 8 channel and a promise of a helpful PPM Sum output.

Be warned that you cannot use this with 8 channels. Only 6 channels could be used with some risks (only 5 for real safety). [Note #1 at the end] It's really disappointing.

Yes. FRSky's CPPM signal has a BIG problem: It has a period of only 18 milliseconds. What does that means? Here we go:

A PPM Sum signal usually has a period of 20ms. As each channel uses up to 2ms so you need 16ms to fully accommodate the data from 8 channels (8 * 2 = 16ms).

Now comes an important element: the Sync Pulse. It needs to be wider than all other ones  to indicate the start of a new PPM train. Any 8 channels system based on a 20ms has room for a 4ms pulse (16 + 4 = 20ms). Even with all the channels at 100% a system like that still gives you a perfect sync pulse.

 

3689479069?profile=original

That's the BIG problem with FRSKy CPPM. If you start using some switches and knobs you are pretty much risking to lose the sync on your autopilot. Because the sync pulse is squeezed until having the same size of any channel.

 

3689479378?profile=original

I hope they can fix that with a firmware update sooner, because I believe it's not acceptable.

Until that, you cannot use it on your autopilot without risks. [Note #1 below]

[ NOTE #1 ]

This is far away from the ideal, but there is a cheat to eliminate the risks when using just 6 channels by suppressing CH7 and CH8 from CPPM.

At least on a ER9X or ERSky9X radios there is this way:
By changing your model's setup to use a Proto PPM 6CH it will not output CH7 and CH8.
(The frame space (300uSec) though is just ignored. I did not see any changes.)
3689479086?profile=originalI've verified on Oscope. It works!!! The CPPM was outputed from RX without CH7 and CH8.
Is still a shame and disappointing using just 6 from 8 channels. But that seems to eliminate the risk.

[ NOTE #2 ]

Jani, from jDrones took this issue to FRSky's GM/CEO and got a response from them. They are now baking a solution to release a new firmware. Probably the new CPPM frame period would be 27ms (the next available number dictated by the hardware's clock division).

[ UPDATE ]

Yesterday (28th September)  Jani came up with a beta firmware from FRSky. It does output CPPM frames at 27ms. So far we have some positive feedback from DIYDrones dev team's tests. I'll not update this post anymore. A new post instead will show some results followed by a mini updating tutorial for those CPPM capable receivers. Stay tuned! ;)

[ UPDATE ]

This post shows how to fix it.

--Sandro

E-mail me when people leave their comments –

You need to be a member of diydrones to add comments!

Join diydrones

Comments

  • Sandro, I'm only testing with what the system actually gives me, I don't have an Oscope.  I'm playing with my radio, and using MP to look at what the APM is doing.  All I can say is that if I set Ch 8 permanently low, and then use 1000-1500 for Ch 7, it's almost impossible to get a lockup.  If Ch7 control works like this, then I'll be OK with it.  I can't imagine any conceivable way I'd ever max out the other 6 channels simultaneously.

    Or am I really missing something else important?

    I'm using a Futaba 9CAP, and I don't know if there's a way I can turn Ch 8 completely off?  I imagine that would cure the problem completely?

    Kevin, touche, we will see what happens.  If it works for 7, or even 6 channels, it's still a good price/performance. The only other option I see is to go genuine Futaba, and their prices are just far too high. I'm more disappointed in FrSky's actions in this.  I'll be really surprised if they let this go because they have come out with new firmwares in the past.

  • Developer

    @I.S. Even on oscilloscope when I set the trigger to sync with any pulse greater than 4ms or even 3ms the error occurs. If I push more from the channels the synchronization is missed.

    @Robert, there is an extra element that maybe you're not thinking on. There is a gap after each channel pulse. So, in fact a 1000us wide pulse plus a gap of 400us will contribute with a time of 1400us. We cannot just sum all the pulse width values. There is a sum of 3200us just for those gaps (8 * 0.4 = 3.2ms). In other words: at 100% a top value is around 1600us though it will be 2000us (pulse + gap).

    3692511839?profile=original

  • Ok, so if we want to correct the problem, and FrSky is not doing anything about it, then the only option I can see is that we change the decoder code to support the bad timing.  Is FrSky is the only one using CPPM?  If so, then there's no compatibility issue with other receivers, right?  And also, if they are the only game in town, besides the Futaba SBUS, which is a higher price alternative, then there's little choice.

  • Developer

    I am pushing more my people and we are taking this issue to GM/CEO level at FrSky. If that does not help then nothing will help and we need to wait until they release their new hardware where this thing is fixed. 

    So we still have some hope... Will it happen, we will see later.

  • That sucks blue monkey balls.

  • Developer

    I just received direct information from FrSky internal peoples and message goes: we know this problem but we will not fix it as new technology is coming soon. Till then use only 6 channels.

    That's a bit sad news but we do not have any support from FrSky for this issue.

  • I've sent an email to: sales4tech@gmail.com

    Hello, I am contacting you to find out if you are working to solve the problem of the CPPM timing on your receivers.  I have bought many of your units (8 receivers, 2 transmitter modules, and telemetry display) and have been very pleased with the performance.   More importantly, I have given very strong recommendations to other people that they should buy your systems because they are a very good value and perform well.  I am a developer on the Ardupilot project, and using CPPM is important for reliability of the data link between the radio receiver and Flight Control computer.  It's also nice to eliminate wire clutter.

    But recently have found out about this problem where the frame width of 18ms is not capable of properly supporting 8 channels.  I have been using all 8 channels, and I have been lucky not to have had a problem!
    I would like to know if you are working on a firmware update to fix the problem?
    I think everybody, and I mean everybody, should sent them an email.
  • This is a bit disappointing. However, FRSKY is one of the ONLY companies out their that listen to their customers so I'm sure they will make the change if we ask. which I'm sure a lot of people have done already.

  • I.S. the problem is real.  As I said, I tested it, and it really happens.  When all the channels go high, the system locks up.

    Crashpilot: Are you sure that's what happened?  This only occurs if virtually ALL of your channels are high.  You need all 8 channels high, if even two of them are 1500 or less, the problem is virtually impossible to get, and if two of them are near 1000, it is impossible.  Why would you have had channel 8 high?  And you were holding full pitch, full roll, full rudder and full throttle when you tried to switch modes?

  • Developer

    Yes, all my multicopter are S.BUS or PPM these days. Comparing the clutter of eight wires to a single one there is no question. Especially when you want to move the receiver out on a arm for separation. But I also use FrSky receivers.. :(  Guess I have been very lucky so far. Time to power up the scope and have a look.

This reply was deleted.