FQ777-124 Pocket Drone

More
11 Jul 2016 13:11 #51548 by victzh
Replied by victzh on topic FQ777-124 Pocket Drone
I decoded XN297 using SDR. I have started writing it up, but did not complete - it's easier to do something than document it properly. I can dig out unfinished document and my decoding scripts for GNU radio, and can answer questions.

Please Log in or Create an account to join the conversation.

More
11 Jul 2016 22:55 - 11 Jul 2016 22:55 #51563 by btoschi
Replied by btoschi on topic FQ777-124 Pocket Drone
Took me a while to get there: Gnuradio showing clearly visible signal from FQ777 (thanks victzh for the hint):



I 'just' installed gnuradio on my system plus compiled osmosdr from source
(fixing cmake issue with SWIG by renaming /usr/lib/x86_64-linux-gnu/cmake/gnuradio/FindSWIG.cmake )
and then followed this nice tutorial on sniffing NRF data with gnuradio:
www.bitcraze.io/2015/06/sniffing-crazyfl...io-with-hackrf-blue/

Decoding should be easy now, hope I manage to do that before summer holiday (four days left) ...
Attachments:
Last edit: 11 Jul 2016 22:55 by btoschi.

Please Log in or Create an account to join the conversation.

More
12 Jul 2016 23:22 - 12 Jul 2016 23:42 #51590 by btoschi
Replied by btoschi on topic FQ777-124 Pocket Drone
Just a small update:
First of all I found a bug in my code, setting address width of 5 bytes is required for this protocol.
But still some strange differences happen - decoding the graph above shows there is no '00' byte transmitted (zero bits after three spikes are throttle),
seems it gets mixed into the 'packet control field' (which also slightly differes from NRF representation) and 1 byte CRC is requested,
but packet on air is too short with that using NRF, thus I'm pretty sure CRC is different, too.

I'm almost sure these remaining issues can be solved by adding control field and CRC manually into bitstream (and maybe sending too much zero bits, transmitter should not care).

Victz told me that the spectral images always differ between different chips without any problems regarding acual decoding.

Current decoded NRF packet looks like this, thus very similar to FQ777:


