1. Forum
  3. Development
  5. Protocol Development
  7. Furibee F36 protocol attempt

Furibee F36 protocol attempt

More
21 Feb 2017 03:36 #59391 by goebish
Replied by goebish on topic Furibee F36 protocol attempt
I've got one on order :)

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

More
21 Feb 2017 06:32 #59398 by bikemike
Replied by bikemike on topic Furibee F36 protocol attempt

xxx wrote: The worst addresses for noise are those similar to 0x55 or 0xAA , basically with many alternate 1s and 0s.


And I think this is exactly what allows you to use the addresses (0x00 0xaa and 0x00 0x55) to sniff and see the full packet because the noise generates a preable/address that occasionally matches.

Of course then you need to do a lot of filtering to find what you're looking for.

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

More
21 Feb 2017 06:44 #59399 by bikemike
Replied by bikemike on topic Furibee F36 protocol attempt

goebish wrote: I've got one on order :)


Great. I'm sure you'll be able to figure out a lot more using SDR. I'm having my doubts that it can be emulated with an NRF24L01+.

I've found 256kbps and address 4B AB 4B AB 4B to give the best information but I can't see a definite start/end of the packet and it seems to be larger than 32 bytes (meaning I don't see noise at the end) and other addresses seem to give more data before what this address shows.

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

More
21 Feb 2017 07:13 #59401 by bikemike
Replied by bikemike on topic Furibee F36 protocol attempt

bikemike wrote: Of course then you need to do a lot of filtering to find what you're looking for.


If you don't want so much noise you can discard packets if RPD is 0. I did this and it seems to work well.

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

More
22 Feb 2017 01:15 - 22 Feb 2017 01:17 #59431 by xxx
Replied by xxx on topic Furibee F36 protocol attempt
Finally found something interesting, or perhaps I should say useful, as it's more confusing than interesting.

Found part that changes with pressing throttle stick button ( maybe headless, not sure what function it is)

at 1mbps,
addr 17 142: ( reversed in actual code)

36 226  44  50 180   6 124 185 164 226  44  50 180 <<thrbuttonpress  6 124 185 164 226  44  50 180   6 124 185 164 226  44  50 180   6 124 

36 226  44  50 180   6 124 185 164 226  44  50 180 <<some otherstate 6 124 185 177  60 192 193  41 123  53  87  36 226  44  50 180 

36 226  44  50 180   6 124 185 164 226  44  50 180 << thr beeping    6 124 185 168 184 125   0 169  11 188 230 132 226  44  50 180   6 124 

36 226  44  50 180   6 124 185 164 226  44  50 180 <<powerup state   6 124 185 164 226  44  50 180   6 124 185 164 226  44  50 180

As you can see, it affects 9 bytes, which implies it's spread over 8 bytes but I have bad offset. Probably their "interleaving" technique they speak of. First and last sequences are the same

Btw I stitched together 100+ bytes to get here
silverxxx
Last edit: 22 Feb 2017 01:17 by xxx.

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

More
22 Feb 2017 01:38 - 22 Feb 2017 08:46 #59434 by xxx
Replied by xxx on topic Furibee F36 protocol attempt
After the button I got to see some stick changes...

They change a large number of bytes so it's hard to get much info using only 32 payload. I guess this is where the nrf24 experiment is close to it's limit. The trims are there also. This data is at the end of the payload as I repeatedly got to see the end noise. The last byte is always FF.

I also determined the offset to be likely <<1 in the data posted in the previous post.

I don't know of any ways to encode something 1 or 2 bits into 8 bytes, so I think I won't be able to decode it without finding the encoding method at this point.
silverxxx
Last edit: 22 Feb 2017 08:46 by xxx.

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

More
23 Feb 2017 20:31 #59537 by bikemike
Replied by bikemike on topic Furibee F36 protocol attempt
Doesn't it seem strange that it would be transmitting so much? You'd think that wouldn't be very good for battery life. I wonder if that's really the case or if we still don't have something right.

The only other thing I might try is checking the RPD field every 200us on one channel to see if it would show how long the transmit happens. This could also perhaps give an indication of how long the TX spends on each channel.

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

More
23 Feb 2017 20:56 #59538 by xxx
Replied by xxx on topic Furibee F36 protocol attempt
It certainly seems inefficient, but if they have FEC and it is of the level that encodes 1 bit into 8, they might be transmitting under 30 bytes.

RPD sounds good, I didn't think about it but my rpd stays on a lot, maybe noise or a wireless around. You could average lots of readouts to get higher resolution.
silverxxx

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

More
24 Feb 2017 08:05 #59554 by bikemike
Replied by bikemike on topic Furibee F36 protocol attempt
My RPD tests seem to show a packet transmit time of about 2500us and a channel switch about every 6000us.

If it is transmitting at 1Mbps, that's about 327 bytes if my math is correct.

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

More
24 Feb 2017 09:41 - 24 Feb 2017 09:41 #59556 by xxx
Replied by xxx on topic Furibee F36 protocol attempt
Interesting... That's pretty long.

My girlfriend looked at the binary printout of the "stitched-up" payload as it was sitting on the couch, and spotted a long pattern. It repeats a number of bytes (4 - 8 ) but it's at a non-8 offset. I might have made a mistake and got the nrf to receive a shifted payload, but it sounds unlikely as it happens multiple times. I have to look into it again sometime. I wish I had a way to get over 32 bytes.
silverxxx
Last edit: 24 Feb 2017 09:41 by xxx.

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

More
24 Feb 2017 12:03 #59558 by bikemike
Replied by bikemike on topic Furibee F36 protocol attempt
Maybe you could try with an xn297? Doesn't it support a 64 byte payload?

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

More
24 Feb 2017 13:17 - 24 Feb 2017 13:45 #59559 by goebish
Replied by goebish on topic Furibee F36 protocol attempt

xxx wrote: It repeats a number of bytes (4 - 8 ) but it's at a non-8 offset.


Congratz to your gf ;)
Can you give the binary sequence ?
As I'm working at the bit level with the SDR, that should be easy to dump complete aligned packets once I receive mine.
My guess is that it's using Manchester encoding and/or FEC.
Last edit: 24 Feb 2017 13:45 by goebish.

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

