which is MJX use protocol ?

Some updates:

Arduino code seems to work somehow. Receiver does receive TX ID and starts to channel-hop as expected, but capturing transmitted frame is hard to do with 250ms capture frame size, which is all I can do yet. Its no problem with stock TX (plenty of frames captured), so it seems to be a timing issue with channel hopping. When attaching a LED to the RX board (2pin connector), one can see that it slowly strobes after power up and starts to flash very fast after receiving one bind packet (both with Arduino and stock TX).

After various attempts I finally captured one received frame, which led to TX changing channel hopping to be done faster for some time. No stable communication yet.

@41ms I received frame, RX switched to channel 0x1D
@56ms RX switched to channel 0x22
@71ms RX switched to channel 0x17
@88ms RX switched to channel 0x34
@104ms RX switched to channel 0x28
@242ms RX switched to channel 0x2B

Thus after receiving one packet the RX listens on every second channel for ~ 15ms and gives up and resets to 150ms listening on each channel after not receiving another packet after 4 tries. Note that TX ID is CE D5 00.

I also found out that the actual bind sequence seems to be send and listened to as if TX ID is 00 00 00.



SPI capture of scana logic where I received the frame for reference. (Scana Studio 2.x can be downloaded for free for Linux/Mac/Windows from www.ikalogic.com/ikalogic-products/scanastudio-2/ and can read/display these files w/o actual device being attached)

More to come ...

Some more progress - getting used to my Saleae (clone for now, still waiting for real one with hopefully much better SMD probes ^^)

I think I've managed to understand the bind process of MJX, it has basically three phases (This is receiver side for now, as this is much easier to debug for me):

1. The RX performs frequency hopping for transmitter ID 00 00 00, changing channels in 140ms interval
2. When receiving a bind packet it switches to fast scanning using channels for the provided transmitter ID switching by two channels every 15ms
3. When receiving more packets during that phase (two or three, not sure whether they count packets or channels where packets where received) it considers itself as 'bound' (Transmitter will never know if its actually bound to something) and performs channel hopping for the transmitter ID chaning channel after 140ms. Any packet which does not have the 'bind' bit set, will be considered as real input since then.

I can confirm that a GR180 Transmitter of a 998-V2 does bind with my F45 receiver board, though I'm not to sure whether it would actually fly. Binding the F45 TX (GR129) with the 998-V2 does not work (and there's a chance I already know the bit which tells the difference).

Just a side note: The MJX feels like its taking a while to bind - actually the transmitter sends bind packets for a long time. Measured with stopwatch it takes 10 seconds between 'bind-beep' and LED getting solid, bind packets are send for 9.5s when checking SPI traffic on RX side. The GR180/998-V2 seems to be slightly faster here, as it 'only' transmitts bind packets for 5.8 seconds.

I'm almost pretty sure that frequency hopping is exactly the same as V2x2 protocol (another TX, another ID, and still it matches: 25 F3 86 gives row 2, increment 7, channel hopping is 18 21 3C 2B 2F 1F 2C 31 39 33 1B 2E 3D 3B 23 1E).

Now I'll try my luck with sniffing the TX side, and then I should be ready to fire up my arduino ...

TX side was easier than expected after finding proper ground pin on MCU (pinout in datasheet tells me its 20pins, though it has 24, I should have seen that earlier and simply use the EM78P419 ^^)

Bind packets are send two times per channel, every 4ms, using hopping scheme for ID 00 00 00. The data packets are send again two times per channel, every 4ms, using hopping scheme for transmitter ID.

And I found that one can easily tell the transmitter to be bound by moving any stick besides throttle after the bind was initiated, immediately sending real data packets, no need to wait 10s.

Time for arduino in new year then, stay tuned and good night for now

hope sucefful new year

Okay, Arduino code is modified so it will bind w/o too much problems.

But I did not manage to get stable communication running - I'm only receiving some frames within 12 seconds (best I had were 5 frames).
I've removed any console printing and checked the delays within code and adjusted so I only wait 4ms (3800us seems to work).

Also tried to do it via timer interrupts, but that does not seem to work (Tried with code ripped from TimerOne library).

So I'll need to connect logic analyzer on arduino side and check what's going wrong there ... Maybe timing is also wrong (4.8ms instead of 4ms ?) ...

Any clues on stable sending of packets on arduino would be great - I'm experienced C/C++/Assembler coder, but did not do too much with AVR/Arduino or other microcontrollers yet ...

