SKEYE mini drone

I just got one of this. after opening remote up i can see RF module (i'll upload picture later). however with the black dot on it, so i cannot read its name (any idea how to remove that in a clean way ? )
i am guesing its nrf24l01 (or something compatible).

i connected logic analyzer and tried to decode the SPI.

init:

07 00 29 00 28 00 27 77 26 22 25 10 24 00 23 03 22 00 21 00 20 4E 1D 00 50 73 07 00 50 53 20 40 4B 01 E2 21 C0 4B 00 00 22 D0 FC 8C 02 23 99 00 39 21 24 D9 96 8A DB 25 24 06 0F B6 26 00 00 00 00 27 00 00 00 00 28 00 00 00 00 29 00 00 00 00 2A 00 00 00 00 2B 00 00 00 00 2C 00 12 73 00 2D 36 B4 80 00 2E 41 20 08 04 81 20 CF F7 FE FF FF 07 00 50 53 00 00 30 AB AC AD AE AF

after init process is complete transmiter keeps sending this until stick is moved up and down:

25 XX A0 A1 F4 30 57 47 AA AA BB B1 D4 (8 times)
25 XX A0 0A 1A 2A 3A 12 22 32 42 B1 46 (8 times)

xx: keeps changing

binding:

07 00 29 00 28 00 27 77 26 27 25 10 24 00 23 03 22 00 21 00 20 4E 1D 00 50 73 07 00 50 53 20 40 4B 01 E2 21 C0 4B 00 00 22 D0 FC 8C 02 23 99 00 39 21 24 F9 96 8A DB 25 24 06 0F B6 26 00 00 00 00 27 00 00 00 00 28 00 00 00 00 29 00 00 00 00 2A 00 00 00 00 2B 00 00 00 00 2C 00 12 73 00 2D 36 B4 80 00 2E 41 20 08 04 81 20 CF F7 FE FF FF 07 00 50 53 30 47 57 30 F4 A1

then the regular packet starts being transmitted :

25 XX (this is sent first, XX is changing)
A0 UP FB RR LR CC FM FL TR CRC1 CRC2

where:
UP: 0-FF (going up)
FB: 0-7F forward
90-FF back
RR: 0-7F: rotate left
80-FF: rotate right
LR: 0-7F left
80-FF right
CC: 0x40 : capture foto
0x80 : start/stop video
FM: 0x40 : normal flight mode
0x80: fast flight mode
<--- trim for forward/backward is also included (ORed with the above byte)
FL: 0x40: flip
TR: trim for left/right
CRC1 & CRC2 : crc bytes



so its 13 byte package.

does deviationTx already support some similar protocol ? (nrf24l01 with 13 byte packet, ordered as above ... i am hoping this quad is using some protocol already supported by deviationTX

any idea what the first two bytes do ? (why second byte keeps changing ? )


i hope some somebody can help me out with this.

ppisljar wrote: I just got one of these. after opening remote up i can see RF module (i'll upload picture later). however with the black dot on it, so i cannot read its name (any idea how to remove that in a clean way ? )
...

Epoxy will usually succumb to a little heat. Go to youtube and search for 'remove epoxy from circuitboard'. There are a number of examples there. A little heat and some judicious prodding with a knife or some such. Try not to damage the surface you're trying to read.
A wooden tool might be safer.

packet is transmitted every 5ms

Hmm ..... seems i have a bad connection with SPI .... any idea what should be the responses ?

i saw response bytes 0E and 2E .... but then sometimes it all goes crazy and i get response bytes 07, 17, 47 ...

i am guesing 2E is the right one ... and when i start getting others i try moving the wires a bit .... most of the time i can get back to 2E responses.

or could it be that just my SPI decoder is messing it up? what do you use for decoding SPI ? (i am using usbee AX test pods logic analyser with builtin SPI decoding)

anyway i recorder the poweron sequence again (i think it was wrong in the previous post)

this is the start of it : ( i recorder this part 5 times and it seems to be always the same )

SDO: 07 00 29 00 28 00 27 77 26 22 25 10 24 00 23 03 22 00 21 00 20 4E 1D 00 50 73 07 00 50 53
SDI: 0E 0E 0E 00 0E 00 0E 00 0E 00 0E 00 0E 00 0E 00 0E 00 0E 00 0E 00 0E 00 0E 00 0E 0E 0E 00

and then this comes:

20 40 4B 01 E2
8E 00 00 00 00

21 C0 4B 00 00
8E 00 00 00 00

22 D0 FC 8C 02
8E 00 00 00 00

23 99 00 39 21
8E 00 00 00 00

24 D9 96 8A DB
8E 00 00 00 00

25 24 06 0F B6
8E 00 00 00 00

26 00 00 00 00
8E 00 00 00 00

27 00 00 00 00
8E 00 00 00 00

28 00 00 00 00
8E 00 00 00 00

29 00 00 00 00
8E 00 00 00 00

2A 00 00 00 00
8E 00 00 00 00

2B 00 00 00 00
8E 00 00 00 00

2C 00 12 73 00
8E 00 00 00 00

2D 36 B4 80 00
8E 00 00 00 00

2E 41 20 08 04
8E 00 00 00 00

(first line output, second line input)

i wrote some comments based on : dl.dropboxusercontent.com/u/2248531/blog/HCD/HCD_init.txt


07 00 // read status
29 00 //-Write to carrier detect ??
28 00 //-Write to packet counter ??
27 77 // clear status register
26 22 // NRF24_REG_06_RF_SETUP = NRF24_PWR_m12dBm | NRF24_RF_DR_LOW
25 10 // set base rf chan ?
24 00 // retransmit rate ?
23 03 // 5 byte data length
22 00 // ?
21 00 // disable auto Ack ?
20 4E // NRF24_REG_00_CONFIG = NRF24_MASK_RX_DR | NRF24_EN_CRC | NRF24_PWR_UP
1D 00 // -read NRF24_REG_10_TX_ADDR ?
50 73 // -ACTIVATE: R_RX_PL_WID, W_ACK_PAYLOAD, W_TX_PAYLOAD_NOACK
07 00 // read status

50 53 // select register bank 1
20 40 4B 01 E2 // same as HCD_init
21 C0 4B 00 00 // same as HCD_init
22 D0 FC 8C 02 // same as HCD_init
23 99 00 39 21 // same as HCD_init
24 D9 96 8A DB // gets different from here on
25 24 06 0F B6
26 00 00 00 00
27 00 00 00 00
28 00 00 00 00
29 00 00 00 00
2A 00 00 00 00
2B 00 00 00 00
2C 00 12 73 00
2D 36 B4 80 00
2E 41 20 08 04
81 20 CF F7 FE FF FF

07 00 // read status
50 53 // select register bank 1

00 00 30 AB AC AD AE AF

bind procedure seems to be almoust the same is init ... the only difference is the TX address that is set on the end (and two other small differences)

07 00
29 00
28 00
27 77
26 27 (init: 26 22)
25 10
24 00
23 03
22 00
21 00
20 4E
1D 00
50 73
07 00
50 53
20 40 4B 01 E2
21 C0 4B 00 00
22 D0 FC 8C 02
23 99 00 39 21
24 F9 96 8A DB (init: D9 96 8A DB)
25 24 06 0F B6
26 00 00 00 00
27 00 00 00 00
28 00 00 00 00
29 00 00 00 00
2A 00 00 00 00
2B 00 00 00 00
2C 00 12 73 00
2D 36 B4 80 00
2E 41 20 08 04 81 20 CF F7 FE FF FF
07 00
50 53
30 47 57 30 F4 A1 (this is different from init)

i tried to update gooblish code for CX-10 to work with my quad .... :: pastebin.com/A0zsL0cJ

i am able to get the same output on SPI (i have logic analzer connected to confirm i am sending the right thing) as transmitter is sending

- init section decodes to same bytes
- i skip the section between init and bind (seems its broadcasting its address? )
- bind section decodes to same bytes
- i keep sending normal package every 5ms

one thing that is different is the SPI frequency. one period on my transmiter is 3.5us ... but on my arduino its 1.2us ... however that should not affect what nrf24l01 transmits ... its just getting the info faster.

the other thing is that 5ms between packets is a bit too much ... on transmiter its a bit shorter ... 4.4ms or sth like this. (in my opinion this is not game breaking either ?)

however binding is not succesfull. i have no idea how to debug this further ? (as i am already getting same bytes on SPI ... i tought thats it ... it will work ) any tips would be most welcome.

maybe someone who already decoded some similar protocol could help ?

thanks

i updated the code to also transmit the part betwen init and bind ... i think its transmitting its address .... and i added channel hopping.

pastebin.com/SE43Ck5G


my quads batters is empty ... will test in 30 minutes. but i dont think it will work. i am thinking:

the chip is not nrf24l01 ... its the BK2421 ( i guess this based on this "magic value part" transmitted over SPI, which is almoust identical to the symax_nrf24l01 driver )
i am trying to send exact copy of what transmiter is sending. but since i am working with nrf24l01 i need to do something different ? (like i could leave the "magic" thing out ... ? )

pastebin.com/vCqMqavY

its working now ... i got it to bind

i still have one problem. how to correctly calculate crc code ? (not the CRC send over the network ... but CRC byte inside the packet itself)

any tip would be greately appreciated.

actually i found out how to calculate checksum (same as symax_nrf24l01)

updated code: pastebin.com/90q7dKKU


however i still dont get past binding process. (instead of sending empty packet i start sending full speed up ... no movement)

nah ... just errors in my code its working now ok ... here is latest version:

pastebin.com/7RCM8MnV

it works ... but not 100% correct.

what i see is that its VEEERY unresponsive. when i move my pot it takes anywhere from 0.1 to 1seconds to actually take effect.

any idea what could be wrong ? i tried disabling frequency hopping but i more or less same result. (my guess was freq. hopping because it looks like every 10th command is registered by quad ... ) ... was thinking something is wrong with CRC ... but have no way to validate it ?

was just another bug in my code. now its actually working as it should.

Nice work. Were the differences from CX10 small enough that you could add an option to that protocol to support the SKEYE?

could probably work, yes.