SOLVED: CX-10 binds but does not ACK packets

Hi,

I'm trying to port a few nRF24L01 based protocols to a standalone module (AtMega328). Right now I'm stuck with the YD717/Skywalker protocol:

I have a Cheerson CX-10 (red PCB version with BK2421) that binds to the TX but doesn't ACK the bind packet (or any other for that matter), so that the state machine in the TX never reaches the YD717_DATA state. Instead it keeps sending bind packets with the occasional data packet (every ACK timeout?) inbetween. The data packets are understood (kinda) by the CX-10, but with a data packet only every second or so (I haven't measured) it's hopeless trying to fly the thing.

What I have done so far:

I sniffed the SPI bus of the stock TX and found out the following:

- The stock TX uses an almost exactly identical init sequence to the one in the YD717 protocol, except for the BK2421 specific register setting.

- The stock TX uses slightly different SPI commands for reading registers: Instead of 0xFF as the second bute transferred it uses 0x00. Tried it but doesn't seem to make a difference.

- The payload is 9 bytes long and always has 0xBF as the last byte. Not so sure about the last byte bit, though.

- The binding sequence seems to differ quite a bit from the YD717 one: Before sending an actual bind packet, the stock TX sends this packet 60? times:Only after that the 0x65... RX/TX address is written and the bind packet is sent.

- The bind packet also is slightly different: Instead of 0x32 it has 0x40 as byte[6].

I've tried altering everything I could to reflect the stock TX, but I wasn't able to get an ACK packet back from the CX-10 (an ACK on the SPI bus would look like 0x2E in the status register, right?)


What else (short of actually sniffing the 2.4GHz band with SDR) could I do to find out what's going on?


Cheers,

Ali



