Furibee F36 protocol attempt

I have attempted to find more info about the furibee f36 protocol. As you may know, the quad and tx both use single mcu / rf ics and as such no spi to sniff as far as I know. There are no markings on either chips.

Findings:

I used a nrf24 to attempt to find packets, and used carrier detect to find likely channels.

So far it seems bind is on channel 2, it lasts for a bout 1 second. If throttle is high, the bind signal finishes, and I presume the tx waits until throttle is lowered.

Rate is 1Mbps.

The tx sends large packets, possibly continuous. The payload length is over 32 and possibly over 64. Within the payload there are several repeating sequences of a few bytes.

After bind, I am receiving data on ch 54, maybe other channels as well as I have not thoroughly searched all channels.

The packets also seems to have very long length, and have a number of repeating sequences, some of 8 bytes repeating several times in a raw. I have not been able to find any bytes that change with stick movements, and I have checked at least 64 consecutive bytes ( believed to be)

In conclusion, it seems the protocol will not be nrf24 compatible, due to the use of long packets. There is also likely to be a FEC scheme, or some other kind of encoding , which masks visible changes with changes in tx inputs.

Example bind sequence ( part of a larger stream) on ch 2
Example data stream ( part of a larger stream) : ch 54
The above are likely not bit aligned as I was unable to find a definite start, although I found what looks like an end ( it has 255 at the end before noise )

perhaps this will help others somehow.For sniffing I used the 2 bytes nrf address option ( not listed in the datasheet) and pieces of packets, to stitch together into larger portions.

I hope somebody does decode the protocol this looks like a kickazz little quad..I ordered one recently and plan on putting a AIO camera on it, but i fly on mode 3 which sucks cause all these and other only come on mode 1 which makes it difficult for me to fly..So hopefully it will be added to the long list of compatible models for deviation..Fingers crossed!

I hope somebody does decode the protocol this looks like a kickazz little quad..I ordered one recently and plan on putting a AIO camera on it, but i fly on mode 3 which sucks cause all these and other only come on mode 1 which makes it difficult for me to fly..So hopefully it will be added to the long list of compatible models for deviation..Fingers crossed!

Any progress on deviating the F36 ? i have 2 and would love to fly them with my 12s..
Until then i'm going to have to unsolder the gimbles in one of the transmitters and switch them around so i can fly on mode 3 ..Really sux doing it cause i did one of my cx10 tx before it was added to deviation..

I gave up as it looked to me I can't use a nrf24 to get further.

Seems it would be LT8910 or similar radio, which I don't have around the place.

I have the 4n1 module installed in my 12s any chance one of the other modules would bind to it?

It's really doubtful but anything is possible I guess

I tried all the different protocols and no luck so i swapped the gimbles and rewired the pots at least now i can fly it on mode 3 but those little toy transmitters suck compared to a full size tx...Maybe somebody will figure it out soon this is such a great little quad not to be on deviation..Really looking forward to my FuriBee F3 EVO Brushed Flight Controller to get here so i can bind it to my 12s...

xxx wrote: Rate is 1Mbps.

The tx sends large packets, possibly continuous. The payload length is over 32 and possibly over 64. Within the payload there are several repeating sequences of a few bytes.

How did you determine that the bitrate is 1Mbps and that the payload is more than 32 bytes?

Did you find an address to use that would allow you to receive packets without all the noise that comes with sniffing with a 2 byte address (0x00 0x55 or 0x00 0xAA)?

I used 2mbps originally and the bits were doubled up.

To find it's over 32 bytes, I used a sequence from the middle of the payload as the address for the next payload, and stitched them together. Sadly I stitched them together many times and never got a full packet.

There are also many 8 byte sequences that repeat in the stream, sometimes with small differences in some bytes

I haven't found a definite start of the packet, I think you can use a larger address size, the 0x55 preamble seems not necessary so you can use anything in the middle of the packet, but I might be wrong.

The main issue is the nrf24 won't receive over 32 bytes, and due to the repeating sequences in the stream, there are some places you can't "skip" past as they repeat too many times. I think a lt8910 is required for this.

Note also, the posted sequences are likely not bit aligned correctly. I have also tried a 8to10 decoder, which is one supported encoding by the LT89xx , that did not work out. The LT89xx also supports 1 to 3 FEC and interleaving , and if those were used, they would explain why there are so many repeating 8 byte sequences imo

So is there still a little hope or we just crap out of it?

How much does a over the air sniffer cost ? I would be interested in investing in one if not to expensive but have no experience using such equipment ..

There may still be hope. It's hard to say.

In my initial testing with the receive power detector I see activity on ch 60-63, 67-69, 73-75, and 79-81.

Sniffing channel 68 and channel 80 I found the following stream of bytes repeated somewhat often:


I'm sure there are others but I've only taken a quick glance at the captures.

Goebish stated in the GW008 protocol thread that it might be possible to emulate it with a CC2500. Perhaps use a cc2500 for sniffing?

I tried some addresses from those posted by bikemike but I didn't get anything to receive.

I also tried 3 byte address, that seemed to not receive anything, presumably because the preamble is missing

Yes, I forgot to mention , it's not xn297 compatible, it was the first thing I tried.

What is the 10 bit PCF and when is it sent? I don't remember anything like this in the datasheet, but of course it's in chinese. Is it to do with ack?

I tried finding an address where I could see changes when moving the sticks. I'm not sure if this is helpful in any way but I finally found one that shows changes when I move the sticks:

CHANNEL: 80, ADDR: 56 97 56 97 56 , 250kbps (my tx hops between channels 61,68,74, and 80).

The bytes looks somewhat consistently like this without sticks(and throttle down):Roll seems to affect most of the packets starting at byte 2. Pitch affects bytes starting at 10. Throttle affects the bytes starting at 18. Yaw affects bytes starting at 27.

One similarity is that the locations where the bytes start changing are all 56 when centered and 57 when lowest for roll, pitch, and throttle.

Yeah, I love the way you guys hack these toys. Full of enthusiasm. Always cool to read about any progress Keep it up!

In an somewhat unrelated way, I wanted to find out why some addresses let a lot of fake packets in, while others are better.

I ran a 2 byte nrf address with random numbers and no signal, 1Mbps, this is what it comes up to:

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

The best, noise proof addresses are those with long 0 or 1 sequences

The packet counts are over 5 seconds,and the worst address lets in just over 200 packets per second

So this would mean the internal nrf24 noise is made up of oscillating 0 and 1 very close together.