Cheerson CX20 Protocol

I have connected my logic analyzer to the stock CX-20 TX and I've captured a bind session. The transmitter is based on the A7105 module and I've identified the interface pins based on their capture function. I've attached the link to a capture of the bind session. It is possible that it did not actually bind, so let me know if the data isn't complete. I will capture the TX functions to include in each: 1) Aileron, 2) Elevator, 3) Throttle, 4) Rudder, 5) switch SWA - 3 position, 6) switch SWB - 2 position, 7) Aux 1 and Aux 2. Please let me know if there are other captures required.



CX 20 Bind Session

I've captured a number of files with the Cheerson CX20 stock transmitter. For each of the sticks and modes, I have collected 10 seconds of data at 4mhz. I have included one capture of the Bind process and I have confirmed that the CX20 and TX did complete the bind. I have also collected the output from movement of the Throttle, Rudder, Aileron and Elevator as well as the output of the two flight mode switches.

Based on my very limited experience, the files look like the other Flysky captures I have reviewed. Unlike other Flysky I've seen, the last word on each packet cycles sequentially beginning with x0A00, x1A00, x2A00, x3A00, and so on through xFA00. AETR are 1234. They seem to be centered at x05DC (1500) and the range is generally from x03E8 (1000) to x07CB (1995). Word 9 and 10 are used for the Aux 1 and Aux 2 potentiometers and they range from x03E8 to 07D0.

Channel 5 (word 8?) is used for the flight mode, with the mid value x05DC as flight mode 0.

Channel 5 value
(position of SWB-SBA) (Mode) (Value hex) (Value dec)
0-0 = Takeoff = x05DC = 1500
0-1 = GPS Hold = x076C = 1900
1-1 = Orientation = x06A4 = 1700
1-2 = Altitude Hold = x0514 = 1300
0-2 = Return Home = x044C = 1100

The generic Flysky protocol using 5 or 8 channels on my Devo 7e doesn't appear to bind to the Quad.

Here are the Logicdata files.
dl.dropboxusercontent.com/u/31578062/CX20%20Bind.logicdata
dl.dropboxusercontent.com/u/31578062/CX20%20Arm.logicdata
dl.dropboxusercontent.com/u/31578062/CX20%20Disarm.logicdata
dl.dropboxusercontent.com/u/31578062/CX2...20L%20last.logicdata
dl.dropboxusercontent.com/u/31578062/CX2...0Up%20last.logicdata
dl.dropboxusercontent.com/u/31578062/CX2...201%20last.logicdata
dl.dropboxusercontent.com/u/31578062/CX2...202%20last.logicdata
dl.dropboxusercontent.com/u/31578062/CX2...2%20cycles.logicdata
dl.dropboxusercontent.com/u/31578062/CX2...20then%20R.logicdata


Please let me know if there is anything else I can provide.

I don't mean to be a pest, but I am wondering if anyone has looked at this? This CX20 appears to be a minor variation of the Flysky protocol using seven channels. I have not been able to bind to my devo 7e using any current Flysky variety.

The initialization process appears to be an exact copy of what I saw in the WLToys variety, and the seven active channel values are used in a similar fashion except for the last word of the data packet. Channels 1-4 are the AETR and channel 5 is used to set flight mode. Channel six and seven are used to control pitch and roll of the gimbal. The last word of the data packet is cycled through 16 sequential values.

Let me know if there is anything I can do to move forward on this.

Just wondering if anyone is doing CX20 protocol work? No updates? Seems strange to have all the other Cheerson quads. I bought a Devo 10 and was hoping to use it in place of the bland stock TX. I have seen a video of someone using a different receiver and using a Devo is that the way to go? I have a Devention 10ch RX but it says it is not compatible with a CX-20. Is there any RX's that are? Thanks for the help.

No, there hasn't been any interest. And I'm not too concerned about it.

The reality is that this quad flies better with a different receiver, and it's relatively inexpensive to get a nice OrangeRX or Frsky. With those you have more channels (10-14 vs 7) and potentially longer range -- although the stock has pretty good range. I still fly with the stock for short range site surveys, but the real fun is adding a gimbal, retracts, and lights, hard to do with the stock RX.

So is the Orange RX plug and play with the CX20 and deviation? Which protocol? How are the flight modes setup? Is this a good choice?

www.ebay.com/itm/141906002162?_trksid=p2...e=STRK%3AMEBIDX%3AIT

