[ 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
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.
@Sandro: yes, stuff will fsck up if it gets a bad signal. But how often does that happen? On the other hand, It will reset correctly when it sees a long enough sync pulse and we assume that the too short sync pulse is a transient thing.
I have no knowledge of the APM sources, I just browsed a little until I found something that resembled what I was looking for. I don't think this is in the main APM source, right? anyway, in this case it looks like the channels are fixed at 8. more than that and you are writing non-existent variables:
volatile int PWM_RAW[8] = {2400,2400,2400,2400,2400,2400,2400,2400}
[...]
else
{
PWM_RAW[PPM_Counter]=Pulse_Width; //Saving pulse.
PPM_Counter++;
}
One other thing though: get that logic out of the interupt into the main loop!
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.
Jelle, just counting pulse is not sufficiently robust. Like I mentioned previously, without sync pulses, we can loose count, and actually mix up the channels. However in this case all pulses have maxed out, so it really doesn't matter. Once again, we need to do a failsafe in this case. We cannot just pass on maxed out pwm values to the code. It is a fault condition.
>>"It just hangs on the last known good value. Maybe that should be fixed."
@Robert, I don't know if there is much more to do here. I mean, do you know what is the frequency of those errors? I really don't know. It's a wireless connection so I would guess that it occurs a lot. If it were confirmed, probably sign for a fail-safe wouldn't be the case.
>>"if((Pulse_Width>5000)||(PPM_Counter==8)) //Verify or guess this is the sync pulse"
@Jelle: Interesting. Though you cannot fix it at 8 channels* and also if you have a false sync pulse your counting would be messed forever. Or am I misunderstanding this?
*Keep in mind that we are talking about the 328's firmware. Those firmwares are generic/universal. If you chose the 328's (or 32U2) PPM firmware it should work at any number of channels not just 8 channels. I don't think we could change the number of channels on-the-fly there. So, searching only for a sync pulse would work at any number of channels.
oh, btw it is in Tools/PPM_decoding/Timers.pde:ISR(TIMER4_CAPT_vect)//interrupt.
-
7
-
8
-
9
-
10
-
11
of 21 Next