More
24 Feb 2017 23:53 - 24 Feb 2017 23:55 #59588 by xxx
Replied by xxx on topic Furibee F36 protocol attempt 
4E 22 C3 2B 40 67 CB 9A  
7 1 45 35 9B 28 57 E3  
8C C4 90 A 34 41 7E 5E  
80 30 7B 4E 22 3A 40 BA  
4E 22 C3 2B 40 67 CB 9A  
4C D 78 6D E 57 10 A  
D4 AF 84 6 E 3B 8B 27  
30 63 F8 AA 55 91 49 49  
44 C0 D7 86 D0 E5 71 0  
A4 E2 2C 32 B4 6 7C B9  
A2 89 F0 E 74 B1 B2 11  
3C 8 1D 93 28 55 95 9C  
B3 6 3F 8A A5 59 14 94  
83 2C 29 22 9F 89 11 8E  
24 E2 2C 32 B4 6 7C B9  
A4 E2 2C 32 B4 6 7C B9  
A4 E2 2C 32 B4 6 7C B9  
A4 E2 2C 32 B4 6

I'm trying to verify the stitching points some more.
 
01001110 00100010 11000011 00101011 01000000 01100111 11001011 10011010  
00000111 00000001 01000101 00110101 10011011 00101000 01010111 11100011  
10001100 11000100 10010000 00001010 00110100 01000001 01111110 01011110  
10000000 00110000 01111011 01001110 00100010 00111010 01000000 10111010  
01001110 00100010 11000011 00101011 01000000 01100111 11001011 10011010  
01001100 00001101 01111000 01101101 00001110 01010111 00010000 00001010  
11010100 10101111 10000100 00000110 00001110 00111011 10001011 00100111  
00110000 01100011 11111000 10101010 01010101 10010001 01001001 01001001  
01000100 11000000 11010111 10000110 11010000 11100101 01110001 00000000  
10100100 11100010 00101100 00110010 10110100 00000110 01111100 10111001  
10100010 10001001 11110000 00001110 01110100 10110001 10110010 00010001  
00111100 00001000 00011101 10010011 00101000 01010101 10010101 10011100  
10110011 00000110 00111111 10001010 10100101 01011001 00010100 10010100  
10000011 00101100 00101001 00100010 10011111 10001001 00010001 10001110  
00100100 11100010 00101100 00110010 10110100 00000110 01111100 10111001  
10100100 11100010 00101100 00110010 10110100 00000110 01111100 10111001  
10100100 11100010 00101100 00110010 10110100 00000110 01111100 10111001  
10100100 11100010 00101100 00110010 10110100 00000110  
0100111000100010110000110010101101000000011001111100101110011010 
0000011100000001010001010011010110011011001010000101011111100011 
1000110011000100100100000000101000110100010000010111111001011110 
1000000000110000011110110100111000100010001110100100000010111010 
0100111000100010110000110010101101000000011001111100101110011010 
0100110000001101011110000110110100001110010101110001000000001010 
1101010010101111100001000000011000001110001110111000101100100111 
0011000001100011111110001010101001010101100100010100100101001001 
0100010011000000110101111000011011010000111001010111000100000000 
1010010011100010001011000011001010110100000001100111110010111001 
1010001010001001111100000000111001110100101100011011001000010001 
0011110000001000000111011001001100101000010101011001010110011100 
1011001100000110001111111000101010100101010110010001010010010100 
1000001100101100001010010010001010011111100010010001000110001110 
0010010011100010001011000011001010110100000001100111110010111001 
1010010011100010001011000011001010110100000001100111110010111001 
1010010011100010001011000011001010110100000001100111110010111001 
101001001110001000101100001100101011010000000110

I think Manchester should be visible at bitlevel, as there should be no long 1 or 0 sequences. No point doing Manchester before FEC as it has no benefit apart for dc balance as far as I know. This has 8 long zeroes and 7 1s sequences.
silverxxx
Last edit: 24 Feb 2017 23:55 by xxx.

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