I have added annotations, control field (?) looks wrong (I'm requesting NO_ACK, thus last bit should be set) and the following zeroes are missing in FQ777 (even that they are written to FIFO),
Attachments:
Last edit: 12 Jul 2016 23:42 by btoschi.

Please Log in or Create an account to join the conversation.

More
12 Jul 2016 23:39 #51591 by bikemike
Replied by bikemike on topic FQ777-124 Pocket Drone
Is there any way I can help out? I have two nrf24l01+ modules and one ssv7241 hooked up to arduinos that I can play around with.

I tried contacting the engineer at SSV but they haven't replied to me regarding the reserved registers and/or nrf24/xn297 compatibility. I also sent an email to the Nuvoton engineers but they don't know too much about the radio chip and the code they use was provided by SSV.

As I said earlier, I was able to receive and decode bayang protocol bind packets(from an h101 tx) on channel 0 with the ssv7241 but receiving data on other channels did not work. Is the center frequency different for other channels? Or is it doing some sort of encryption on other channels or with the address field? What about the sync byte? Is it 0xAA or 0x55? For some reason I can't get the ssv7241 to capture many packets in pseudo promiscuous mode (setting the adress to (0x00 0xAA or 0x00 0x55 and disabling checksum). It could be that the ssv7241 doesn't actually allow 2 byte addresses while the nrf24l01+ does?

Also, Is the data rate 2mbps for the FQ777-124 protocol?

Please Log in or Create an account to join the conversation.

More
12 Jul 2016 23:50 - 12 Jul 2016 23:58 #51592 by btoschi
Replied by btoschi on topic FQ777-124 Pocket Drone
For me it looks like the difference happens when using Enhanced (?) Shockburst format only.
Address and Sync bytes are the same (added annotations to NRF capture, same waveform on SSV7241).

Data rate is strange ('11' is reserved value), but seems to work similar on both, scale on waveforms is the same.
Quick'n dirty measurement on waveform gives around 240000 bits per second, thus the high bit dicates 250kbp here.

I'm writing 7 bytes of channel data (CRC should be added by NRF) yet,
My current init code for NRF is:
    NRF24L01_WriteReg(NRF24L01_00_CONFIG, 0x0c); // 1 byte CRC, PWR UP
    u8 rx_tx_addr[] = {0xE7, 0xE7, 0xE7, 0xE7, 0x67};
    NRF24L01_WriteRegisterMulti(NRF24L01_10_TX_ADDR, rx_tx_addr, 5);
    NRF24L01_WriteRegisterMulti(NRF24L01_0A_RX_ADDR_P0, rx_tx_addr, 5);
    NRF24L01_WriteReg(NRF24L01_01_EN_AA, 0x00);     // no AA
    NRF24L01_WriteReg(NRF24L01_02_EN_RXADDR, 0x00); // all RX pipes DISABLED
    NRF24L01_WriteReg(NRF24L01_05_RF_CH, 0x4D);
    NRF24L01_WriteReg(NRF24L01_1D_FEATURE, 0x04); // DPL, NO-ACK (confirmed on air)
    NRF24L01_WriteReg(NRF24L01_1C_DYNPD, 0x01);
    NRF24L01_WriteReg(NRF24L01_06_RF_SETUP, 0x26); // DR: 11 (reserved)
    // my addition ...    
    NRF24L01_WriteReg(NRF24L01_03_SETUP_AW, 0x03);   // Five-byte rx/tx address (confirmed on air)

Note that the ADDR transmitted in waveforms above is the actual TX id (transmitted in bind-packets) which is { 0x50, 0x39, 0x00, 0xE7, 0x67} on my TX.
Last edit: 12 Jul 2016 23:58 by btoschi. Reason: added note about ADDR

Please Log in or Create an account to join the conversation.

More
13 Jul 2016 16:41 - 13 Jul 2016 16:44 #51609 by bikemike
Replied by bikemike on topic FQ777-124 Pocket Drone
I did some more tests and found that the ssv7241 and nrf24l01+ seem to be somewhat compatible. I did not write to the ssv7241 reserved registers for these tests. Here's what I found:

ssv7241 set up as rx can receive data from nrf24l01+ on all channels but it seems that packets may be missed and certain channels miss a lot more.
nrf24l01+ set up as rx can receive data from ssv7241 on most channels (little or no data on 0,16,32,48,64,80,96,112 at 1mbps - notice a pattern?). also the data can be received on chan and chan+1.

bitrate seems to play a factor as well. 250kbps and 2mbps seem more reliable.
Last edit: 13 Jul 2016 16:44 by bikemike.

Please Log in or Create an account to join the conversation.

More
13 Jul 2016 17:43 #51616 by bikemike
Replied by bikemike on topic FQ777-124 Pocket Drone
BTW, I was not able to receive a bind packet on channel 0 (at address 0xe7 0xe7 0xe7 0xe7 0x67) from the fq777-124 transmitter using either the ssv7241 or the nrf24l01+ set up as a receiver.

Either I don't have something set up right or I need to write to the reserved registers before it will work.

Please Log in or Create an account to join the conversation.

More
14 Jul 2016 05:19 #51628 by bikemike
Replied by bikemike on topic FQ777-124 Pocket Drone

btoschi wrote: Data rate is strange ('11' is reserved value), but seems to work similar on both, scale on waveforms is the same.
Quick'n dirty measurement on waveform gives around 240000 bits per second, thus the high bit dicates 250kbp here.

NRF24L01_WriteReg(NRF24L01_06_RF_SETUP, 0x26); // DR: 11 (reserved)


I think that is incorrect. 0x26 is 00100110 with DR LOW at bit 5, DR HIGH at bit 3. So I think DR is 01 or 2mbps.

Please Log in or Create an account to join the conversation.

More
14 Jul 2016 16:38 #51638 by btoschi
Replied by btoschi on topic FQ777-124 Pocket Drone
We're both right ;)

I confused the RF_DR_HIGH - which is bit 3 in the register, thus zero when programmed with 0x26.
But RF_DR_LOW is set high, thus 'RF_DR_HIGH' 'is don’t care if RF_DR_LOW is set.'.
The 'bitvalues' in their datasheets are composed by 'DR_LOW' as high bit and 'DR_HIGH' as low bit (Just to confuse everyone :P )

This means that we have 250kbps datarate here, which is exactly what I measured.

As a note: I'm not quite sure if having I/Q values changes that,
but generally speaking sampling with 1Mhz bandwidth (RTL SDR cannot do more) cannot capture a 2MHz signal.

Please Log in or Create an account to join the conversation.

More
14 Jul 2016 16:56 #51639 by btoschi
Replied by btoschi on topic FQ777-124 Pocket Drone
Stumbled upon this:

bikemike wrote: BTW, I was not able to receive a bind packet on channel 0 ...


Channel zero is the wrong channel. 0x07, 0x27, 0x43 and 0x4d are the only channels used by FQ777 protocol.

Please Log in or Create an account to join the conversation.

More
14 Jul 2016 18:12 - 14 Jul 2016 18:14 #51641 by bikemike
Replied by bikemike on topic FQ777-124 Pocket Drone

btoschi wrote: Stumbled upon this:

bikemike wrote: BTW, I was not able to receive a bind packet on channel 0 ...


Channel zero is the wrong channel. 0x07, 0x27, 0x43 and 0x4d are the only channels used by FQ777 protocol.


Ok good to know. Which channel is the bind packet send on? Are many packets sent or only one? I was going off your capture in this post:

www.deviationtx.com/forum/protocol-devel...e?limitstart=0#43017

And it looked like it was setting channel 0 before sending a bind packet. I'm very new to this stuff so I'm probably reading it wrong.
3.25510 31 FLUSH_TX 
3.25522 32 W_REGISTER(RF_CH) 00
3.25534 33 W_TX_PAYLOAD 20 15 05 06 50 39 00 89 
3.25589 34 W_REGISTER(RF_CH) 4D
3.25602 35 W_REGISTER(STATUS) 70


Sorry about the bitrate mix-up. I should have read the datasheet more closely. :S
Last edit: 14 Jul 2016 18:14 by bikemike.

Please Log in or Create an account to join the conversation.

More
14 Jul 2016 20:43 - 14 Jul 2016 20:46 #51646 by btoschi
Replied by btoschi on topic FQ777-124 Pocket Drone
Yeah, thats right for the very first packet, but I'm not even sure if its send at all.
(CE must be held hight for at least 10µs to start actual transmission, you cannot see that in SPI traces).

The packet you see in the capture is send constantly on channels 0x4d, 0x43, 0x27, 0x07 all 2ms.
In another capture at 0.476s the first bind packet is send (next one at 0.478s using next channel),
and at 1.392s they reprogram TX_ADDR and start with real data transmission,
still using very same channel hopping sequence.
Note that these seconds are seconds from trigger of logic analyzer, which usually means 'powerup of mcu', thus the absolute value means nothing.

No problem with the bitrate, it always confuses me, too, I had to triple check that :)
Last edit: 14 Jul 2016 20:46 by btoschi. Reason: Note about seconds

