[ 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
Hi Jelle, don't be so quick to cut off the conversation. I'm learning a lot by hearing all the discussion!
@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.
@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.
How would the lower update rate affect aggresive quad flying in acro or stabilize mode? Could flips, etc, still be executed?
It probably doesn't matter a lot in the practical sense, since if all you're doing is hucking around the sky you're not going to be trying to control extra channels for camera control, etc, but I'm curious as to what the minimum update rate to be for "good" control in acro situations.
Yes, pretty much has to. It's a failure of the signal, should be treated the same as any others.
I'd also really like it if MP had something where it could tell us "Signal Loss, Entering Failsafe Condition: RTL" or whatever the failsafe is programmed as.
Aah... Good point! If it becomes to much frequent or permanent so it would sign for a fail-safe. Nice!
Loss-of-sync should be treated as loss-of-signal, instead of just hanging onto the last known good value.
Yes, you could not instantly switch to failsafe ever time you lost sync. Because I agree, it probably happens a lot be we don't even know it.
No, what I mean is, if we have continuously lost sync for >1 second, then do something.
But again, not to get alarmist. The APM system is already 100 times safer than traditional RC. I can completely lose signal, and the aircraft will do something intelligent, instead of just crashing.
However I do think this loss-of-sync thing could be improved.
@Jelle: PS.: Even discovering the channels at the first counting would be dangerous. If it start wrong all the thing would be compromised.
-
4
-
5
-
6
-
7
-
8
of 17 Next