CX-10 green board experimental build

Please find enclosed experimental build for CX-10 based on hexfet's module.

It requires nRF24L01+ (or Beken equivalent) module.

I built it for Devo 10 and Devo 7E, model file has speed assignment to FMODE. If you have Devo 7E, you can assign Channel 5 to less than 0 for low speed, 0 to 50 for medium, >50 - fast.
Channel 6 mapped to ELEV D/R is a flip channel - <= 0 - no flip, >0 - do a flip upon the elevator/aileron stick.

Please note that it supports only CX-10 "green board" version.

Please report success/failure.

Success!!!!
Tested with CX-10 Green board and JXD 395. Both works perfect, not any glitch or lost packet, simply perfect!
BTW, I tested also rates and flip mode and both works perfect.

Congrats Victzh, this is great!!!

Unreal thanks buddy great work
Neil

Hi,
I doesn't work on mine. But may be i make something bad:
- i boot up cx10. led flash, and after a little amount of time, blue light flash fast, and red light stay solid.
- i boot up devo. nothing change on the cx 10
- i go full throttle, and min throttle (i remember i had to do that with the original radio)
nothing change on cx10...
i will try with the original radio

I have a blue board. Didn't remember this little detail...

camousse wrote: Hi,
I doesn't work on mine. But may be i make something bad:
- i boot up cx10. led flash, and after a little amount of time, blue light flash fast, and red light stay solid.
- i boot up devo. nothing change on the cx 10
- i go full throttle, and min throttle (i remember i had to do that with the original radio)
nothing change on cx10...
i will try with the original radio

Are you sure your CX-10 is a green pcb edition?
What nRF24L01 module do you have installed at your Devo TX? I lost your comment about blue PCB.
The armin procedure from stock TX (throttle Up, Throttle down) is not necessary using your Devo TX.

@Victzh, tested 3 more charges under my CX-10 and JXD-395 flying outside. Not any single packet drop flying at 1mw power output to about 50 meters.
My nRF24L01 module was bought at Banggood, it's the typical under other sellers with PA + LNA, maybe people using modules extracted from stock TXs could have problems, I don't know...

PhracturedBlue wrote: victzh,
can you use the uploader script instead in the future?
I'm trying to get developers to use the upload area because it allow me to not have hundreds of old builds sitting in the archives for years taking up space. All developers have access to it, and it works on all platforms.

I will. I forgot about this script when uploading the build. May be it makes sense to pin the message with the script in Builds subforum as a reminder?

And FYI, this is amazing work. Good job.

Thanks! Still many things remain to be solved, in particular the reception path. Do you think it makes sense to put the emulation code in the separate file in src/protocol/spi directory? The alternative is to make it an include (I would call it xn297emu.inc - it's not a header) to not burden Devo 7E at the cost of multiple instances in all other Devos.

Hi victzh, I have a question...
Can I use safely your experimental build to fly other protocols?
Your build appears to be compiled with latest merges from DeviationTX repository, but I would prefer to ask you because tomorrow morning I plain to use my Devo TX.

Will this work with the Devo 8 and Devo 12?

Also is it now in the deviation nightly builds?
Thanks for all your hard work..

@Durete - it's as safe as any nightly build, your judgement here is as good as mine.

@magic_marty - it will, I just built it for the one I have (10) and another one that is critical with resources (7E) to check it compiles and works well with the module system. The module itself is not production quality yes, one thing is the protocol is not reversed fully yet and we can't support many CX-10 flying simultaneously. Another, I would like to implement "blue board" as well. It will take some time but it's gonna be soon.

victzh wrote: @Durete - it's as safe as any nightly build, your judgement here is as good as mine.

@magic_marty - it will, I just built it for the one I have (10) and another one that is critical with resources (7E) to check it compiles and works well with the module system. The module itself is not production quality yes, one thing is the protocol is not reversed fully yet and we can't support many CX-10 flying simultaneously. Another, I would like to implement "blue board" as well. It will take some time but it's gonna be soon.

I also have a blue board. I look forward to your work on that and it is much appreciated.

Awesome work!

I'm brand new to the scene. I recently purchased a CX-10 but I didn't like the controller so I purchased a Devo 7E. Of course I'll buy more serious copters later but for now, this is a neat toy.

I analyse the blue board protocol on the past. And the tx have to receive the rx id to send good packet (only one).
The CE pin of the NRF24L01 is always high, so you can't change the mode (TX/RX of NRF24L01). But PB said it is possible by shutting it down, and restart it in RX mode. It take times (don"t remeber how much) but i think it can work

The main problem is not changing the mode, it can be done through the power down as PB said (more slowly, but may be not critical). The problem is whether nRF24 or Beken can detect a valid packet on air, issued by XN297. It's not tested yet, and not implemented in the emulation layer.

Patience...

Ok i understand what you mean. Preambule (one bytes that is sent before address is sent, to identify start of packet) is different from nrf24l01 to xn297. this means the nrf never identify the start of a new packet, so we never receive what we expect.
Some guys try to put the NRF24L01 in "promiscous mode" (as in ethernet, listen to packet without knowing the address). I already post the link in the jxd395 thread.
The basic idea is that. Packet are composed of preambule, address, and payload. For exemple, preambule is AA. By using a address on 2 bytes (the minimum), and setting the address to AA AA, nrf24l01 will misunderstand the start of the packet, and the payload will be the real address.
Ok i think about it, and it isn't usefull as preambule is different