JD 395 cx-10

Checked both. 7e works with cx-10a, 10 - no binding. Yesterday I also checked only with devo 7e, not 10. So I see only two explanations. Either there is some incompatibility related to Devo10 or my two NRF modules are acting differently (on 7e I have that with PA from BG, and on 10 it was cut out from V2x2 TX). Anyway both work with DM007... I have no good ideas. Does anyone else checked blue protocol on Devo10?

Previously I tested without fixed id-s on both TX-s. But ok - tried several different values on Devo10 - no bind as previously.

My devo10 also fails to bind with blue board CX10 using the first test build that was uploaded. No reaction on the quad LEDs. I'm hoping it's because my 10 has a Beken 2421 module, but haven't had time to do more testing. Looking at the XN297 emulation code it seems like it should work on the Beken. The radio at least receives AA packets since it can bind to yd717.

My CX10 is only a couple weeks old - wouldn't surprise me if it's yet another protocol.

May be it is do the problem of TX and not the rf-module incompatibility?.. I mean: the problem may be in model of Devo, 7e or 10. And the cause of it - is 7e, not 10. I mean that the bug is not Devo10 not working, but the bug is Devo7e working...

I mean that 7e with its dynamic protocols may do (or not do) some extra initializations (of memory or hrdw) for example. And this mechanism overcomes quietly some bug in two-ways exchange. For example.

Really it is only my imagination - I did not studied devo sources above end-protocol level. But may be this idea can be helpful.

goebish wrote: Understood.
I'll try to make it work as on stock controller later, and maybe allow continuous flips ...

@vasiliy_gr can you try these firmwares with the CX-10A ? I don't understand why yesterday's one would work and not this one, mine works and nothing has changed for the blue protocol, DM007 is just a variant of the green one.

www.dropbox.com/s/iaf5z7a56r1s49u/deviat...0.1-51df623.zip?dl=0 (7e)
www.dropbox.com/s/jnu4is0e6nw4xfs/deviat...0.1-51df623.zip?dl=0 (10)

This is probably a stupid question but how do you upgrade deviation from releases such as this which only have one folder and do not have the other folders & files which are transferred after reformatting?
I upgraded with this file via the utility, and transferred the missing files and folders. However, when I boot the TX it screams at me with a continued beep and the screen stays blank. I have restored back to a previous firmware which contained all the files and folders.
Heres a comparison to help clarify my question:
boonce.org/up/Untitled23.jpg
Thanks

You only need to update the protocol folder, and continue using the other folders from a previously nightly. So DFU file and Protocol folder needs to be paired ALLWAYS.
I never format the drive after a nightly update, only delete and copy the new one Protocol folder.

Goebish, did you see actual TX_DS flag raised by XN297? When I first set XN297 code I experimented with it and in my setup it failed to do so. 15 microsecond delay is the CE strobe width, the packet itself goes more slowly - 1us per bit at 1Mbps gives (5+19+2)*8=208us for packet and approximately the same time for frequency stabilisation, so it will be ~0.5ms per packet at least. So you have plenty of time to switch it to RX mode without waiting for TX_DS (which can be eternal).

Thanks Durette for sorting that out for me.

Not binding with the 7e and blue board. What ini is everyone using?

Thanks

goebish wrote: No ini required, it should bind with default settings.
So, looks like there are mitigated results, which module are you using ?
I'm almost sure there's something fishy with switching from tx to rx mode ...

I am using the cx10 module.

What do you mean - cx10 module? You connected it directly to Devo? It should not work. I can modify the code so that it would work, but it would not work for any other protocol requiring nRF module.

victzh wrote: What do you mean - cx10 module? You connected it directly to Devo? It should not work. I can modify the code so that it would work, but it would not work for any other protocol requiring nRF module.

Apologies, was thinking of protocols. I am using the nrf module. And using the cx10 protocol.

It's working!!!

I'm building from goebish CX10A branch. I changed the usleep(15) to NRF24L01_SetTxRxMode(TXRX_OFF). Needed a power down before the switch to receive mode. Seems like some devices don't need it.

Great work all around!

I tried waiting for TX_DS first. It didn't make any difference. TX_DS was being asserted because the watchdog timer did not kick in. I wonder if some kind of wait there might be a good idea to be sure the packet is sent before powering down.