Please Log in or Create an account to join the conversation.

More
14 Jul 2016 20:50 - 14 Jul 2016 20:54 #51647 by bikemike
Replied by bikemike on topic FQ777-124 Pocket Drone
Ok, I'm able to receive packets from the tx with both the nrf24l01+ and the ssv7241!!

I think the reserved registers somehow mangle the packets. Here I have set the reserved registers on the ssv7241 and it seems to decode the packets differently.

nrf24l01+:
BIND PACKETS (chan 7, address e7e7e7e767):
PACKET RECV: 22 50 28 B0 B9 DF 9A 15 17 2A 51 B6 A2 BA 6D A1 58 B4 A6 D8 41 4A 54 2A 88 A8 AA 52 A8 93 45 4E  
PACKET RECV: 22 50 28 B0 B9 DF 9A 15 17 2A 51 B5 42 D2 DA 42 55 95 4E A1 56 5B 4D 1D DA 5B BA A5 5A 95 89 A4  
PACKET RECV: 22 50 28 B0 B9 DF 9A 15 17 2A 51 8E B5 68 81 5A 82 D0 49 95 42 A1 49 53 1C 2C B9 4A 68 A9 51 52  
PACKET RECV: 22 50 28 B0 B9 DF 9A 15 17 2A 51 89 6D A2 4B 64 A1 41 49 30 8A A6 96 D3 B1 20 95 A6 AA D5 CB 5A  
PACKET RECV: 22 50 28 B0 B9 DF 9A 15 17 2A 51 A9 D6 AF BE F5 2B 95 BD D3 69 69 57 59 6B 57 7E AE EA DB ED 5E 

