- Posts: 1386
FQ777-124 Pocket Drone
- victzh
- Offline
Please Log in or Create an account to join the conversation.
- btoschi
- Offline
- Posts: 151
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) ...
Please Log in or Create an account to join the conversation.
- btoschi
- Offline
- Posts: 151
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),
Please Log in or Create an account to join the conversation.
- bikemike
- Offline
- Posts: 42
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.
- btoschi
- Offline
- Posts: 151
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.
Please Log in or Create an account to join the conversation.
- bikemike
- Offline
- Posts: 42
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.
Please Log in or Create an account to join the conversation.
- bikemike
- Offline
- Posts: 42
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.
- bikemike
- Offline
- Posts: 42
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.
- btoschi
- Offline
- Posts: 151
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 )
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.
- btoschi
- Offline
- Posts: 151
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.
- bikemike
- Offline
- Posts: 42
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.
Please Log in or Create an account to join the conversation.
- btoschi
- Offline
- Posts: 151
(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
Please Log in or Create an account to join the conversation.
- bikemike
- Offline
- Posts: 42
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?
Please Log in or Create an account to join the conversation.
- Multirotor Go
- Offline
- Posts: 55
Please Log in or Create an account to join the conversation.
- btoschi
- Offline
- Posts: 151
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
And I cannot see the 8 zero bits which are actually send in a bind packet
(
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 ?
Please Log in or Create an account to join the conversation.
- bikemike
- Offline
- Posts: 42
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.
- bikemike
- Offline
- Posts: 42
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?
Please Log in or Create an account to join the conversation.
- bikemike
- Offline
- Posts: 42
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).
Please Log in or Create an account to join the conversation.
- btoschi
- Offline
- Posts: 151
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.
- bikemike
- Offline
- Posts: 42
a0516173bf342a2e
Xor
20150506d3450089
=
804464756c712aa7
And now that xor with normal packet data:
804464756c712aa7
Xor
807656474c312ac0
=
0032323220400067
I think we can work with this!!!
Please Log in or Create an account to join the conversation.
- Home
- Forum
- Development
- Protocol Development
- FQ777-124 Pocket Drone