JD 395 cx-10

Sure, I'll do that.

It was late last night and I didn't intend on securing everything. I think one of my probe popped loose when I was manipulating the controller sticks. The stick tension is super tight.

I'll solder everything to ensure a solid contact. And do those captures as requested. It makes more sense to break it up.

In the past, I had recorded the video so you can scrub through the capture and see what I physically did. But the round trip of capturing and uploading the video is tedious.

This is how it looked like last night...quick and dirty method. LOL

Here's the series of captures breaking it up by task.

I wired it up the same as you saw in the previous capture. However, this time I soldered all the connectors instead of using the clips.

Steps:

Turn on TX.
Turn on quad.

Towards the end of the capture, I moved the throttle stick full up then back down, which finished the binding process and arms the motors.

cx10_green_tx_startup_bind_arm.zip

This capture have me moving throttle up and down.

I did this 4x total.

cx10_green_throttle_up_down.zip

This capture has me throttle up to about 50%.

Then I moved rudder stick left and then right.

Repeated the left and then right cycle 4x total.

cx10_green_throttle_50_rudder_left_right.zip

This capture has me moving the elevator (right stick) up and down.

I did this 4x total.

cx10_green_elevator_up_down.zip

This capture has me moving the aileron (right stick) left and then right.

I did this 4x total.

cx10_green_aileron_left_right.zip

Finally, this capture have me invoking the two switches that can be activated by depressing the left stick or right stick.

Depressing the left stick in cycles between the three preprogrammed rates.

I started off by pressing the this left stick in to cycle between each rate.


Next, I press the right stick in to toggle auto flip mode. Then I moved the cyclic to complete the flip.

cx10_green_dual_rate_flip_switch.zip

Are people still working on this protocol?

Here's something to try. Adds a new CX10 protocol. This diff is against the latest PB repo. The changes are also pushed to my repo at bitbucket.org/hexfet.

The first three writes to the XN297 are to registers that don't appear in the other nRF clone datasheets - no telling what that's about. Couldn't find a XN297 user manual. The code for those statements is commented out in the cx10 driver - enable at your own risk.

I added the Beken register set 1 initialization. Other than that the sequence is exactly as captured.

The captures have all zeros for the MISO data, but the TX never tries to read anything anyway. After binding the frequency channel is changed before each transmitted packet through a 4 channel sequence.

It appears the same fixed TX/RX address is always used. Doesn't bode well for flying multiple models in the same space.

Channels are 16-bits and vary from 1000 to 2000 like esky. May need reversing.

Extra switches are on channels 5 and 6, but from the data there may also be another bit involved. Need some feedback on how the dual-rate and flip functions behave.

Looks like this is the same as the MoonTop protocol, though I didn't examine it closely.

This is completely untested. Enabling the nRF in the emu_devo10 build gives me a missing multimodule error...

hexfet wrote: Here's something to try. Adds a new CX10 protocol. This diff is against the latest PB repo. The changes are also pushed to my repo at bitbucket.org/hexfet.

The first three writes to the XN297 are to registers that don't appear in the other nRF clone datasheets - no telling what that's about. Couldn't find a XN297 user manual. The code for those statements is commented out in the cx10 driver - enable at your own risk.

I added the Beken register set 1 initialization. Other than that the sequence is exactly as captured.

The captures have all zeros for the MISO data, but the TX never tries to read anything anyway. After binding the frequency channel is changed before each transmitted packet through a 4 channel sequence.

It appears the same fixed TX/RX address is always used. Doesn't bode well for flying multiple models in the same space.

Channels are 16-bits and vary from 1000 to 2000 like esky. May need reversing.

Extra switches are on channels 5 and 6, but from the data there may also be another bit involved. Need some feedback on how the dual-rate and flip functions behave.

Looks like this is the same as the MoonTop protocol, though I didn't examine it closely.

This is completely untested. Enabling the nRF in the emu_devo10 build gives me a missing multimodule error...

Hi Hexfet,


Good to hear, you are working on

Here some pdf I have for the XN297





Can you build it for Devo 7E or Devo 10 ?, I can try with my JXD 395

Unfortunatly, the Moontop M9911 dont have the same protocol even if it's using also this XN297...

A small remark concerning the name of the protocol.

In fact, the CX-10 have(d) two board: the "red" pcb compatible skywalkr protocol (from ABE compagny) and this "green" pcb (you are working on) labeled with the "LF" compagny. The JXD 395 is also using this "green" protocol. So calling CX-10 can be confusing for those who have the red version (even if now, last CX-10 are all in green edition). Maybe call it JXD 395 ? or LF (the name of the RF compagny)

CX-10G & CX-10R

I bought a CX-10 with a dead board (green). BG sent me a replacement board (red). Not binding with the original TX. (Reading this thread, now I understand why ) Then BG sent me a complete new set (on the way).

So I will have a "red" CX-10 as "BNF", and a complete "green" one.

I hope the latest Deviation release will support both
(and I'll have some time and luck to install the new module in the D10...)

bm

Here is a build for the devo10. Got past my emulator issues and fixed a couple problems. The post with the diff has been updated.

Took a closer look at the MoonTop capture. It uses the same RF chip initialization, but different bind sequence and data packet format. If this CX10 works I'll look at adding an option for the moontop.

hexfet wrote: Here is a build for the devo10. Got past my emulator issues and fixed a couple problems. The post with the diff has been updated.

Took a closer look at the MoonTop capture. It uses the same RF chip initialization, but different bind sequence and data packet format. If this CX10 works I'll look at adding an option for the moontop.

Sorry but I can't bind my JXD 395 with ...

I have a problem. Devo 7E to cx-10 board red.
Where can I find the setting select , sky wlkr`protocol option.

dieter

mtx63 wrote: I have a problem. Devo 7E to cx-10 board red.
Where can I find the setting select , sky wlkr`protocol option.

dieter

Select the YD717 protocol then press ENT when YD717 is selected than choose SkyWlkr with arrows.

SeByDocKy wrote: Sorry but I can't bind my JXD 395 with ...

What sequence did you use to try to bind? I set the protocol to stay in bind mode for 6 seconds. You'll need to turn on the quad during that time, or try turning on the quad and then hit re-init.

Is there any response from the quad, or does it behave just like there is no transmitter?

Possible issues I can think of:
- mistake in the coding
- missed something in the bind capture data
- XN297 not compatible (maybe something to do with the 3 undocumented registers)
- Are we certain CX10 protocol is same as JXD395?

I got my replacement CX-10 today... WITH RED BOARD and a matching controller!
Now I have 2 working micro quads!!!
(It was worth to wait...)

I tried both method too bind ....
There is absoluptly no response of the quad I will make a short video


Yes the JXD 395 can fly the CX-10 "green" and vice et versa ...

hexfet wrote:

SeByDocKy wrote: Sorry but I can't bind my JXD 395 with ...

What sequence did you use to try to bind? I set the protocol to stay in bind mode for 6 seconds. You'll need to turn on the quad during that time, or try turning on the quad and then hit re-init.

Is there any response from the quad, or does it behave just like there is no transmitter?

Possible issues I can think of:
- mistake in the coding
- missed something in the bind capture data
- XN297 not compatible (maybe something to do with the 3 undocumented registers)
- Are we certain CX10 protocol is same as JXD395?