Introducing the Issue and the solution:
We've talked about FRSky's CPPM signal on this other post that compares it with a standard PPM signal. The issue is that originally FRSky's CPPM runs at 18 milliseconds. That short period has no space enough for 8 channels plus a proper sync pulse.
After carrying that issue to FRSKY, Jani came up with two FRSky's beta firmwares running CPPM at a 27 milliseconds period. We did test it at the DIYDrones Dev Team and it seems to work pretty fine.
Some guys at that old post were expressing their worries about the 37Hz update speed from the new custom firmware. However, keep in mind that probably you will not see any difference. Mainly if you aren't a crazily fast acrobatic pilot. Furthermore, our focus here is on drones. A good example is the Mission Planner that uses only 20Hz for joystick control.
Well, now those beta firmwares became official: There are custom firmwares for the receivers D8R-XP and D4R-II on their BetaTestSection. The links are now on FRSKY's download area. (Thanks Vladmir for the heads up).
About the Updating process:
Inside of each update zip file there is a PDF explaining how to update your receiver. I'll not describe it here because it's pointless.
Reading their manual you'll see that an FRSky USB cable is necessary. That adapter is a TTL level "USB to RS232" one.
But what's the difference from that adapter and a common "USB to Serial TTL" one? There is just a single difference: the signal is inverted. FRSky's adapter uses the RS232 logic but not an usual RS232 high voltage level that would vary from -25V to +25V. Though the receiver's serial input has internally not just an inverter but also has a RS232-to-TTL voltage level shifter as shown on the diagram bellow (from FRSky's Two Way System Manual):
How to use an FTDI cable:
When I received the first beta firmware some improvisation was needed because I had no the required FRSky's adapter.
I've used my FTDI 3.3V cable with a little trick and it did work perfectly! All I did was configuring the cable to work with inverted input and output signals. ;)
Here goes how you can make that too (at your own risk):
First you need this powerful tool who did the magic: The "FT_PROG" from FTDI Utilities. It runs from a folder and doesn't need to be installed.
The first thing you'll gonna do is attach your FTDI cable and select "Scan and Parse" from "Devices" menu.
After finding the adapter the screen will be like this:
Now you'll navigate at the "Device Tree" selecting the "Hardware Specific" node for checking the proper options that will invert TXD and RXD (output and input of FTDI cable).
Now click on the "flash icon" as shown below:
On the programming screen click on the button "Program" and watch the status bar until it finish.
That's it! After the steps above you have a TTL inverted FTDI cable.
It's reversible, of course. You just need to follow the same steps but this time deselecting the inverting check-boxes.
You'll just need to use some jumper cables. The receiver can be powered by the 5V output from the FTDI cable.
Remember of crossing the connection between your FTDI cable and the receiver input:
FTDI_TXD (orange) goes on the Receiver_RXD.
FTDI_RXD (yellow) goes on the Receiver_TXD.
If you'll flash your receiver... good look! =)
Please, add comments telling us about your experience on it.
Comments
@Vladmir. I've updated the post with the new links. ;)
Thanks for the heads up!
new link to receiver's firmware
http://www.frsky-rc.com/download/downloadItem.php?uid=10
OK, I have successfuly upgraded PPM encoder firmware on both APM boards, one used in quadcopter and second in skywalker. In conjunction with FrSKY D8R-II receiver in both planes works flawless. Yes it works even with D8R-II. I upgraded firmware on D8R-II with one for D8R-XP at a 27 milliseconds period.
I ended up getting a 3.3V FTDI USB-to-TTL to replace my PL2303. This resolved the issue where the update would freeze at 2%.
After some more investigation it appears that the beta firmware from the FrSky website here http://www.frsky-rc.com/DownloadItem.asp specifically for the D8R-II plus gives you permanent (no jumper) CPPM output on Ch8 with an 18ms frame length. I have verified this on the scope. After throwing all caution to the wind I uploaded the beta D4R-II firmware from the same FRSky website into the D8R-II and now seem to have 27ms CPPM on Ch1 when Ch3/4 are jumpered.
I have successfully updated my D4R-II receiver after finally figuring out I had to short the Ch1/2 signal pins to enter programming mode, however my D8R-II plus receiver seems to accept the new firmware (fdd_rx_rev2_cppm_build110314.frk) but then does not output CPPM. I have had both units on the scope and have confirmed the CPPM signal from the D4R on ch1 and that the period is now 27ms but the D8R continues to output a single channel pulse on Ch1 with an 18ms period even when the Ch3/4 signal pins are shorted. Anyone have any ideas?
Has anyone tried this using an Arduino Nano 3.0? The FTDI driver loads fine in Windows 7. I've tried it with RX/TX/G attached, powered from the ESC as well as RX/TX/G, 5V and Gnd pins power from the Nano itself. I don't get the UID message at all.
For people just trying to get by (new to data-communications) this info is priceless as it's not stated in the FrSky instructions. Or at least I didn't read it that way. Thanks.
Why did you expect the FTDI to work without its' GND connected in the first place? I see no possibility to get a relieable datacommunication without a reference to GND. I also didn't connect the vcc line because two voltage supplies can produce another difference of potential if they are not exactly the same.
I did some testing and discovered that both 5V and 3.3V FTDI adapters work. The trick is to have the ground connection from the FTDI (required). First I tried a 5V BEC from an ESC without success but discovered that adding the ground connection from the FTDI adapter made it work. Also the 6V BEC worked with the addition of the ground from the FTDI. And then I switched my FTDI back to 5V and tested with success. In all scenarios the ground needed to be connected. +V connection from the FTDI was not necessary.