Bugs 3 mini

DPyro wrote: I selected bind, turned the quad on and then it went back to menu. RX ID changes from 0 to -29664

Ok, so you got a reply from the quad but it doesn't bind (probably wrong final address), more work is required ...

Now I've to simulate the reply of the quad with an arduino+nrf24 to try to understand how rxid affects address and/or hopping sequence.

That's interesting that C0ckpitvue 777 and I have Rx that can be used with the same addresses/frequencies despite different IDs.

@DPyro, just to confirm, it doesn't bind, but deviation exits the "binding" dialog when a battery is connected to the quad ?

I don't need any more bind sequence for now, I've to build a rig that simulates the reply of the Rx to the Tx during bind to understand how rxid affects final address and channel hopping. I suppose hexfet did the same for the Bugs3 (remember the spreadsheet? ).

I've to understand how the checksum that's sent by the quad in bind reply & telemetry packets is computed first:packets sent by 2 different RX, 1st byte is the checksum, 2nd and 3rd bytes are rxid.
I don't get it yet.

Ok got it!
rx packet checksum = (0x6d + sum of packet[1:15]) & 0xff;
(same "magic number" as tx packet but used with sum of bytes instead of xoring)
Now to build a rig with stock tx+arduino+nrf24 when time allows ...

edit: 0x6d is the 'm' of "mjxRC" which is the bind address converted to ASCII actually

Rig is up and running, spitting out rxid / address pairs at the impressive rate of around 3 per second (out of 65536)





First 3 bytes of the address are easy to guess (2nd byte is constant, I suppose that's a byproduct of the txid, but we don't care), and 2 last bytes often repeat, it shouldn't be that hard to crack (ie easier than the Bugs3 ?...).

Arduino code, if anyone is curious: gist.github.com/goebish/71fa5b6568e200438bf2090d50692480

Still running, 50% done, 3 hours to go.

I want everyone to be able to bind first (even if a spreadsheet is required for 1st bind at first...) then I've to thoroughly understand the flags (modes ...), that's not the case yet, I've to make more captures or watch packets in realtime.

New test builds available (7e & 10):
www.dropbox.com/sh/nrc4oppo121887l/AABQ_...IEn8A7BYvH5BpGa?dl=0

How it works (seems complicated but that's not...):
- start with no battery in the quad
- select Bugs3Mini protocol then press bind
- connect a battery to the quad
- wait for the bind dialog to exit then disconnect the battery for now
- go to the protocol options dialog then write down the "RX Id" value
- switch off transmitter
- go to bit.ly/bugs3mini_rxid
- find your RX Id in the green column (rxid s16)
- write down the corresponding value from the blue column (address[3:4] s16)
- connect your transmitter as an USB drive
- open the models/modelsxx.ini file in a text editor (under Windows, use notepad++ for exemple, not the builtin notepad, it does corrupt end of lines ...)
- under the [protocol_opts] section, fill the Address= field with the value from the blue column
- save and disconnect USB

Et voilà, it should bind now
You can now check that channel 5 controls leds.

source: github.com/goebish/deviation/blob/protoc...bugs3mini_nrf24l01.c

Now we've to try to make sense of this spreadsheet so we don't need it anymore ...

I do not have a 7e but it works on my t8sg v2+ and 7e emu.
Have you flashed the dfu and copied the new protocols folder to the filesystem ?

I've just rebuilt and uploaded the 7e firmware just in case ...

That's weird, pressing bind doesn't do much more than before, it only grabs the RX Id.
C0ckpitvue 777 can you check on your 7e please ?