Search Results (Searched for: cx-10)
- alibenpeng
SOLVED: CX-10 binds but does not ACK packets
Category: Protocol Development
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:
0xa0, 0x2a, 0x03, 0xc2, 0x11, 0x56, 0xaa, 0x40, 0x00, 0xbf- 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.
- SeByDocKy
SOLVED: CX-10 binds but does not ACK packets
Category: Protocol Development
- hexfet
SOLVED: CX-10 binds but does not ACK packets
Category: Protocol Development
- alibenpeng
SOLVED: CX-10 binds but does not ACK packets
Category: Protocol Development
- SeByDocKy
- billmester
- billmester
JD 395 cx-10
Category: Protocol Development
1. turn on quad 1
2. turn on quad 2
3. turn on original tx
4. binding process (up-down)
5. both stop blinking, both fly
- btoschi
- billmester
JD 395 cx-10
Category: Protocol Development
if i turn on both quads, and then run the binding sequence, both will fly the same time
so the binding does not have unique pairing code...
- SeByDocKy
- SeByDocKy
- SeByDocKy
JD 395 cx-10
Category: Protocol Development
....There is absoluptly no response of the quad
I will make a short videoYes the JXD 395 can fly the CX-10 "green" and vice et versa ...
hexfet wrote:
SeByDocKy wrote: Sorry but I can't bind my JXD 395 with
What sequence did you use to try to bind? I set the protocol to stay in bind mode for 6 seconds. You'll need to turn on the quad during that time, or try turning on the quad and then hit re-init.
Is there any response from the quad, or does it behave just like there is no transmitter?
Possible issues I can think of:
- mistake in the coding
- missed something in the bind capture data
- XN297 not compatible (maybe something to do with the 3 undocumented registers)
- Are we certain CX10 protocol is same as JXD395?
- billmester
JD 395 cx-10
Category: Protocol Development
Now I have 2 working micro quads!!!
(It was worth to wait...)
- hexfet
JD 395 cx-10
Category: Protocol Development
SeByDocKy wrote: Sorry but I can't bind my JXD 395 with
What sequence did you use to try to bind? I set the protocol to stay in bind mode for 6 seconds. You'll need to turn on the quad during that time, or try turning on the quad and then hit re-init.
Is there any response from the quad, or does it behave just like there is no transmitter?
Possible issues I can think of:
- mistake in the coding
- missed something in the bind capture data
- XN297 not compatible (maybe something to do with the 3 undocumented registers)
- Are we certain CX10 protocol is same as JXD395?
- SeByDocKy
- mtx63
- SeByDocKy
JD 395 cx-10
Category: Protocol Development
hexfet wrote: Here is a build for the devo10. Got past my emulator issues and fixed a couple problems. The post with the diff has been updated.
Took a closer look at the MoonTop capture. It uses the same RF chip initialization, but different bind sequence and data packet format. If this CX10 works I'll look at adding an option for the moontop.
Sorry but I can't bind my JXD 395 with
... - hexfet
- billmester
JD 395 cx-10
Category: Protocol Development
I bought a CX-10 with a dead board (green). BG sent me a replacement board (red). Not binding with the original TX. (Reading this thread, now I understand why
) Then BG sent me a complete new set (on the way).So I will have a "red" CX-10 as "BNF", and a complete "green" one.
I hope the latest Deviation release will support both
(and I'll have some time and luck to install the new module in the D10...)
bm
- SeByDocKy
