Logic Analyzer SPI Capture for PROPEL 74-z

PROPEL Star Wars 74-z speeder bike





RF IC: bk2425 tssop-16
Please help find this protocol,thanks!
Capture files:
www.mediafire.com/download/rat5dudf6k2aae1
Capture files2 :
www.mediafire.com/download/62jdhxaox58lbdq
Capture files3 :
www.mediafire.com/download/1i12b74ea1qb6dr

This chip is compatible with nRF24L01. Have you tried the existing nRF protocols and format options?

The attached file has the SPI data from the capture. Currently I don't have time to work on an implementation. Maybe in a couple weeks if no one else picks it up.

hexfet wrote: This chip is compatible with nRF24L01. Have you tried the existing nRF protocols and format options?

The attached file has the SPI data from the capture. Currently I don't have time to work on an implementation. Maybe in a couple weeks if no one else picks it up.

I tried the existing nRF protocols and format options, but it no match.

Da ich auch den Speederbike 74-z hier stehen habe, interessiert mich das auch sehr. Ich habe alle Protokolle einschl. Unterprotokolle durch getestet, aber leider habe ich es nicht geschafft, den Speederbike zu binden.


Since I also have the Speederbike 74-z here, I am also very interested.
I have tested all protocols including sub-protocols, but unfortunately I have not been able to tie the Speederbike.

I had a bit of time to spend on this over the weekend. The first hurdle is to determine how the packet checksum is calculated. Without that it will be impossible to implement the protocol.

The first byte of the checksum is just the sum of all the packet data bytes.
The second byte is likely just a transformation of that sum. It appears the second nibble of the second byte is just the second nibble of the first byte xor'd with 0x0A, though maybe other equations would work.
Anyone that can solve this puzzle will move the work forward

From the data in the table below:
S1 = sum(data bytes)
S2 = (S2a << 4) + ((S1 ^ 0x0A) & 0x0F)
S2a = unknown (most likely only depends on the value of S1)

I've got most of this capture decoded. Details in the attached spreadsheet. Still have to crack the checkbyte algorithm though.

Have made some progress on the checkbyte but really need some more capture data. Not all the possible values appear in the one capture which is leaving some uncertainty. Please make another capture of about the same duration, but only need to be moving the sticks to all possible positions. It will be best to move both sticks around randomly at a medium pace. Hopefully this will generate enough unique packets to capture all possible checksum values.

hexfet wrote: I've got most of this capture decoded. Details in the attached spreadsheet. Still have to crack the checkbyte algorithm though.

Have made some progress on the checkbyte but really need some more capture data. Not all the possible values appear in the one capture which is leaving some uncertainty. Please make another capture of about the same duration, but only need to be moving the sticks to all possible positions. It will be best to move both sticks around randomly at a medium pace. Hopefully this will generate enough unique packets to capture all possible checksum values.

Ok, but I am in other cities these days, and I will do this after June 10th. Thank you for your help!

Capture files3:
www.mediafire.com/download/1i12b74ea1qb6dr

There may be something wrong with this file. Try it. If it doesn't work, I'm going to do it again.

The link is not working. MediaFire says it's likely the file doesn't exist.

Please try the test build (5e34ea5) here . No guarantees but it might work

Here are the channel assignments. For special functions set channel > 0 to activate.
CHANNEL1, // Aileron
CHANNEL2, // Elevator
CHANNEL3, // Throttle
CHANNEL4, // Rudder
CHANNEL5, // Leds
CHANNEL6, // Roll ccw
CHANNEL7, // Roll cw
CHANNEL8, // Altitude hold
CHANNEL9, // Calibrate

The speed is always set to high. Use mixer rates to slow things down.

There is some data that comes back from the quad, but the values are always the same. Probably has to do with the combat modes since the manual doesn't mention low battery warning or anything else that sounds like telemetry.

Capture files 3new:

www.mediafire.com/download/7aomm3bnrblvljt

Don't forget to download this

hexfet wrote: Please try the test build (5e34ea5) here . No guarantees but it might work

Here are the channel assignments. For special functions set channel > 0 to activate.
CHANNEL1, // Aileron
CHANNEL2, // Elevator
CHANNEL3, // Throttle
CHANNEL4, // Rudder
CHANNEL5, // Leds
CHANNEL6, // Roll ccw
CHANNEL7, // Roll cw
CHANNEL8, // Altitude hold
CHANNEL9, // Calibrate

The speed is always set to high. Use mixer rates to slow things down.

There is some data that comes back from the quad, but the values are always the same. Probably has to do with the combat modes since the manual doesn't mention low battery warning or anything else that sounds like telemetry.

test build (5e34ea5) it not work:(

Thanks for testing. There was one simple change that might help - please try the updated test build (3e2cbd0). If there's no reaction from the aircraft I'll need to inspect the code and captures again.

hexfet wrote: Thanks for testing. There was one simple change that might help - please try the updated test build (3e2cbd0). If there's no reaction from the aircraft I'll need to inspect the code and captures again.

where is test build 3e2cbd0 Link?

It's under Downloads -> Test builds on the left.

hexfet wrote: It's under Downloads -> Test builds on the left.

3e2cbd0 it not work

Capture files 3 lost D3 ，please pass.

Capture files4:
www.mediafire.com/download/9m3mcroa81o4qs1

If the Propel protocol doesn't work at all I would expect the screen would just show the "Binding ..." message until ENT is pressed. Is that what is happening?

Thanks for the capture. I'll be able to look at it in the next couple days.

Test build ( 6888afe ) is updated. The bind sequence in the second capture is a little different, so it may require several experiments to figure out what's significant and what's not.

Please try the Propel protocol. Post what happens on the tx screen and any response by the aircraft (leds, etc).

hexfet wrote: Test build ( 6888afe ) is updated. The bind sequence in the second capture is a little different, so it may require several experiments to figure out what's significant and what's not.

Please try the Propel protocol. Post what happens on the tx screen and any response by the aircraft (leds, etc).

688afe Doesn't work
6888afe Test video:
www.mediafire.com/download/7ubanxo91277bkw