MJX V1 (CC2500 based) Protocol

Just wanted to share my findings on MJX T40C Transmitter, which uses CC2500 chip (26MHz xtal, SPI commands match perfect).

RF Module Pinout (Top to bottom, Antenna is considered to be at "top") plus MCU pin its connected to:
? (10) (Looks like Radio Enable, low while Payload is written)
CSn (14)
n/c
GND (5)
n/c
MISO (13)
CLK (12)
MOSI (11)
3,3V (15,16)

Its using channel hopping, 21 channels, sequence is
Payload is 16 bytes, e.g.CS is simple sum of all elements,
ST C8 = bind packets, 08 = default, 18 = Cam active
SS is 56 on bind packets, 47 when bound is Channel sequence ID / TX ID. Random on T40C TX
TX ID is guessed. May be wrong, is 6D CF for MiniPET TX.
Packets are sent every 8ms with these SPI Commands:
Bad thing is that sometimes CLK is kept high when CSn goes low, and Saleas SPI decoder does not like that (STX in above sequence is always affected, and one command in init sequence). In fact the chip itself reads values on rising CLK, so it does not care about that.

I have neither a RX board for this protocol, nor another TX to check with, but I'll try to put that in some deviation code so someone with old MJX equipment (HJ MiniPet/X100 should be fine, too) can test that.

I have a custom SPI decoder which makes use of the Salea SDK, which enables 'live view' of data. Together with piping through grep its capable of almost everything

Anyway, thanks for the hint. I'll share my SDK based code some day, I hope. Currently its in 'hacked until it worked once for me' state, say, unusable for anyone else

Short update:
I recently got an used Mini PET from eBay (HJ V997, X100 with Bee canopy) and can confirm that it binds with the MJX T40C Transmitter and can be flown with (though missing one channel).
Thus the protocol here seems to be really the 'one' MJX V1 protocol, most propably even compatible to F645 V1.

It's good if MJX (V1) Job is "almost" done

Since UDI protocol (BK/nRF ShockBurst Feature, to be precise) gives me headaches, I thought I'd give MJX CC2500 protocol another try.

Sniffed init, bind procedureand some steering commands on my MiniPET TX.
Note that SPI on this one uses CPOL=1 and CPHA=1, which makes trace magically parseable by Salea Logic Software.

Attached is an .csv export plus a python script which parses CC2500 commands from Salae SPI exports, just like victz's nRF24_decode.py does (in fact its based upon its code). Expect anything, but results looks sane to me.

