Advanced Search

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...

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...

Are people still working on this protocol?

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

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

I did this 4x total.

cx10_green_aileron_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 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 have me moving throttle up and down.

I did this 4x total.

cx10_green_throttle_up_down.zip

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

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

can you regenerate the files breaking it up per task?
start with capturing power on and binding
then 4 files moving each stick in exactly one direction (up/down or left/right)
then the extra options (switches, or whatnot)
also, please double-check the connections. It looks like there was bad data in the 2nd half of the capture. maybe snap a pic of how you wired it up?

After the LA has been hooked up.

I powered up the quad and TX.

Then moved the stick up and down to complete binding or arming of the quad.

Then I gave throttle and moved the cyclic stick around. Then moved the rudder stick around.

Then I pressed the left stick in to activate the three rate mode. I pressed the right stick in to activate flip mode. However, I didn't complete the flip.


Let me know if there's a better procedure I should be following.

Thanks.

-Daryoon

Can you explain how you took the capture?
The 1st half looks like SPI, but it seems like it is a repeating pattern. I don't see anything that looks like initialization code though. The 2nd half looks decidedly not like SPI. Perhaps the wires shorted out?

I didn't check to see if I could make out any nrf commands as yet.

I hook up the Logic Analyzer on the bottom 4 legs of the MCU.

Left to Right on the MCU corresponds to:
CH1, CH2, CH3, CH4 on the Logic Analyzer

Hope you can make sense of it. LOL

hacksmods.com/files/cx10_green_capture1.zip

Daryoon - I must admit, that's just genius! Funny thing they didn't bother to connect MISO. Strictly speaking, you can get away without it at the cost of some reliability.

So, the answer for SPI traces - 4 wires going from the top to the bottom of the board and connected (my guess) to the bottom right 4 pins of MCU.

Here's a full resolution shot with the front and back overlayed on top of each other.

The back has been flipped horizontally so the traces lines up with the component in the front of the board.



I also have the Photoshop layered file you can change the opacity on if you have Photoshop and want a copy of the PSD.

Full resolution:

Could someone post an image of the entire PCB where the MCU is visible ?
I'm usually attaching my probes to the MCU, not the RF chip itself.
You can see traces running from RF chip to the lower part of the PCB on the backside, so these are the ones we're interested in. The contacts through the board at the lower part looks like standard pitch, easy to solder / attach SMD probes.

One can also try to solder to these "trough-board" contact rings.

Another document with the pinout (identical to the nRF24L01)

This chips must be even cheaper than the BK2423 ...
The Moontop M9911 have the same chip too ...
(see Moontop M9911 thread )