Cheerson CX20 Protocol

I agree 2 values are different on a total of 16. The RX will just even go over it without an issue.
Let's see when we will have at least one more dump.
Pascal

Here are two bind captures with the receiver on. Let me know if either of these will work.

drive.google.com/file/d/0B4toKKKJwI9jNFN...cGc/view?usp=sharing
drive.google.com/file/d/0B4toKKKJwI9jM1Z...TU0/view?usp=sharing

Also, I'm interested in having a look at the parsed data too. Is your a7105 parser available on github?

I've also seen some parsed data for the nrf24 captures so I assume there is one of those floating around somewhere too.

Thanks for the dumps
FYI RX does not have to be on since there is no "talk" between TX and RX.
Your TX ID is 0x02233465.
The hopping frequency used is:
0x90 0x40 0x7C 0x2C 0x86 0x36 0x68 0x18 0x5E 0x0E 0x27 0x4A 0x54 0x3B 0x72 0x22
The equivalent Flysky is:
0x90 0x40 0x7C 0x2C 0x86 0x36 0x68 0x18 0x5E 0x0E 0x9A 0x4A 0x54 0x04 0x72 0x22
Again 2 frequencies are different...
Pascal

bikemike wrote: Also, I'm interested in having a look at the parsed data too. Is your a7105 parser available on github?

I've also seen some parsed data for the nrf24 captures so I assume there is one of those floating around somewhere too.

I've written quickly my own parsers using powershell which I adapt time to time to my needs.
I'm sharing them if it can be useful.
In the attached zip, you will find:
- nrf24L01 parser which is giving a really detailed view of every register access down to the bits and flags
- a7105 parser which is using a 4 bits output of the SPI analyzer since like I said strobe commands are on 4 bits and not decoded if you are on 8bits. I haven't implemented a full register details since most of the time there is an init section and nothing else...
- output of the a7105 parser from your bind file. It's a CSV file which I open in excel, do a text to columns with space separator and then apply a filter on all the columns. After that you can choose to filter what you want to see. RF channels is an access to the register 0F_PLL_I, payload is an access to 05_FIFO_DATA. When you filter on payload you can see the time difference between 2 payloads which is usefull to get the timing right away.
Pascal

Ok there is a pattern.
TX ID 0x02233465.
CX20: 0x90 0x40 0x7C 0x2C 0x86 0x36 0x68 0x18 0x5E 0x0E 0x27 0x4A 0x54 0x3B 0x72 0x22
Flysky: 0x90 0x40 0x7C 0x2C 0x86 0x36 0x68 0x18 0x5E 0x0E 0x9A 0x4A 0x54 0x04 0x72 0x22
TX ID 0x06358972
CX20: 0x3A,0x53,0x49,0x26,0x0D,0x5D,0x3F,0x8F,0x17,0x67,0x35,0x85,0x21,0x71,0x2B,0x7B
Flysky: 0x03,0x53,0x49,0x99,0x0D,0x5D,0x3F,0x8F,0x17,0x67,0x35,0x85,0x21,0x71,0x2B,0x7B.
When the base freq is 0x0A add 0x37 and then substract (TXID&0xF0>>4) -> this is preventing the frequency to be too low or roll over
When the base freq is 0xA0 substract 0x73 and then substract (TXID&0xF0>>4) -> this is preventing the frequency to be too high
Applying the above rules makes the frequency table to be auto generated correctly for both TXIDs.
It looks like to me that this is a Flysky frequency table fix to work with any TXID... Since it does go around the special treatment we are applying in our Flysky code to TXID[3] where we limit the upper value to 0x09 since 0x0A-0x0A=0 and anything above will give rf channel values of FF,FE....
Pascal

I ran out of time today, but i do have the controller all set up for testing. I'll test in the AM as soon as I can!

I really appreciate your efforts!

Any news?