NORMAL PACKETS(chan 7, address d3 45 00 e7 67) :
PACKET RECV: 20 40 3B 2B 23 A6 18 95 60 30 4E 8B 75 AC C0 A9 33 52 1 25 2A 8A 94 59 51 D2 52 4A 12 C1 15 24  
PACKET RECV: 20 40 3B 2B 23 A6 18 95 60 30 4E B2 28 A9 BB C4 D4 DB 75 54 C9 66 65 70 12 9C AD 6D 52 B5 4B 55  
PACKET RECV: 20 40 3B 2B 23 86 18 95 0 6B A6 A9 16 C5 6B 6A 6A 16 AA 99 25 1A A2 35 4A A6 FA AD 45 32 B4 53  
PACKET RECV: 20 40 3B 2B 23 86 18 95 0 6B A6 AD 6B 19 45 5A 12 CA B7 95 DF AB D5 D2 5B AC B5 55 29 35 5B 7C  
PACKET RECV: 20 40 3B 2B 23 86 18 95 0 6B A6 A6 5A AA 66 82 A6 68 94 A5 2A CA 95 52 AA 11 5A 42 A2 45 1A 36  
PACKET RECV: 20 40 3B 2B 23 86 18 95 0 6B A6 B5 2A F2 D6 AF 53 36 9B 2A 6A AE D5 CA 9D 6E E6 E5 55 6D B5 5E

SSV7241 with reserved registers set:
BIND PACKETS (chan 7, address e7 e7 e7 e7 67):
PACKET RECV: A2 14 4C C5 D5 AE B0 23 6B DB 3F E6 B6 62 A0 87 40 16 A1 64 1E 2 80 16 C9 AA 69 18 DA 26 87 6C  
PACKET RECV: A2 14 4C C5 D5 AE B0 23 6B DB 3F EF F6 10 20 41 4A 12 4B 8B FB 30 4 9E CA B0 63 9 FE C1 17 29  
PACKET RECV: A2 14 4C C5 D5 AE B0 23 6B DB 3F DD C6 41 ED 72 C4 1A 49 8B 72 57 4F F2 FA 18 FE 98 FF C9 A1 7F  
PACKET RECV: A2 14 4C C5 D5 AE B0 23 6B DB 3F EB FE 24 F8 94 12 57 0 CF 84 25 C FC F9 39 6B 10 EF 16 A6 4B  
PACKET RECV: A2 14 4C C5 D5 AE B0 23 6B DB 3F FB D6 E4 BB 87 4 56 99 C9 96 27 CC 7F EB 29 E5 9B 9C 43 85 D  

NORMAL PACKETS(chan7 address d3 45 00 e7 67):
PACKET RECV: A0 4 5F 5E 4F D7 32 A3 1C C1 20 E9 67 77 E2 81 C0 6 9 89 CE 17 FC 14 E4 E 60 3B 3D C7 5B 7A  
PACKET RECV: A0 4 5F 5E 4F D7 32 A3 1C C1 20 E9 D4 DA 42 97 D4 1B 3 68 81 DF 8 D7 B0 68 2D 88 E9 77 A4 E9  
PACKET RECV: A0 4 5F 5E 4F D7 32 A3 1C C1 20 FD D2 62 23 EF 40 3B 5C ED AF 5 4A FB 40 6C 6B 0 3C E1 C4 3  
PACKET RECV: A0 4 5F 5E 4F F7 32 A3 7C 9A C8 EF E6 B2 91 C6 56 B2 11 99 3 B 2D 60 49 2C 73 1B F7 41 85 7A  
PACKET RECV: A0 4 5F 5E 4F F7 32 A3 7C 9A C8 E4 24 E6 81 86 80 76 30 EA 40 18 85 6B 3B 24 C 12 F0 41 CC 4F  
PACKET RECV: A0 4 5F 5E 4F F7 32 A3 7C 9A C8 C0 B4 D3 C8 83 A7 A F1 69 22 2 CA F6 62 68 DD A8 27 4C AD 2D  
PACKET RECV: A0 4 5F 5E 4F F7 32 A3 7C 9A C8 E9 D6 20 F0 9A 0 1A 0 E8 3B 4D BF C6 C0 21 65 6B EC 4E D9 2B  

