Advanced Search

@goebish,
I tested again again the 4in1 module with last multiprotocol code.
Now it is binding ok Hubsan and Cx-10 blue
There were some modifications in the main code and a bug fix on CX10.
Remembering back I used before V911 module which has only PA and working ok with Hubsan(Hubsan original has Rf module with PA only).
So it remain to fix in 4in1 module full range Hubsan telemetry(LNA),which can be done as a HW hack on existing module.

Cut a trace from 4042 chip pin 12 to Vcc and solder one wire from the same pin12 to A7105 GIO1.

I have been using the CX-10 (Blue board) file, kindly posted by ursus69 in this thread:

www.deviationtx.com/forum/6-general-disc...nd-devo-7e-deviation

It works for me, with my Devo 7E (3x2 switch mod), in that the rates are on SW B (there is no headless). You can arm the motors by holding the left stick to the bottom-left while putting the right stick to the bottom-right.

Don't try flips with this - it won't end well.

Not sure if you can activate the camera with this.

I would really like to assign throttle hold to HOLD1 for this model, but I haven't worked that out yet.

xJustiinsane wrote: Cool! I ordered an 7E couple weeks ago. I'm waiting for that to build that module in. I'd like to get one from the Cheerson CX-10 controller, is that the same? (Same protocol, yes, but does harvesting work the same and how?)

That transmitter you would have to cut the actual PCB the module is on, and I'm not even sure it's harvestable just like that... you're probably best getting a new module because you can get the nRF24L01+PA+LNA which has a power amplifier which will give you a lot more range, as well as being compatible with a lot more models because it is the "+" version.

Cool! I ordered an 7E couple weeks ago. I'm waiting for that to build that module in. I'd like to get one from the Cheerson CX-10 controller, is that the same? (Same protocol, yes, but does harvesting work the same and how?)

Yep. Nasty and appreciated.

Figured out the scrambling, still working on the crc part... and possibly transmitting commands from the RPi.

Imagine how mind bending it was to figure it out

Yay, I am detecting when the TX is on... I can see it bind, and I can see the channels it ends up using...

Now I'm going to see if I can understand the payload and maybe transmit to the quadcopter - the xn297 emulation is a bit brain bending.

Ok that makes sense - so I now my devo has all 30 model spots again
But now Why do you think when I try and click on a protocol n it doesn't have like sub protocols now. like cx-10 when you click would show you- red or blue or what not
Now it doesn't show anything on any I click

There are usually two ways of addressing a specific device over shared channel. Either use different address, or put TX ID into the body of the packet. I'd doesn't matter which way in particular is used, in the former case the radio chip handles it, in the latter - main processor. Another way to distance competing radio transmissions is to use different frequency hopping patterns. So in reality several devices even using the same hardware address coexist without much interference.

Well, that's a special flavour of awesome. Thanks, that helps incredibly.

I beleive that I've seen those address bytes - will confirm when I'm back in front of my testing rig - helps a lot to know what you are looking for. I would imagine that two newer cx-10 units wouldn't coexist nicely due to address clashing... If so, that seems like a design flaw by the manufacturer. Ah well.

I've written code for a CX-10 receiver, to be incorporated into Cleanflight at some stage. See github.com/martinbudden/cleanflight/blob...main/rx/nrf24_cx10.c

To briefly answer your questions, the CX-10 receive address you should listen on is {0x49, 0x26, 0x87, 0x7d, 0x2f} (this is address {0xcc, 0xcc, 0xcc, 0xcc, 0xcc} converted by the XN297 transmitter used by the CX-10)

The CX-10 binds to its transmitter using channel 0x02, but once it is bound it channel hops on 4 channels determined by the bind process. The hopping channels are set as:

// The hopping channels are determined by the txId
STATIC_UNIT_TESTED void setHoppingChannels(const uint8_t* txId)
{
rfChannelIndex = 0;
rfChannels[0] = 0x03 + (txId[0] & 0x0F);
rfChannels[1] = 0x16 + (txId[0] >> 4);
rfChannels[2] = 0x2D + (txId[1] & 0x0F);
rfChannels[3] = 0x40 + (txId[1] >> 4);
}

