[ 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
Just updated the repo with the fixed ppsum signal driver here: https://github.com/Crashpilot1000/TestCode3/commit/75f7a67587a158ce... After all I went the autodetection route. The problem condition has to occure 30 times in a row (540ms) and then the fix is automatically enabled for the flight session. The statistics gathering + displaying method also works but is MUCH longer.
Cheers Rob
@John Church: Actually it isn't in mwii/bf/cf or openpilot.. I somehow lost track of all the projects around and just focus on stuff that I am interested in with my gear. Since I publish my code and some people (besides me) actually fly it, I keep it as general as possible, so there is a variable to set for those troubled 18ms 8channel ppsum RX (so fallback to default is mostly/always possible). Dominic Clifton ("cleanflight") took over the openpilot ppsum decoder and finds it works better on his TX/RX gear transmitting more than 8 channels (maybe graupner, maybe something else, his documentation is not clear on this). Well I tried "his" code on my troubleled Frsky gear and it is def. no solution for my setup - since I don't have the range of available radiotransmitters and receivers at hand I can not comment if it might be superior on other setups than the defaults. However I choose to go that route: During the first second where a valid ppsum signal is detected some statistics are gathered (without holding back RC data):
1: The count of readable channels detected (in my case: 8)
2: The average time for a complete frame (like 18ms)
So the user can print out those values in the command line interface (CLI) by typing "status". If the ppsum decoder finds something troublesome it will inform the user there like "sync in danger" and advise to set an option (if available) or change the radiogear (that's the point where the user must check the manufacturers website if an update is available)
EDIT: That could also be some mavlink message as well - so the mission planer could present the user a nice warning requester "You have trouble with your RC - check the configuration page for details" or something like this. Not everybody is a nerd and some people might be very happy to know that before their flight ends up in an out of control situation.
Cheers Rob.
BTW: I did a video of the problem and the solution here: https://vimeo.com/101973730 . Well after all it is possible to use those 18ms Frsky sumsignal RX without problems and without flashing a new frsky FW that produces more inputlag.
I am working on some 32 Bit port of multiwii and was able to reproduce the 18ms problem with unflashable Frsky D4FR http://www.frsky-rc.com/product/pro.php?pro_id=100. 7 channels maxed, then a little channel 8 and BOOM all channels floating around 2000us - sync lost. At least in multiwii it is not possible to arm the copter with 7 channels + X maxed you always have perfect sync in startup/arming phase. In those - very rare occasions where such sync losses can happen it is enough to add the sync condition: 8 channels done - new sync! I tested it - it works (no sync loss) even after provoking/teasing it for minutes and that will not happen in reality (like: 4 Aux channels maxed, full throttle full roll&pitch and then a little yaw..)
BTW: I measured the ppm framelength in software it is 18ms - so that is confirmed with the old D4FR :)
So maybe there is also a flightcontrol sided change of the RC ppsum code that allows that for Arducopter?
Cheers Rob
Indeed that is on hardware level. But what now on the firmware level (mission planner config to read RSSI from this Sbus rssi input port) ?
No experience with pixhawk, but according to description:
"the port labeled "SB" can read RSSI or output S.Bus to servos"
Hi Renato, I will get RSSI from Ch2 indeed. But how does Pixhawk read this RSSI input ? From which port and how do I configure Mission planner to tell it to read RSSI from whatever port on pixhawk ?
Thx
From ch2 signal pin.
"...still get RSSI..." what you mean by still ? How you get RSSI before upgrade ?
After upgrading A D8DR II Plus with this 27ms CPPM firmware, will APM and mission planner still get RSSI information ? Or Do I need to wire something else and/or recompile the Arducopter code ?
Same question if Pixhawk is used instead of APM ? How do I get RSSI from a D8DR receiver upgraded with CPPM firmware ?
If only 1` wire from your receiver to the APM you better do the 27 mS software update.
I
-
1
-
2
-
3
-
4
-
5
of 17 Next