C-17 Transport

I really have absolutely no idea what i am doing... I did get some values and i upload the pics. Most of the time the second line numbers were changing fast. If i need to redo the tests, please tell me some more details what to do.

Is that still in bind mode or after binding (I don't know the c-17 bind procedure, throttle up down?)

Moeder wrote: Is that still in bind mode or after binding (I don't know the c-17 bind procedure, throttle up down?)

Yes, it binds with throttle up, and then down. The first line seems to be stable then. When moving the right stick, the second line changes all the time. If i must redo the test, please instruct me what to do exactly.

Bind is on channel 67 for V2 (2 is V1).

And also keep the tx in bind mode, so power it up without moving throttle down again, so it won't finish bind.
@planger address seems to be exactly the same for this tx...so only rf channels somehow sent in bind payload?

First pic is before binding, second is after binding, the third is what chanel 2 shows.

Unfortunatelly the protocol doesn't seem to bind to the plane, V1 or V2 variants. I tryed both. What esle can i try?

I'm surprised of the channel numbers...
@Goebish: with my nrf24l01 (multi module) I'm getting a lot of false positive on a lot of channels with this remote control. When I say false positive, I'm getting data with good CRC but this is not the main channel being used just an echo/ghost. Here is an example
channel nbr frames
0 30
2 141
5 251
9 9
15 136
20 24
22 144
25 213
29 4
33 29
35 77
39 48
45 147
49 50
55 6
59 109
65 63
6D 140
7B 1
7C 7
In this example 5 and 25 are the real ones. All the others are artifacts...
Pascal

Fer wrote: First pic is before binding, second is after binding, the third is what chanel 2 shows.

Ok the fist picture is a bind. Your TX ID is 67 0F 00 69.
I would widely guess that the "real" channels being used are 6 and 26, can you force that and see if you receive something?

Moeder wrote: And also keep the tx in bind mode, so power it up without moving throttle down again, so it won't finish bind.
@planger address seems to be exactly the same for this tx...so only rf channels somehow sent in bind payload?

Everything before was normal packets: 00 20 1F ... 00=THR, 20=AIL, 1F=TRIM....
If you refer to the NRF address yes it's always the same.
What's changing is:
- the payload crc since the xor seems to be based on rx_tx_addr[0]^rx_tx_addr[1]^rx_tx_addr[2]. We can test that easily with one of the captures.
- the 2 frequencies
Pascal

Let me post two more pics that i know what are showing now. First one is while in bind mode (the stick is up, and haven't put it down yet), the second is after i lower the stick.

Fer wrote: Let me post two more pics that i know what are showing now. First one is while in bind mode (the stick is up, and haven't put it down yet), the second is after i lower the stick.

That confirms the TX ID in bind mode. But can you force in normal mode (after bind) the channel you are looking at to 6 and 38 to see if you are receiving packets?

@Fer Great.Now we need the actual channels used. I suggest putting some distance ( a couple of meters at least) between the C-17 tx and your devo then run the scan and write down the channels which have valid crc packets. it should only be 2 or 4 channels really. If you get more, try increasing the distance between the txs.

@planger first bind payload packet seems to contain first channel

Ok, here we go. First is before bind, second after bind. Now the only other channels it seems to find are 54 and 22. I attach the pics. The second raw keeps changing in channels 54 and 22. (The pics were not uploded in the order i described, but it is easy to see which is which).

I understand that you may want to see the rx. I managed to remove the hatch with minimum damage. Here is the rx in two pics.

Fer wrote: I understand that you may want to see the rx. I managed to remove the hatch with minimum damage. Here is the rx in two pics.

The only difference between the 2 receivers is the antenna. V1 has a dipole, V2 is a simple wire.

Fer wrote: Ok, here we go. First is before bind, second after bind. Now the only other channels it seems to find are 54 and 22. I attach the pics. The second raw keeps changing in channels 54 and 22. (The pics were not uploded in the order i described, but it is easy to see which is which).

Ok 22 and 54 looks good to me since 22+0x20=54 so they are keeping the same channel separation.
So know what's the rule to go from these 4 bytes 67 0F 00 69 to 0x16 or 0x36.
It might be only my &0x0F in the channel calc let's see.

ok so the payload xor works with this ID as well using payload_xor = rx_tx_addr[0]^rx_tx_addr[1]^rx_tx_addr[2] = 0x68
Just need the channel calculation now to work

@Goebish
The bind does not work because you haven't changed for V2 the bind freq line 230:
NRF24L01_WriteReg(NRF24L01_05_RF_CH, GD00X_RF_BIND_CHANNEL); // Bind channel

it should be instead:
NRF24L01_WriteReg(NRF24L01_05_RF_CH, sub_protocol==GD_V1?GD00X_RF_BIND_CHANNEL:GD00X_V2_RF_BIND_CHANNEL); // Bind channel

Ok the channles could be calculated by doing this:
channel1 = (0x15+rx_tx_addr[0]^rx_tx_addr[1]^rx_tx_addr[2]^rx_tx_addr[3])&0x1F
channel2 = channel1 + 0x20
I was not far off with my first assumption.