So if you listen on the 16 channels starting at 0x03 you should eventually receive something.

You'll also need to set the NRF24L01 data rate to 1Mbps and set auto acknowledgment off. See my routine cx10Nrf24Init

IIRC, cx-10 uses XN297, we implemented emulation layer for this. So CCCCCCCCCC address actually translated to something else. And every other payload byte as well. Look into implementation of the emulation layer for the details. It's in src/protocol/spi/nrf2401l.c

victzh wrote: You're not going to detect the "drone" itself, unless it has telemetry. You're sniffing controlling signal from TX.

True enough - but for the sake of the project, I might as well say I'm detecting the quadcopter...

Basic approach - look at the source of the corresponding protocol, it has initialization parameters which define radio mode - basically data rate and addresses.

Have been looking at code - various sources - I will have a look at cx10_nrf24l01.c more closely though... am I correct in assuming that 0xCCCCCC from:is the address I should be looking for? ...or does that change?

Also it has frequency hopping algorithm, they can be non-trivial.

Now there's a point - is that where my confusion regarding channels is coming from? Does it (specifically the CX-10 blue/new-red) select different ones each time?

Thanks for the response, btw!

You're not going to detect the "drone" itself, unless it has telemetry. You're sniffing controlling signal from TX.

Basic approach - look at the source of the corresponding protocol, it has initialization parameters which define radio mode - basically data rate and addresses.

Also it has frequency hopping algorithm, they can be non-trivial.

Hey All,

Long story short - I'm doing a tech project for a course I'm doing towards my masters degree... I'm doing a proof of concept "drone detector" - just need to show that I can detect the presence of one type of quadcopter in the local area.

I had originally ordered an A7105 board and compatible quadcopter from dx.com... but a comedy of errors ensued and I still don't have the parts (2 months later and mostly due to Canada Post).

So, I recently ordered an nRF24L01 and cx-10 from an online shop that could get it to me next day... Joy and bliss, it's a red board... oh wait, there's a newer red-board that's just like the blue board apparently. Thus, I wasted a precious day thinking I should be looking for YD-717 RF traffic.

I do have the nRF24 (connected to a raspberry pi) working along the lines of Travis Goodspeed's promiscuous hack - so I am seeing RF, but of course, I wasn't seeing what I was expecting to see.

Now, to the meat of the matter - what should I be looking for and on what channels? I've read different things (look for address CCCCCCCC or something else, on channel 0x02... no cycling through 0x08, 0x1E, 0x33 and 0x40... no 0x16, 0x33, 0x40 and 0x0E... no 0x41, 0x0A, 0x1E and 0x2D...)

The documentation on the YD-717 protocol was awesome - but I can't find anything definitive like that for the new cx-10 protocol.... which doesn't even have a name it seems.

Any pointers would be appreciated. If I have to, I'll find a logic analyser and do SPI sniffing, but my time is short on this (read days now, not weeks) so if anyone can give me pointers or a more definitive resource... I'd be very appreciative.

Thanks in advance,

Ron

Hey guys, I'm hoping someone can point me at any documentation for the "new" cx-10 red board protocol...

I'm playing with a nrf24 board on a raspberry pi, and I'd like to look at sniffing the packets sent to the cx-10 - any info would be appreciated.

Also, I have to say that the treasure trove of information I've found on these forums, the rcgroups forums and the associated github/bitbucket accounts of users here... has been very helpful and educational.

Thanks in advance - Ron.

got it flyin awesome!

ok I just read the blue board protocol, ill try that

hi I know this is an old post, I hope you see it, I have devo 7E modded I can bind my cx10 but cant seem to bind my cx10A
what protocol should I be using for the cx10A thank you

No, it's not all available data We know how its registers work, we know what it actually transmits over the air. This is much more important for its usage than various temperatures and dimensions.

But your document is very nicely done