P.S.: Great project (although I don't have a Devo TX), your work on protocol reversing/implementation is invaluable!

Edit: problem solved, see last post.

Some users have reported flying the CX10 red board successfully. Wonder if there are different models?

Since the CX10 responds to data packets it seems likely the bind was successful but not recognized by the tx because the CX10 never acknowledged the packet after the bind. How's the antenna on the CX10? Maybe your radio device has a problem receiving?

Does the CX10 indicate a successful bind in any way (LED or beeps) so you would know if it bound? You could try changing the code to go into data mode after bind regardless of whether an ack is received.

- The data sent by the master when reading is irrelevant. Has no effect on the radio device.

- 0xbf is the correct checksum for the data in your post. Is the last byte different on the bind packet? Seems likely the last byte is a checksum.

- The YD717 and Skywalker stock TXs differ in the data sent during binding. The YD717 binds successfully using the Skywalker data, so that's what I used in the protocol. It should also work for the CX10. The difference is that the Skywalker sends the bind data in every bind packet, while the YD (and it seems the CX10) send channel data until the very last bind packet. The Skywalker method seems more robust since the receiver only needs to receive one good packet to get the rx/tx address.

- Yes, a 0x2e status means the packet was acknowledged by the rx. Are you seeing a 0x1e status (timeout)?

- An SPI trace from the receiver might help you figure out what's going on.

The red edition is binding perfectly the YD717=>SkyWalker protocol ....

hexfet wrote: Some users have reported flying the CX10 red board successfully. Wonder if there are different models?

..or maybe I made some stupid mistake. Would certainly not be the first time

Since the CX10 responds to data packets it seems likely the bind was successful but not recognized by the tx because the CX10 never acknowledged the packet after the bind. How's the antenna on the CX10? Maybe your radio device has a problem receiving?

The XC10 seems alright, as I see lots of Acks in the SPI captures of the stock TX. The same goes for my transmitter module, which I successfully use with the crazyflie (stock protocol, with payload in Acks).

Does the CX10 indicate a successful bind in any way (LED or beeps) so you would know if it bound? You could try changing the code to go into data mode after bind regardless of whether an ack is received.

Yes, the bind is successful, the LEDs stop blinking and the CX10 (with about a second lag) responds to the remote. Also, I don't see a single Ack byte (0x2e) in all of the MISO captures I did. The lag is probably on account of the still running bind procedure, in which a data packet is sent, every now and then.

I'll change the code to do what you suggested and report back on the results.

- The data sent by the master when reading is irrelevant. Has no effect on the radio device.

I guessed, but I wan't sure. Good to know.

- 0xbf is the correct checksum for the data in your post. Is the last byte different on the bind packet? Seems likely the last byte is a checksum.

The bind packet looks like this:What's interesting, is that not only the bind packet, but a lot of the 0x40,0x80,0x40,... packets are ack'd.

- The YD717 and Skywalker stock TXs differ in the data sent during binding. The YD717 binds successfully using the Skywalker data, so that's what I used in the protocol. It should also work for the CX10. The difference is that the Skywalker sends the bind data in every bind packet, while the YD (and it seems the CX10) send channel data until the very last bind packet. The Skywalker method seems more robust since the receiver only needs to receive one good packet to get the rx/tx address.

The bind data being the 0x56, 0xaa, 0x32, 0x00?

- Yes, a 0x2e status means the packet was acknowledged by the rx. Are you seeing a 0x1e status (timeout)?

Exactly. The first two reads of 0x07 give 0x0e and the third gives 0x1e.

- An SPI trace from the receiver might help you figure out what's going on.

Might take a few days but I'll see to it.

hexfet wrote: You could try changing the code to go into data mode after bind regardless of whether an ack is received.

I just did that and the CX10 flies like an eagle! Well, more like a mosquito, really, but anyway, it flies!

I'm setting the phase to YD717_DATA instead of YD717_BIND3 when the counter in YD717_BIND2 runs out. Still no ACKs, but who cares, the damn thing flies!

Seriously, though: I still wonder what the cause of the mysterious absence of ACKs is.. But on the other hand, probably only a trace on the RX will show, and now that I can fly, I'm a bit less inclined to put a soldering iron to the CX10.

For now. At some point I'll want to add more protocos and will be forced to face the issue.

alibenpeng wrote:

hexfet wrote: For now. At some point I'll want to add more protocos and will be forced to face the issue.

Great

A little update on the issue:

The little hack mentioned above works, but has its quirks. I've never been able to go into "flip mode" and sometimes, especially after a crash, the quad goes crazy. Shooting off in any direction, random flips, stuff like that. So I can fly the quad but it's not really a lot of fun.

Then I acquired a Devo8s (which I absolutely love, btw) and that's when stuff got really weird. I put in another nRF24 module and it behaved exactly like the one in my module.
It binds the quad successfully but doesn't know it, and even the hack I did on my module works exactly the same (including the quirks).

Right now I can't come to any conclusion other than that both of my nRF24 modules are faulty or at least somewhat different to what everybody else is using. Which isn't total nonsense as I bought them as a pair quite a while ago. Or I made the same wiring error twice, and I really don't want to believe that.

PB mentioned somewhere that the nRF modules can be very sensitive to 5V, and come to think of it, both of my modules may well have been exposed to 5V a few times in the past.

I've ordered a whole set of new modules plus a bunch of multimodule boards, so I'll see how that goes.

Another update:

Turns out I had two faulty nRF24 modules with exactly the same fault. Must have been the exposure to 5V I guess, but I can't be sure.

Anyway, I received the new nRF24 module and it works as intended. Bind packets get ACKed now and I can also bind the crazyflie, which didn't work before.

The erratic behaviour of the quad stayed, but I'm confident that's fue to it having crashed a few times too often. Actually, after poking around a bit, I suspect that one or more solder joints on or around the IMU were bad, as reflowing the whole area around the MPU6050 seems to have fixed the problem.

So, case closed and lesson learned: Be careful not to connect 5V to your nRF24 module. Even if it seems to work at first glance it might still be broken in a less obvious way.

Thanks everyone for the support.

Glad to hear you got it sorted. Thanks for updating.

Being a beginner to deviation, this post may be just irrelevant (if so, I apologize).

A couple of days ago I received my first deviation-capable remote controller. In fact it is the 2nd receiver I ever bought by itself (and not as part of some RTF package, that is how much of a beginner I am). I decided to train myself on it using my toy quadcopters. The Syma X5SC worked fine especially after installing the settings found in another thread of this forum. So did my other Symas (X125S and an X5H) using default settings.

But the reason I write this here is that I read the part in the first message about the yd717 protocol and "sending bind packets with the occasional data packet (every ACK timeout?)". This seems to be related to the issues I had with my Attop yd719 Skyline, the next toy on the list.

Here I tried the yd717 protocol with various formats (yd717,Sky Wlkr etc) with ACK=YES. Many of the formats did bind with the quad-copter just fine, but controlling it was next to impossible: slow responses, extreme and erratic movements etc (I have a video on that). I messed a little with the mixer but to no avail. Then, while experimenting I turned ACK to NO in the yd717 options (after it the initial bind) and then the little thing was flying fine and perfectly controllable. Only problem was that with ACK=YES it does not bind when turned on. So now I do the initial bind with ACK=YES and then turn it to ACK=NO to fly it. Besides that, no issues. Since I know very little about those things, if there is a better way to do this it would be educational for me to know.

Cheers to all.

Not irrelevant - this is a bug. I have made a PR with a fix and once that's merged the nightly builds will not have this issue.

The Use A.ACK option was added recently to accommodate nRF clone chips that don't support auto-acknowledge correctly. This change missed updating the bind procedure, which uses auto-ack to skip binding if an already bound receiver is detected. The fix is to always go through the bind procedure when the option is set to No.

I've tested this with my yd717 and it fixes the issue you describe.

Thanks!

Thank you for the response and the information! Soon I will test it on the yd719 as well.