I had to sniff for the address. I don't know how it is encoded into these bind packets?
Last edit: 14 Jul 2016 20:54 by bikemike.

Please Log in or Create an account to join the conversation.

More
14 Jul 2016 22:05 - 14 Jul 2016 22:07 #51657 by Multirotor Go
Replied by Multirotor Go on topic FQ777-124 Pocket Drone
I have been at the edge of my seat eating my nails, although I have never done that in my whole life! I don't understan anithing yo have been wrting but I am praying to the multirotors Gods, if this goes well is going to be so exciting, I am waiting with devo in my hands, good luck, and thanks
Last edit: 14 Jul 2016 22:07 by Multirotor Go.

Please Log in or Create an account to join the conversation.

More
14 Jul 2016 22:21 - 14 Jul 2016 22:23 #51660 by btoschi
Replied by btoschi on topic FQ777-124 Pocket Drone
Okay, that are great news ...

Address are the last three bytes before the checksum in the bind packet:
W_TX_PAYLOAD 20 15 05 06 50 39 00 89

Results in bind address 0x50 0x39 0x00 0xe7 0x67 (latter two bytes are the same as before).
And note: The 0x67 is the first byte on air, 0x50 the last one.

Your NRF bind packets all start with these bytes:
22 50 28 B0 B9 DF 9A 15 17 2A 51
That's (even adding 9 bits for shockburst header) way more than I would expect.
And I cannot see the 8 zero bits which are actually send in a bind packet
(or is your TX sending another payload ? can you sniff that ? Edit: Nah, your bind address is d3 45 00, thus 8 zeroes at the same place )

The SSV7241 also has eleven bytes which are constant over the sequence (the others are simply noise after end of transmission, you can omit these).
Do you have programmed the receiver with dynamic payload or shockburst / CRC enabled ?

The bytes are in fact somehow scrambled, but I can see a pattern here:
NRF 0x22 and 0x20 results in 0xA2 and 0xA0 (+0x80),
0x15 and 0x95 results in 0x23 and 0xA3 (+0x0e).
Looks like position dependent (de)scrambling, the 0x15 shows up as 0x23 and the following 0x17 as 0x6B.

But still the SSV should be able to receive the actual transmitted data, did you ever sniff the RX side if they are using different values for special registers ?
Last edit: 14 Jul 2016 22:23 by btoschi. Reason: Saw the bind address ;)

Please Log in or Create an account to join the conversation.

More
14 Jul 2016 23:14 #51670 by bikemike
Replied by bikemike on topic FQ777-124 Pocket Drone

btoschi wrote: Do you have programmed the receiver with dynamic payload or shockburst / CRC enabled ?

The bytes are in fact somehow scrambled, but I can see a pattern here:
NRF 0x22 and 0x20 results in 0xA2 and 0xA0 (+0x80),
0x15 and 0x95 results in 0x23 and 0xA3 (+0x0e).
Looks like position dependent (de)scrambling, the 0x15 shows up as 0x23 and the following 0x17 as 0x6B.

But still the SSV should be able to receive the actual transmitted data, did you ever sniff the RX side if they are using different values for special registers ?


I did not try enabling dynamic payload or crc yet. I just wanted to confirm that I could receive some sort of data. I will attempt to enable dynamic payload and crc this evening.

I do not have a logic analyzer so I can't sniff SPI. When I say I sniffed the address for my tx, I mean I set my nrf24l01+ to 'pseudo' promiscuous mode and then searched for 67 e7 packets.

But I don't think the rx and tx use different values for the reserved registers based on the Nuvoton quadcopter code. The ssv7241.c file for the tx and rx have same Initial_Reg_Array).

Please Log in or Create an account to join the conversation.

More
14 Jul 2016 23:57 - 14 Jul 2016 23:58 #51674 by bikemike
Replied by bikemike on topic FQ777-124 Pocket Drone