Ben has dumped is TX with TXID 0x89643A30
CX20: 0x3E 0x57 0x11 0x61 0x1B 0x6B 0x25 0x75 0x2F 0x7F 0x39 0x89 0x43 0x93 0x4D 0x34
Flysky: 0x07 0x57 0x11 0x61 0x1B 0x6B 0x25 0x75 0x2F 0x7F 0x39 0x89 0x43 0x93 0x4D 0x9D
Applying the above fix: 0x3E 0x57 0x11 0x61 0x1B 0x6B 0x25 0x75 0x2F 0x7F 0x39 0x89 0x43 0x93 0x4D 0x2A
So I've found how to find the values which are causing issues. It looks I've found how to correct the 1st value (0x3E has been corrected like it should from 0x07).
But the second value 0x34 has been corrected from 0x9D to 0x2A instead of 0x34. The strange thing is that this second value correction worked in the other 2 cases...
Without more examples I'm afraid it's going to be difficult to find a common rule for this second value.

Do you think it's possible to dump the SPI from a RX perspective?

I bound and connected to the CX20 receiver just fine using version deviation-devo7e-v5.0.0-a1d201f! I didn't actually fly it but using Mission Planner I could see all the inputs were working for Channels 1-6 and the ranges seemed to be right on - i'll add Channel 7 as soon as possible. All of the outputs were as expected as well, using a Devo 7e version of the Model.ini I use on my 6S (normally with DSMX). The control response seemed a bit laggy, but that may be the Mission Planner screens.

I think I can set up the logic analyzer sometime tonight or tomorrow and get some captures.

I managed to get captures from my Rx. I *think* I labelled the inputs correctly - I got decoded data with the correct TXID, so I guess it's correct. I soldered them all to get the capture, but the pins of interest are attached as follows:

Blue - GND (bottom or top row, leftmost)
Orange - CLK (bottom row, 2nd from right)
White - ENABLE (top row, 4th from right)
Black - MOSI (top row, 3rd from right)

Yellow - MISO (bottom row, rightmost) (not sure about this one)

Actually, I'm not sure about which way around to label MOSI and MISO at all. My TXID definitely shows up in the MOSI data.

I realise the picture is pretty rubbish, but hopefully you get the idea.

Ben

The RX RF module looks exactly like the one used in the Flysky I6 shown in This Blog . The pinouts match up to what you have used. I've got to find time to get this hooked up....



I need to study this a bit more but it's nice to know that this is part of a larger family.

Ben has posted new dumps that I can now decode with my script: www.rcgroups.com/forums/showpost.php?p=36338135&postcount=6523
The frequencies the RX is looking for are:
0x3D 0x56 0x10 0x60 0x1A 0x6A 0x24 0x74 0x2E 0x7E 0x38 0x88 0x42 0x92 0x4C 0x33
Which is -1 what the TX is sending.
Perfect we can now go to the second step which is to use different TX IDs to get the expected frequencies out of the RX.
Pascal
PS: I'm attaching a new version of the powershell script to decode A7105 dumps which contains a few fixes for the ones interrested.

Flysky/CX20 is now fully reversed including the frequencies vs TXID.
Goebish the source file is available here: github.com/pascallanger/DIY-Multiprotoco...col/FlySky_a7105.ino

Pascal

Hello,

Could you please confirm that now the Flysky protocol that is implemented in the latest builds (I am currently using a nightly of March, I recently migrated from 4.01 to recent Nightly to enjoy control of my modded Eachine H8 Mini thanks to you all !) is working with Cheerson CX-20 ?
I'm thinking in buying this little bird for trying mission planner / GPS / camera shots from aerial, and I'd like to know if I'll be able to control it using the stock receiver and my Devo10 (or if I should fastly move to a new receiver such as an Orange one or anything else).

Thank you very much !

For A7105 , it's ok on my side
I'll make a return if I manage to get the CX-20 then I'll try the bind with my devo for sure !

Looking for some help here. Experienced RC flier, new to quads. Got a cx20 off ebay, having trouble setting it up. The Cheerson forums keep telling me the same things, use Mission Planner, etc.etc.
I can go through the whole calibration in MP, but radio calibration and esc calibration do NOTHING.
if I tilt or rotate the quad, the HUD moves appropriately.
Radio appears to bind, light on rx goes from flashing to solid when I turn on the tx.
I don't have a logic analyzer, but I do have an oscilloscope.
Ideas/suggestions on how I can determine if either the Rx or TX is bad?
I tried plugging a regular rc servo into one of the rx outputs, also got nothing.
Thanks for any all replies/help.