[ 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.
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.
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.)
I'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
Comments
Probably not. Those FRSky's TF ones are full compatible with FASST 2.4G Systems and they have a CPPM framing at 20ms. What model is your RX?
i just bought two Futaba compatible receivers. Will these be affected as well?
@David: Many thanks by that info!
Looks like the factory's D8R-SP firmware has just the fast blinking LED. I did check the manual and it has no information about HS. That was making a fool out of me then.
@Sandro, I just got confirmation from FrSky that the 9ms HS mode is disabled in the new 27ms firmware.
Hi Jelle, don't be so quick to cut off the conversation. I'm learning a lot by hearing all the discussion!
Hey guys, stop arguing and start coding. One line (about the 9th pulse) fixes it, about two or three more are needed to keep track of the total frame length and see if it matches some pre-recorded average.
Who will be first to commit a better fix?
@Keen: We are talking about a solution to the masses. Our PPM decoding needs to work with the standard 20ms. They came up with a non-standard solution. We don't need to move from the standard. So, that's it. It would be nice if FRSKY were not messed up the whole thing in the first place.
We don't want to change the system to handle any super-particular high speed receiver system. The point here is make things safe for people that are using normal cheaper hardware with a reasonable quality, like FRSky.
@David: Interesting that you're mentioning that because it doesn't work on my tests. I've tested D8R-SP and D8R-XP on the oscope and I can't see any difference when HS in enabled. The led does blink faster on both receivers. However, on the oscope it still reads and shows a 18ms period. Did you verify if that 9ms is working on yours?
@Kenn, Actually some of the FrSky receivers do support a 9ms frame size. They call it HS mode (vs. FS mode for normal). Check the docs on the D8R-XP, for example.
A see a lot of people saying "27 is only 9ms slower than 18ms. What's the difference?" I think this is exposing a certain misconception about control systems and latencies. This is not a trivial 9ms, this is an increase in latency of 50%. Without getting bogged down in theory, I'd like to point out that that is a large difference, and is noticeable when doing fine control. As long as FrSky is making a 50% slower firmware, it would be really cool if they'd make a 50% faster one, too, using 9ms as a frame window. Our autopilots can easily be rewritten to handle this.
There is an interesting field of controls which shows that better results can be had with granular controls at high refresh rates, rather than high resolution controls at low rates, so there's little risk in going to the higher speed. Anyway, I don't see anyone responding to that, so I guess it's off the table for now.
@Mark. I don't know. I'm curious about it too.
Agreed. If I were an acrobatic pilot I would not use so many channels neither use an APM. I would be cool with a simple and cheaper KK or MultiWii boards (keeping other two boards on my pockets). :P
Talking serious: If someone discover that 27ms CPPM is bad to fly acrobatically on APM... He could stick with the 18ms CPPM firmware and cut off CH7 and CH8 (as described on the post's Note #1). I guess they will provide a way for getting back to the original firmware.
-
6
-
7
-
8
-
9
-
10
of 21 Next