Note that another channel hopping sequence than in my T40C TX trace is used here, so its most likely coupled to a transmitter ID.
Edit:
The sequence printed in the very first post ist the bind sequence.
When bind phase is done (times out after ~9s or by throttle up/down with MJX V1/V2) it switches to channel hopping sequence as dictated by TX ID - which is the very first byte in the payload.
My MiniPET TX seems to always use 0xED as ID, but the T40C Transmitter seems to use a random ID, which lets me confortable sniff every sequence w/o too much guesswork.
For testing one sequence with fixed ID should be okay, the rest will need 256*21 bytes storage and some sniffing attempts worst case (or I can find an algorithm to derive the sequence, we'll see).

Lets see if I get this one bind with my arduino ...

btoschi wrote: Since UDI protocol (BK/nRF ShockBurst Feature, to be precise) gives me headaches, I thought I'd give MJX CC2500 protocol another try.

Sniffed init, bind procedureand some steering commands on my MiniPET TX.
Note that SPI on this one uses CPOL=1 and CPHA=1, which makes trace magically parseable by Salea Logic Software.

Attached is an .csv export plus a python script which parses CC2500 commands from Salae SPI exports, just like victz's nRF24_decode.py does (in fact its based upon its code). Expect anything, but results looks sane to me.

Note that another channel hopping sequence than in my T40C TX trace is used here, so its most likely coupled to a transmitter ID.
Edit:
The sequence printed in the very first post ist the bind sequence.
When bind phase is done (times out after ~9s or by throttle up/down with MJX V1/V2) it switches to channel hopping sequence as dictated by TX ID - which is the very first byte in the payload.
My MiniPET TX seems to always use 0xED as ID, but the T40C Transmitter seems to use a random ID, which lets me confortable sniff every sequence w/o too much guesswork.
For testing one sequence with fixed ID should be okay, the rest will need 256*21 bytes storage and some sniffing attempts worst case (or I can find an algorithm to derive the sequence, we'll see).

Lets see if I get this one bind with my arduino ...

File Attachment:

File Name: minipet.zip
File Size:723 KB

Can PB help you . He already got some experience with CC2500 chip...
If you are fixing the ID, is it binding ?. Why not fixing a table of Id and sampling in it where the associated RX/channel is free ?

P.S. I received my other U839. This quad is very good .... It would be great to have this hacking ... What is the exact test procedure I should do with this second U839 ?

I'll need to get CC2500 code running on arduino and interface my tiny cc2500 board (one should really take a look at pin pitch when buyin such small devices .. 0.5 inch )

Regarding UDI: At first I need to manage getting a packet acknowledged when using ShockBurst. This is the point I'm stuck (MAX_RT gets set ... I think I'll need to try strobing CE instead of keeping it up all time to enable receiving ACK packets ... )

Update:
Arduino code is up an running, Module is attached using SMD Probes and I can read proper values for partnum (0x80) and version (0x03).
Init Sequence and Packet transmission as observed on TX is implemented and at least data transmission is working as expected, since I can poll GDO0 for going high and low again (programmed to 0x06, such indicating ongoing transfer).
Anyway I'm missing something, as the MiniPET's LED does not change the blinking at all (which indicates receiving of valid data packets).
More to come tomorrow ...

Ago , Mjx use nrf24l01 and now is cc2500 ?

MJX has two 2.4GHz protocols.

MJX V1 (that's my name for it as its the older one) uses CC2500 and is found on early 2.4GHz Models, like MiniPET / X100 / 997 V1 / T-Series and F645 with Rev 1 PCB (that's where the Text printed on Transmitter is not red). That's what is coverd in this thread. And I can bind and some kind of control the Quad now after fixing a stupid bug in my code.

MJX V2 uses nRF24l01 and is found in all newer 2.4GHz Models (F45 with Rev 2 and 3 Receiver, F46, F48, X200, ... ). That one is covered in another thread.

Okay, some more testing later I am able to control the quad mostly using arduino and attached dead Transmitter.

Test code for arduino is attached, but be warned that this can seriously damage you or your quad or helicopter !!!

Code is for Arduino Mega and you'll need CC2500 Module (only SPI, 3.3V and GND needed to be connected), but you can adjust the CSn Pin easily by #define to work with other arduino boards (others defines are remains of outdated CC2500 library I converted to use SPI library)

Some issues with reaction to inputs from time to time and I'm not too sure about mapping of steering to negative/positive axes.
Currently I'm just using my MiniPETs TX's ID plus Sequence ID and use the observed hopping sequence (aka: Hardcoded ID).

You'll need serial monitor to start bind process by 'b' + Enter, after a while 't' + Enter to start transmitting normal packets (check receiver LED to go solid, then it has synced to TX bind packets and its safe to do so).
'r' + Enter stops transmission (MiniPet will keep motors running for ~ 2 secs and then stop)
Any number + Enter toggles that bit in flags, bit 4 (0x10) e.g. turns camera on/off.

Feel free to test with any CC2500 based MJX Model (F45 with V1 receiver would be nice, but you better disconnect the two motor cables (not servos) before trying this )

Too bad my newest multi module does not work as expected - it has CC2500, but Nothing gets detected (even MultiMod and CYRF missing), Devo 8S auto-resets when having nRF or CC2500 enabled (pretty sure that's an some code with endless loop killed by Watchdog ...).
Anyway I'll try to convert that for deviation and see if I can my MultiMod issue fixed ...