JD 395 cx-10

It's useful to have it in case we'll figure out what's the difference and just to document the protocol.

It is very strange. I checked the XN297 datasheet www.foxware-cn.com/UploadFile/20140808155134.pdf and though I can't read Chinese the register names are in English and all these new registers are DEMOD_CAL (0x19), RF_CAL (0x1e), and BB_CAL (0x1f) with predefined values that should be loaded:

DEMOD_CAL 0x03 0xA7 0x00 0xDF 0x0B
RF_CAL 0x95 0x2B 0x83 0x61 0xB0 0x9A 0xCA
BB_CAL 0x20 0x9C 0x67 0x84 0x7F

compare it with what happens in CX-10

DEMOD_CAL 0x03 0xA7 0xc4 0xDF 0x0B
RF_CAL 0x9C 0xAB 0xBB 0x61 0xB0 0x9A 0xC9
BB_CAL 0x20 0x9C 0x67 0x84 0x4C

These small differences can lead to frequencies slightly shifted, modulation parameters changed, and I don't know what can happen to baseband!

Almost no hope to control it with nRF24L01+. Beken on the other hand probably could be tuned if they'd be a bit more open on their "register bank 1".

As an experiment, can some happy owner of XN297 and working PPM module try and load stock parameters from datasheet and check whether it can control the heli in that state or not?

Thanks @goebish, it clarifies the situation.

Are you able to read the registers? If so, after power-up do they match the default values in the data sheet?

The datasheet describes them as "debug registers".

I've got very strange results comparing original CX-10 (green board) TX and my own code (assembled from different sources - hexfet's Deviation module and couple of Arduino PPM modules).

CX-10 bounds on channel 2, which translates to channel frequency 2402MHz. I have HackRF Jawbreaker SDR with which I captured the signal.

CX-10 TX transmits a packet every 1.5ms with center frequency 2402MHz and width approximately 1.2MHz at -30dB which seems to be normal for 1Mbps.

My code uses nRF24L01+ and transmits packets with center frequency 2402.2MHz! and probably slightly wider in bandwidth.

I checked the available literature and it never mentions this 200KHz deviation.

I am not so sure about calibration of HackRF, it can be other way around- nRF24L0+ transmits on 2402MHz, and XN297 on 2401.8MHz, but other than this it's very clear difference in center frequency of 200KHz.

At 1Mbps it can easily be the reason of incompatibility of these chips, and without knowledge about "debug" registers of nRF we will not be able to compensate for it.

It would be great if someone with more precise instruments can confirm this.

victzh wrote: I've got very strange results comparing original CX-10 (green board) TX and my own code (assembled from different sources - hexfet's Deviation module and couple of Arduino PPM modules).

CX-10 bounds on channel 2, which translates to channel frequency 2402MHz. I have HackRF Jawbreaker SDR with which I captured the signal.

CX-10 TX transmits a packet every 1.5ms with center frequency 2402MHz and width approximately 1.2MHz at -30dB which seems to be normal for 1Mbps.

My code uses nRF24L01+ and transmits packets with center frequency 2402.2MHz! and probably slightly wider in bandwidth.

EDIT : in the section 5.2 of the nRF24L01+ documention, you hade DeltaF_1M = 160Khz of deviation.... Can be set ? somewhere ?

I checked the available literature and it never mentions this 200KHz deviation.

I am not so sure about calibration of HackRF, it can be other way around- nRF24L0+ transmits on 2402MHz, and XN297 on 2401.8MHz, but other than this it's very clear difference in center frequency of 200KHz.

At 1Mbps it can easily be the reason of incompatibility of these chips, and without knowledge about "debug" registers of nRF we will not be able to compensate for it.

It would be great if someone with more precise instruments can confirm this.

Damned for 200Khz versus 2402Mhz so a deviation of 1/1000 is enough to desynchronize everything ....

Look section 5.2 of the nRF24L01 documention .... Devation at 1Mbits is 160Khz ....

That frequency deviation is a bit different - it means how much the central frequency varies to signify 0 or 1. So say with central frequency 2402MHz 0 would be marked by emitting 2401.84MHz and 1 by emitting 2402.16MHz. There is no mention in documentation that the frequency can be systematically shifted by 200KHz.

On the other hand 200KHz is 83ppm deviation at 2.4GHz. It means shitty crystal, but for module for $3-5 bucks they can easily use 100ppm crystal.

My other experiment with Beken 2421 module is even more puzzling - it holds frequency correctly, but no binding happens.

All of it does not matter

I finally demodulated the binding packets using an excellent HackRF Jawbreaker and Gnu Radio. I used www.inguardians.com/pubs/GRC_signal_analysis_InGuardians_v1.pdf as a guide.

The results are the following: if I use my own code and both nRF24L01 and Beken 2421 I can successfully demodulate the signal and can see preamble (0xAA), the address (five 0xCC bytes), and following packet bytes.

If I try to demodulate XN297 I can see some demodulated signal which coincides with the radio signal but have no such well defined structure - I can't see the preamble and address - just some bytes arbitrarily appearing.

I will look at it more - I have an impression that it is passed through some scrambler. It is untypical to do so - usually only the contents of the packet is scrambled and preamble and address are as is.

The difference is minimal - One is a production version, with components moved around, RF cage is designed in (not populated), RF cleaned up a bit, no 900MHz antenna on board (which you needed to isolate by desoldering a bridge anyways), plastic case, reset button, LEDs in a convenient place, extension pinout.

Jawbreaker is the last beta - fully functional, but less convenient. It lives in an antistatic bag and I get it out of it and put on antenna and USB every time I need to use it. On the other hand, I've got it for free as a part of the beta program - who am I to complain

I was not very lucky with XN297 so far - I soldered to CX-10 green TX and tried to isolate the MCU so that I can use it with my own code but keep an ability to switch back to the native code to keep the baseline for comparison. This approach fails - the other elements on the TX board feed MCU enough to interfere with my code.

I ordered another CX-10 - and got a red version! So, I'm waiting for Eachine H7 which is guaranteed to have XN297 in it in a detachable form.

Next I plan to first make my code work with CX-10 green and Eachine's XN297 and make a comparison RF traces of biding sequence with XN297, Beken, and Nordic. CX-10 binding is luckily uses one RF channel so it's easy to catch. I can publish these traces for analysis - just set up GNU radio and you can read it from file. You don't need HackRF or any other SDR for this.

CX10 would be the holy grail for me as I have one of those. So surprise it still hasn't been deviated yet. LOL

Always appreciate you guys developing and continuing to push Deviation forward.