Update:
Arduino Interrupts working fine now.
I was able to sniff both SPI ends at once thanks to 8 channels on Saleae and thus was able to track this issue down to the fact that receiver never switches back to 4ms listening as it misses many packets during the 150ms scan phase, which is most likely the essential key to MJX protocol I'm missing.
Gosh, I hope they did nothing too tricky here, this could be prime factors, though I'm not too sure yet ...
Think I'll have to hook up MJX transmitter and receiver at once for this (that'll be fiddly on my on my always much to populated desktop ^^)

Great development!

I found my error - but still I'm not in sync at all, now I'm receiving one frame in two seconds, still way too much loss to be usable at all.

Since I'm stuck for now (waiting for working 998-V2 to arrive which may help me with fresh ideas), I've started with UDI R/C Protocol (U816/U818) which is much easier since there is no channel hopping at all. I'll post my findings about that in a new thread ...

btoschi wrote: I found my error - but still I'm not in sync at all, now I'm receiving one frame in two seconds, still way too much loss to be usable at all.

Since I'm stuck for now (waiting for working 998-V2 to arrive which may help me with fresh ideas), I've started with UDI R/C Protocol (U816/U818) which is much easier since there is no channel hopping at all. I'll post my findings about that in a new thread ...

thank for your efforts


Currently, Mjx f45 have some upgrade mechanical . This project succesful, we have a f45 complete

Some updates:
I've got my 998-V2 now - damaged receiver board, but its able to bind (only one edge split so that rear motors won't spin).
I was able to bind F45 TX (GR129) with it and using an new 998-V2 receiver board I was even able to fly it around. Thus GR180 and GR129 transmitters definitely speak the same protocol.

I now can easily detect whenever arduino board binding works somehow, as the 988-V2/X200 RX board LED first blinks quickly when it detects bind packets and is continous on while it receives data packets. I can see it strobe on bind packets and then start to stay on for some time, turning off, turning on, turning off, ...
Thus it accepts the protocol, only thing is that channels are out of sync somehow, but allowing data transmission every few seconds.

Either channel hopping sequence is not properly aligned (index 0 is not their index 0) or timing is somehow screwed up. I'll have to re-check this again. (This is getting more work than I expected after seeing first SPI traffic ^^ )

btoschi wrote: Some updates:
I've got my 998-V2 now - damaged receiver board, but its able to bind (only one edge split so that rear motors won't spin).
I was able to bind F45 TX (GR129) with it and using an new 998-V2 receiver board I was even able to fly it around. Thus GR180 and GR129 transmitters definitely speak the same protocol.

I now can easily detect whenever arduino board binding works somehow, as the 988-V2/X200 RX board LED first blinks quickly when it detects bind packets and is continous on while it receives data packets. I can see it strobe on bind packets and then start to stay on for some time, turning off, turning on, turning off, ...
Thus it accepts the protocol, only thing is that channels are out of sync somehow, but allowing data transmission every few seconds.

Either channel hopping sequence is not properly aligned (index 0 is not their index 0) or timing is somehow screwed up. I'll have to re-check this again. (This is getting more work than I expected after seeing first SPI traffic ^^ )

Great

You are close now ..... Keep going !!!

SeByDocKy wrote: Great

You are close now ..... Keep going !!!

+1

Great work !!! ... looking forward to get my F45 under Devo control

@btoschi I doubt that exact index position matters - after first matching packet the sequence synchronizes. As a first step I usually try to replicate the packet sequence exactly from one of the transmitters and check that everything else is working. One of my own errors in one of the protocols was incorrect length of hopping sequence - so if was subtly off, but lead to intermittent faults. Check once more that you don't accidentally generate an extra packet.

I have triple checked about everything. SPI traffic on arduino matches sequence captured from original TX, I was even able to let it switch sequence from bind to real transmission at very same point within sequence.
One entire sequence (32 transmissions / 16 channels) take exact 128ms on arduino and real TX. Channel sequence is the same on both.
I have also added measuring time between writing RF_CH and average time between these switches and adjusted IRQ timing such that I have an average of 4135us on both SPI captures.
Still not working better though ...

Victor, I have a Mini Pet and transmitter if you want to\have time to co-develop.

My previous reply went nowhere, trying again.

Yes, I'd like to take a look myself, remote debugging of hardware is not that effective Is it known that Mini Pet uses the same protocol as MJX F45?

If you could also make (or point me to) high-res photos of the heli's main board and transmitter board near the RF chip it would help me to realize the level of complexity I am going to deal with.

In case Mini-PET is the same as MJX X100 (which I think it is) - small size like Ladybird - its using the old MJX protocol, with CC2500 chip.

I found these images of the PCB - 26MHz xtal prooves CC2500, when I'm right?



