[ 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
@Jelle Please look at the picture in the post that is labeled "FrSkys CPPM issue", and then please explain how you figured out that a valid frame started. It's not about the length. It's about being able to identify the start of the frame.
Sorry if this already has been said, but this storm in a teacup is not requiring a firmware change from frsky, especially if this deteriorates the update frequency of the receiver.
The whole thing IMHO comes down to: do you need verification that you are at the start of a frame every 18/20 milliseconds, or can you program your way around 'invalid' sync pulses? Any microcontroller can count up to nine, so that should be no problem. Even if your crystal on the receiving side will drift from the tx one, you still can correct this shift by detecting the timing between the pulses. Unless you are missing entire pulses (which happens on an analog link, not likely on a digital link), you can always count to nine and know that your sync pulse is there.
If you need more verification: you can still know that your too-short sync pulse is the right one as you can predict it being too short. If the falling flank is at 18mSec, then you have it.
PPM is a technique designed for analog radios and has proved pretty robust and usable for a long time. Even with microcontrollers well established, we are still using this obsolete protocol. Make use of their potential instead of complaining if one actor uses the protocol not fully to spec: Be forgiving in what you accept, be strict in what you put out.
I think it was already pointed out above that having a 27ms frame time, will result in slower frame rates vs the 20ms frame size. Simple math says that we'll be able to receive only 37.03 frames/sec as opposed to the 20ms frame rate, which will provide 50 frames/sec. Also having a 4ms frame size, would probably be overkill, and might overload the decoder, since we'd have to process 250 frames/sec.
In a typical realtime system, 10ms response time is sufficient, so I think 10ms frame would be ideal, if the decoder can handle 100 frames/sec.
So, why are we accepting, a slower frame rate as a win? The only success I can see out of the situation is that we were able to coerce FrSky into providing us with a compromise solution, to appease us.
I know, how is the 27ms solution a compromise?
I mean, if we accept the 27ms "solution".
How is this a compromise?
How can we be more robust than looking for a 4ms sync pulse? That's what everybody else is doing.
I don't understand why we are accepting a compromise solution, from FrSky, when we should be putting code in our own software that can solve the problem, and put in functionality which can make us more robust against such radio signal problems in the future. We need more robust code to perform failsafe, in case of bad radio signals anyways.
Kenn, you can of course stick with the 18ms period. Do you need more than 6 channels?
Why not use an Xbee as a control link? At 57,600 baud, you could transmit 8 16 bit control words at a frequency of 450 hz? If that is the only thing the Xbee is doing, no telemetry on that link, then it would be pretty fast?
@Jani--
Great to hear they're being so responsive. Any chance of having an option that upgrade I was discussing, where instead of slowing down the frame-- which is quite bad for computer control-- instead speeding up the frame and compressing the CCPM? I'd be very happy to do some testing on that. At 37Hz, there's too much jitter and latency, making the FrSky no longer an option as a super-cheap, proven, robust link between autonomous vehicle and digital controller.
Status update on issue. Today we received custom made test software directly from FrSky. (Thanks to all guys over there that have been working with me to solve this issue over last month or so. Coffees and Doughnuts on me on our next meeting).
Our developers have now received their copies of the test software and people are currently uploading those to their receivers. We should have feed back from devs. in few days. If and when everything are ok we will give green light for FrSky and they will release official firmware with 27ms frame size.
And with devs. I mean most of ArduCopter/ArduPilot devs. and several outsiders too.
-
9
-
10
-
11
-
12
-
13
of 21 Next