More
24 Feb 2017 23:59 #59590 by xxx
Replied by xxx on topic Furibee F36 protocol attempt

bikemike wrote: Maybe you could try with an xn297? Doesn't it support a 64 byte payload?

The xn297 has that extra 28 bit sequence before address, I don't think I'll ever get anything to pass thru.
silverxxx

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

More
02 Mar 2017 07:29 #59760 by bikemike
Replied by bikemike on topic Furibee F36 protocol attempt
Ahh. Ok.

Since I was out of ideas, I decided to desolder the chips.

This is the text on the back side of the rx chip:
516T_CGDAOV. 1
or maybe the O is a 0:
516T_CGDA0V. 1


This is the text on the back side of the tx chip:
B210
08
and
1_CGDK39.
Attachments:

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

More
04 Mar 2017 14:45 - 05 Mar 2017 16:36 #59839 by goebish
Replied by goebish on topic Furibee F36 protocol attempt
Just got mine :)

First observations:

- it does not transmit continuously, each packet lasts ~2.6 ms, at 1 Mbps that's roughly 32 bytes of data, so maybe it can be emulated with a nrf24l01 (37 bytes max).
- packet interval: ~23 ms (start of packet to start of next packet on same frequency) must be divided by 4 as you previously found it was hopping on 4 freqs
- seems I get some packets at 1 Mbps with 0x555555 as preamble but I'm not sure because I don't see much bits change while I move the sticks. (edit: I think I see them actually, but far away from the preamble ...)

It could be a LT8910 or LT8900 RF core ( packet format ) ... I'll extract 0s and 1s and try to reassemble the messages, though I'm not 100% sure of the bitrate ...

I'm pretty much a newbie at SDR, so any suggestion is welcome :)

File Attachment:


File Attachment:


File Attachment:


Also, I see there are a lot of test points on the quad's pcb, has anyone already tried to connect a logic analyzer to the Tx pad ? Perhaps that could give us some clues if they have "forgotten" to remove debug information. --> edit: nothing on this pad, always HIGH.
Last edit: 05 Mar 2017 16:36 by goebish.

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

More
04 Mar 2017 21:18 - 04 Mar 2017 21:19 #59851 by xxx
Replied by xxx on topic Furibee F36 protocol attempt
Certainly strange, makes me look bad :(

The pads don't do much that I have noticed, connecting ST-link comes up with an error, so I could not get anything. On the other 2 pads one is led and the other seems to do nothing

If you can find a preamble and address maybe I can find something of use with my tx.
silverxxx
Last edit: 04 Mar 2017 21:19 by xxx.

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

More
04 Mar 2017 21:38 - 04 Mar 2017 21:39 #59852 by goebish
Replied by goebish on topic Furibee F36 protocol attempt
try with this address, however it might be tx id dependent:
uint8_t addr[] = {0xb6, 0x44, 0x50, 0xeb, 0x14};
preamble is 0x555555
I receive packets if I set a nrf24l01 to this address, but the payload I receive is always the same ... nothing changes when I move the sticks :(
27 86 5d 30 63 f8 aa 55 91 49 48 d4 af 84 06 0e 3b 8b 27 13 cc 0c 12 97 b3 55 72 8b 87 d0 0a 90
Last edit: 04 Mar 2017 21:39 by goebish.

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

More
04 Mar 2017 21:54 #59853 by bikemike
Replied by bikemike on topic Furibee F36 protocol attempt

goebish wrote: - it does not transmit continuously, each packet lasts ~2.6 ms, at 1 Mbps that's roughly 32 bytes of data, so maybe it can be emulated with a nrf24l01 (37 bytes max).
- packet interval: ~23 ms (start of packet to start of next packet on same frequency) must be divided by 4 as you previously found it was hopping on 4 freqs
- seems I get some packets at 1 Mbps with 0x555555 as preamble but I'm not sure because I don't see much bits change while I move the sticks. (edit: I think I see them actually ...)

It could be a LT8910 or LT8900 RF core ( packet format ) ... I'll extract 0s and 1s and try to reassemble the messages, though I'm not 100% sure of the bitrate ...


Cool, this timing seems to match what I found using the RPD field of the nrf24l01+.

But I don't think your calculation for number of bytes @1Mbps is correct:
Bytes sent = rate * time
= (1Mbps * 1024 * 1024) * (2.6ms/1000)
= 2726.2976 bits
= 340 bytes

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

More
04 Mar 2017 22:02 #59854 by goebish
Replied by goebish on topic Furibee F36 protocol attempt
Yes, I realized that ... Maybe the bitrate isn't 1 Mbps after all, because 340 bytes is insane.
... gnuradio and the nrf24l01 are able to demodulate something at this bitrate, but maybe that's only an artefact.

I'll have a closer look at the low level signal.

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

  1. Forum
  3. Development
  5. Protocol Development
  7. Furibee F36 protocol attempt
Time to create page: 0.074 seconds
Powered by Kunena Forum
Re-enable mobile display