Yes, in fact the Hobby King Nova is available without a receiver, so the OrangeRX and Frsky are the most popular choices. OrangeRX uses DSMX, and with gimbals you need a Devo with pots, although you can also use trim buttons. The v2 seems to be well received and my R1220X v2 is nice. I got mine from Hobbyking... its a bit of a wait and the R1220X v2 is only a couple dollars more than the 820. If you use CPPM (one wire) to connect to the APM FC, then you can connect servos, lights, whatever to the additional ports. And when using CPPM, you can still attach a servo or sensor to channels 1-9 RX output pins.

The Frsky incorporates telemetry somewhat easier I hear, and Devo support is in test now. I have the telemetry radios so I don't need it.

If you search this site for APM you will find some good INI files that will work with either of these RX.

From the first dump, I can tell that it's definitively a Flysky variant:
- brodcast address is 0x5475C52A (like Flysky)
- the A7105 init is nearly identical as Flysky with only 3 registers with different values (over 50): 0E_DATA_RATE=0x01, 1F_CODE_I=0x1F, 20_CODE_II=0x1E
- packets are sent every 3984µs (different)
- payload is 21 bytes (like Flysky)
- bind packets are sent on rf channel 1 with first byte set to 0xAA after bind this byte changes to 0x55 (like Flysky)
- last byte of the packet is set this way (hopping_frequency_counter<<4)|0x0A (different)
- 16 RF channels for hopping (like Flysky)
- the TX ID in the dump is 0x06358972 sadly the hopping frequency table is slightlydifferent from Flysky... In the dump the table is:
0x3A,0x53,0x49,0x26,0x0D,0x5D,0x3F,0x8F,0x17,0x67,0x35,0x85,0x21,0x71,0x2B,0x7B
The Flysky table for this specific ID is if I'm not mistaken:
0x03,0x53,0x49,0x99,0x0D,0x5D,0x3F,0x8F,0x17,0x67,0x35,0x85,0x21,0x71,0x2B,0x7B.
Note: only 2 values differ which on a total of 16 frequencies should still give us a good link. If other TX ID/freq tables are dumped we might figure out something to adjust these values.
- I haven't looked closely at the sticks since this is the easy part. There are 7 channels centered around 0x5DC (1500). Values are most likely coded like Flysky ie equivalent to PPM 1000(µs) is -100%, 1500(µs) is 0% and 2000(µs) is +100%. (Does 7 channels match the number of outputs of the RX?)
So basically it's quite easy to port this protocol except the frequency table... May be a few dumps from other TXs would help to figure out.
Pascal

I've implemented the changes here if someone is willing to test: github.com/pascallanger/DIY-Multiprotoco...col/FlySky_a7105.ino

Pascal

Nice work. I can't test (yet) but I can provide additional tx spi captures. I've attached the one I did last night (receiver was not on).

Let me know if this contains the tx id and channel hopping info you're looking for.

I'll test on my 7e tomorrow! Thanks!

bikemike wrote: Nice work. I can't test (yet) but I can provide additional tx spi captures. I've attached the one I did last night (receiver was not on).

Let me know if this contains the tx id and channel hopping info you're looking for.

The dump only contains bind data. So I'm not sure if the TX is doing a bind at each startup or if you have asked for it but this is what I see...
So basically yes I can see the TX ID (0x02233465) but I can't see the frequencies.
Also can you post the logic data file instead or change your spi analyzer settings to 4 bits? I've written my decoder based on 4 bits otherwise you miss all the strobe commands...
One thing I've noticed is that on your TX there is no counter on the last payload byte.
Pascal

goebish wrote: Thanks Pascal, here are test builds for Devo 10 & Devo 7e, Deal57 can you test please ?
(Flysky protocol, CX20 format option)

www.dropbox.com/sh/vckyhhyb92cencr/AABHu...gtu8HOFEHMAXIqa?dl=0

I've looked at your implementation here: github.com/goebish/deviation/blob/protoc...tocol/flysky_a7105.c
You are missing this mod in flysky_init():Pascal

I've updated my version in the mean time... Basically, I haven't noticed at first that the counter for the last byte is in fact the hopping frequency index (which counts all the time including during bind even if the output freq is forced to 1)...
Pascal

goebish wrote: Ok, I modified that as well.

Just checked and like I said chancol should also count even during bind (even if rf_freq is forced to 1 during that period).
chancol = (chancol + 1) % 16; should be moved just before return packet_period;
Pascal