Its also not in Deviation and not yet published in the web, but not the protocol I'm trying to reverse engineer.

X200 / 998-V2 and their rebrands (e.g. MAXTECH 860) use the very same "new" MJX protocol like F45 (Rev2&3) plus all F46,47,48,...

Hooking up with the transmitter and the F45 board is fairly easy - I'm using SMD probes on the MCU pins (the probes shipped with my Salea Logic are fine) to sniff. I'm pretty sure that I have seen pictures of F45 old board where the RF chip is also on a PCB below the main board (and, nice, pins are labeled so you can easily probe with multimeter which MCU pin connects to what signal).

Okay, It seems I know the answer to my problems

I've attached another NRF module (with PA+LNA plus WiFi Router Antenna) to my arduino and I was able to bind my F45 RX with it (LED blinking steadily fast). This is not too reproducable and SPI capture tells me that I am mostly not in full sync - but TX sometimes transfers some packets (around at full rate before switching back to fast scan mode (skipping one channel) again.
My X200 board binds and the LED is constantly on - SPI capture not possible w/o soldering, but I can fly-test with my X200

I know that the original F45 has problems with binding when TX is too near to model (they even state that in their manual), and I'm using WiFi on my laptop where router is right under my desk - so there is plenty of Noise in 2.4GHz band.
And moving the receiver away from my laptop (Thanks Saleae for including such a nice, long USB cable) helped improving quality.

Testing further, bind with X200 board is really working fine (LED always lights up and stays so).

Checking my 2S LiPo I use to power the F45 board it may be that its just not properly charged (6.2V) and that's the reason why its not working (Last hope, I think ) ... charging ...

edit:
Arduino code (a mess, but you may get the idea )

btoschi wrote: Okay, It seems I know the answer to my problems

I've attached another NRF module (with PA+LNA plus WiFi Router Antenna) to my arduino and I was able to bind my F45 RX with it (LED blinking steadily fast). This is not too reproducable and SPI capture tells me that I am mostly not in full sync - but TX sometimes transfers some packets (around at full rate before switching back to fast scan mode (skipping one channel) again.
My X200 board binds and the LED is constantly on - SPI capture not possible w/o soldering, but I can fly-test with my X200

I know that the original F45 has problems with binding when TX is too near to model (they even state that in their manual), and I'm using WiFi on my laptop where router is right under my desk - so there is plenty of Noise in 2.4GHz band.
And moving the receiver away from my laptop (Thanks Saleae for including such a nice, long USB cable) helped improving quality.

Testing further, bind with X200 board is really working fine (LED always lights up and stays so).

Checking my 2S LiPo I use to power the F45 board it may be that its just not properly charged (6.2V) and that's the reason why its not working (Last hope, I think ) ... charging ...

edit:
Arduino code (a mess, but you may get the idea )

File Attachment:

File Name: MJX_arduino.zip
File Size:9 KB

Mean it is work ? Reason is put rx near .so it noisy .
Have you test control mjx f45 ? What is your tx ppm ?

GOOD WORK. Thank for your try

john wrote: Mean it is work ? Reason is put rx near .so it noisy .
Have you test control mjx f45 ? What is your tx ppm ?

GOOD WORK. Thank for your try

Well. It does work much better than before after changing NRF Module, but its not really working reliable yet.
I have to hook up some transmitter sticks to my arduino (have a broken MJX TX here) and the I can try to bind/fly my 998-V2 (which is the same as MJX X200).
Not sure if I have time for this tomorrow, but I'll try ...

For flying F45 I need much more testing and get somehow mobile (install NRF in devo 8s, get code to work with deviation), as a colleage owns the F45, not me. I only have the broken board to test ^^
Problem with NRF installation is that I still do not know whether UDI protocol will require CE to be connected, or not ...

Okay, tried with my 998-V2 quad - code seems to work fine for me when binding did succeed (which can take some time, maybe 15s or more, but can be as fast as 3s). Note that this board has a slightly damaged antenna, the other one does bind (LED stays solid red) much faster.
I have hooked up a dead GR-180 as analog sticks to my arduino and its not working as expected (throttle is always fine, but yaw changes with throttle ... 4 pin connector, ground and VCC, middle ones center of poti, which should be the actual readout)

Anyway, I can bind with it and controll throttle and some kind of yaw. Won't try to take off w/o proper analog reading and roll/pitch connected

Flags bit 4 = 1 (0x10) enables camera, records until its zero again.

Note even that this is some kind of breakthrough it does not mean that enough data packets are send to actually be able to control the quad as expected. I'll try to fix the analog readout issue and hook up the other stick so I can test more.