btoschi wrote: The bytes are in fact somehow scrambled, but I can see a pattern here:
NRF 0x22 and 0x20 results in 0xA2 and 0xA0 (+0x80),
0x15 and 0x95 results in 0x23 and 0xA3 (+0x0e).
Looks like position dependent (de)scrambling, the 0x15 shows up as 0x23 and the following 0x17 as 0x6B.


Looks like if you positionally XOR the NRF packet bytes with the following they are equal:
80 44 64 75 6c 71 2a 36 7c f1 6e

Maybe if you could post some packet data from the SPI traces we can find the pattern there too?
Last edit: 14 Jul 2016 23:58 by bikemike.

Please Log in or Create an account to join the conversation.

More
15 Jul 2016 07:04 - 15 Jul 2016 07:20 #51703 by bikemike
Replied by bikemike on topic FQ777-124 Pocket Drone
More to report. I tried enabling enhanced shockburst (dynamic payload length) but I wasn't able to receive any data on either chip. I may be doing something wrong.

Another discovery though. I tried not programming the reserved registers on the ssv and then the packet data matches the nrf. I also added enhanced shckburst parsing to my program and here is the result from the bind:
: len: 8, pid: 2, nack: 0, data: A0 51 61 73 BF 34 2A 2E 54 A3 25 24 90 9A 6A B9 65 4D 49 49 25 15 C2 95 A5 28 A5 21 5A 59  
PACKET RECV: len: 8, pid: 2, nack: 0, data: A0 51 61 73 BF 34 2A 2E 54 A3 A 35 49 13 29 75 53 5A B2 36 AB 6B 4A AA BA 5D 96 D2 77 D6  
PACKET RECV: len: 8, pid: 2, nack: 0, data: A0 51 61 73 BF 34 2A 2E 54 A3 49 15 3B 21 A2 A1 53 A2 49 64 97 32 D1 22 28 25 50 84 24 85  
PACKET RECV: len: 8, pid: 2, nack: 0, data: A0 51 61 73 BF 34 2A 2E 54 A3 29 68 94 D4 0 6A A1 61 50 50 E9 3A CB 28 42 8A 55 50 AA AA  
PACKET RECV: len: 8, pid: 2, nack: 0, data: A0 51 61 73 BF 34 2A 2E 54 A3 55 EA F5 D9 56 A7 B5 6D 6D 55 53 B5 1D B5 9A 92 5C A7 6E A9  

