[ 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.
If it's in wii, it can be in APM :) Let's get a dev.'s eyes on this to cover the base. JAB, you in here?
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
No one can help?
I just cant get this to work.
I am using the default v2 firmware of turnigy 9x and in non cppm mode everything works fine with all servo wires connected but when i use only one servo wire for cppm mode channel 5 and 6 get swapped on apm planner. So when i do my mixes so i can use my 3 switch on turnigy 9x and gear for 6 modes. now my gear switch moves channel 5 and my f.mode switch moves channel 6. This doesn't work because APM requires channel 5 for a current pwm when you setup your flight modes.
PLEASE HELP ME.
PS: If this doesn't work should i keep the new 27ms xp firmware or go back to the old d8r-ii plus firmware to use non cppm mode with all servo wires plugged in.
Hi i successfully upgraded the firmware of my d8r-ii plus to the xp 27ms.
plugged the servo wire from channel 1 to port 1 of the apm.
Bridged the signal from channel 3 and 4 from d8r-ii ,plug and bridged the signal from 2 and 3 on the apm.
All works well and i can see all my stick movements on apm planner
The problem is now i cant use my 3 mode switch plug gear to get a 6 mode.
The reason why this isn't working is because with this mixing it appears on channel 6 instead of channel 5 for mode changing.
This worked fine when i was using normal ppm with my turnigy 9x and all the servo cables connected.
Can somebody help me with this?
Thanks
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
-
1
-
2
-
3
-
4
-
5
of 21 Next