and from data packets:
PACKET RECV: len: 8, pid: 0, nack: 0, data: 80 76 56 47 4C 31 2A C0 60 9D 6A 95 48 95 2F 2D 63 54 A A0 38 96 D5 33 53 75 49 6D 2D 97  
PACKET RECV: len: 8, pid: 0, nack: 0, data: 80 76 56 47 4C 31 2A C0 60 9D 26 49 A4 8A 49 42 15 54 9A 5A 56 2 AA 55 5A A4 95 4E D1 55  
PACKET RECV: len: 8, pid: 0, nack: 0, data: 80 76 56 47 4C 31 2A C0 60 9D 55 6D B5 BE B6 9D A7 D7 5E F7 76 FA AD B6 EE AA 56 CB 6D AE  
PACKET RECV: len: 8, pid: 0, nack: 0, data: 80 76 56 47 C 31 2A 0 D7 4D 51 A4 A9 6B 55 54 8A 92 54 6E A0 2A A8 E1 29 53 64 2C 8A DA  
PACKET RECV: len: 8, pid: 0, nack: 0, data: 80 76 56 47 C 31 2A 0 D7 4D 25 CA C9 A8 A5 55 25 29 56 73 24 5A 15 5 54 56 92 22 96 D4  
PACKET RECV: len: 8, pid: 0, nack: 0, data: 80 76 56 47 C 31 2A 0 D7 4D 4A D5 57 28 25 28 14 B3 54 12 2E 54 C2 AA 25 36 A8 B6 AD AA  
PACKET RECV: len: 8, pid: 0, nack: 0, data: 80 76 56 47 CC 31 2A 40 2C 2D 56 95 9 9D 53 5A 92 D5 2A 46 29 55 42 8C 12 85 28 29 3A B4  
PACKET RECV: len: 8, pid: 0, nack: 0, data: 80 76 56 47 CC 31 2A 40 2C 2D 1 55 D2 E6 A9 D6 FD EA D8 EB 8D 85 6B 2D 49 7D A9 5F 4B 74  
PACKET RECV: len: 8, pid: 0, nack: 0, data: 80 76 56 47 CC 31 2A 40 2C 2D 57 72 1D BA AB 7B 3E ED FA BF DD 6F B6 AB 6B D5 BB D5 CD 5A  
PACKET RECV: len: 8, pid: 0, nack: 0, data: 80 76 56 47 C 31 2A 0 D7 4D 26 A9 55 15 54 C2 50 B5 54 B5 6B AD 36 A5 4D 34 D5 54 AB 8  
PACKET RECV: len: 8, pid: 0, nack: 0, data: 80 76 56 47 C 31 2A 0 D7 4D 9 29 64 95 5A A4 AA 42 44 A9 2A A A 12 2B 68 EC A1 5A 4A  
PACKET RECV: len: 8, pid: 0, nack: 0, data: 80 76 56 47 C 31 2A 0 D7 4D 4A B2 A5 95 DE DF F7 FE AF CD AA DA 5A 36 AA BA 93 9A AB 52  
PACKET RECV: len: 8, pid: 0, nack: 0, data: 80 76 56 47 C 31 2A 0 D7 4D 42 6A 15 2C 51 34 A9 32 AD 21 57 5B DD 6B ED 74 EB 75 FA 6E  
PACKET RECV: len: 8, pid: 0, nack: 0, data: 80 76 56 47 4C 31 2A C0 60 9D 66 E9 4C 45 6A 2E 85 68 AA A4 EE 15 29 48 14 A8 6A A9 6A A4  
PACKET RECV: len: 8, pid: 0, nack: 0, data: 80 76 56 47 4C 31 2A C0 60 9D 54 A8 55 93 85 9D 54 A1 2D 55 6A B1 55 5 46 DB B9 EA BE FA  
PACKET RECV: len: 8, pid: 0, nack: 0, data: 80 76 56 47 4C 31 2A C0 60 9D 2A AA 92 AA 91 55 42 52 48 AC A8 55 B4 C9 50 94 5E A9 B3 A6


fields:
0 throt 0x80 -> 0xe4
1 yaw   left 0x44, center 0x76, right 0x20 (not in order)
2 pitch stick down 0x64 center 0x56, stick up 0x00 (not in order)
3 roll  left 0x75, center 0x47, right 0x11 (not in order)
4 roll/pitch/yaw trims
5 flags for throttle button, two buttons above throttle,(i forget what this does) 
6 ??
7 roll/pitch button (i forget what this does too)

I should also mention that if I write to the reserved registers, the parsed packet control field data isn't valid(gives a packet length of 40 I think).
Last edit: 15 Jul 2016 07:20 by bikemike.

Please Log in or Create an account to join the conversation.

More
15 Jul 2016 07:38 #51704 by btoschi
Replied by btoschi on topic FQ777-124 Pocket Drone
Great findings, you definately have more spare time than me ;)

The problem with shockburst is most propably that SSV prepends the 9 bits and then scrambles the entire data,
thus NRF cannot receive it any longer. Though I have no idea why SSV cannot receive it ...

You can see the 'CRC' part in the data packets (last bits - not sure if 100% aligned - are CRC):
80 76 56 47 4C 31 2A C0
80 76 56 47 CC 31 2A 40
80 76 56 47 0C 31 2A 00

Please Log in or Create an account to join the conversation.

More
15 Jul 2016 07:39 - 15 Jul 2016 07:41 #51705 by bikemike
Replied by bikemike on topic FQ777-124 Pocket Drone
Xor of bind with your spi capture(with my tx id):
a0516173bf342a2e
Xor
20150506d3450089
=
804464756c712aa7

And now that xor with normal packet data:
804464756c712aa7
Xor
807656474c312ac0
=
0032323220400067

I think we can work with this!!!
Last edit: 15 Jul 2016 07:41 by bikemike.

Please Log in or Create an account to join the conversation.

Time to create page: 0.126 seconds
Powered by Kunena Forum