which is MJX use protocol ?

I don't know what's going on,I can't upload other pictures.

Message:
500 Internal Server Error
Fatal Error was detected!
Please contact the site owner.

SeByDocKy wrote:

dc59 wrote: Hi Victzh,
Bad news~
MJX X600 seller told me, MJX use different protocol on quad and heli, they tried to bind X600 quad with F45/F47 tx,
it didn't work , too bad! I have my X600 on the way .

I am not surprized .... I am sire they shifted to a XN297 protocol based. I saw recently a general move to this (even cheaper) chip...

Hi Seby,
Do you know XN297 pinout?



I measure voltage of each pin
1. 3V (3.3V Vcc ???)
2. 2.36v
3. 2.04v
4. 1.14v
5. GND
6. 0.06v
7. 0.85v
I want to capture SPI data,but I don't know MISO / MOSI / CLK / SCK pin or I can just try and error?
Thank you very much.

I found a schematic of the XN297 that might help.



It appears to me that pins 2, 3 and 4 correspond to CSN, SCK (clock), and MOSI; these should give you a good capture once you determine a ground pin. I can't tell from the photos where the 1st or 5th pin from the processor is connected, but that the processor's CE and MISO; they might not be needed to get a capture. I'm not entirely sure you've got ground and 3.3 right..the red wire to pin 5 would suggest there is Vcc on that pin? Where does that red wire go?

Here is a good example of what the team did with the CX-10 Green board. The chip pins are the same and you might be able to follow the process there. On that one the MISO wasn't connected, and it looks like just capturing CSN, SCK and MOSI got what was needed.
CX-10 Captures

Edit: found a photo with the red wire connected to the shield, which probably means that pin 5 is ground. So yea, connect 2, 3, 4 and 5 to your analyzer and let 's see the results!

Thanks Deal57,it's really help me to find the answer.
I used resistance gauge to check pin connection,
1, VDD
2, CSN (enable)
3, SCK (clock)
4, MOSI
5, GND
6, MISO
7, CE

But I got some problem when I captured SPI data,there is some error occur :





Could anyone help?

ps. the red wire on pin 5 connect to copper foil, I think it shield some noise.

I think that the display isn't set up for the SPI decoder to do its job. I just added a note to the SPI Capture Guide topic that may help you set up the SPI analyzer settings.

Let me know if I can elaborate or clarify any of those notes.

Hi Deal57,

I captured data :
www.mediafire.com/download/dvnzv8bqddww1...-Armed-THR_0-1-0.zip

1, quad on
2, tx on
3, bind
4, armed DISARM ( throttle 0% -> 100% -> 0%)
5, throttle 0% -> 100% -> 0% (DR=100%)

The errors don't affect the exported csv - all the expected data is there. Judging by the clock and data with no enable, there's definitely at least one other device on the SPI bus. Maybe the timing errors are just a design problem addressing the different devices.

Another oddball protocol. Uses the same address for bind and data. Hops four frequencies, two of which are the same in both bind and data phases. Need more tx captures to see if the values vary at all between different transmitters.

What action moves from 3 to 4 (bound to armed)?
The throttle channel changes are too jumpy to be confident in the interpretation. Maybe another capture with slower stick movements?

hexfet wrote: The errors don't affect the exported csv - all the expected data is there. Judging by the clock and data with no enable, there's definitely at least one other device on the SPI bus. Maybe the timing errors are just a design problem addressing the different devices.

Another oddball protocol. Uses the same address for bind and data. Hops four frequencies, two of which are the same in both bind and data phases. Need more tx captures to see if the values vary at all between different transmitters.

What action moves from 3 to 4 (bound to armed)?
The throttle channel changes are too jumpy to be confident in the interpretation. Maybe another capture with slower stick movements?

Hi hexfet,

It's good to see you at this thread.

The action between 3 to 4 is move throttle from down(0%) to up(100%) then down(0%) , it should be a "DISARM"(I put wrong word,apologize for my suck English), then throttle can work! this is MJX starting process .

I will capture slow throttle movement data and upolad it here.

Really appreciate.

Hi hexfet,
I captured more SPI data,include throttle slow movement.
www.mediafire.com/download/qzt5ipa9ve1ifix/MJX600-SPI-02-04.zip

@Deal57
Please also check this data,thanks.

Thanks, that's helpful. Need the trim and special function captures too please.

I've uploaded a test build and pushed code that adds the MJXq (for quadcopter, though I think you have a hex!) protocol. It may or may not bind. I left out one piece of the stock tx initialization hoping that it doesn't matter. If it does matter we'll need more captures from other transmitters. If it does bind, moving the throttle up and down to arm likely won't be necessary so be ready for takeoff

The stock tx sends a seemingly meaningless first packet - just one packet - before starting bind packets. Hopefully that's just a mistake, but if it determines the data phase rf channels we'll need to figure out that relationship. For the moment I've also set what appears to be a txid to the same values as in the capture.

Here's the protocol info.
RF address always the same: 6d, 6a, 73, 73, 73
Bind channels: 0a, 35, 42, 3d
Data channels: 0a, 46, 3a, 42 (varies by tx?)
Data rate 1Mbps, 16 byte payload
Packet data
0: throttle, 0-ff
1: yaw, +left, value encoded as sign + magnitude
2: pitch, -forward
3: roll, +left
4-6: trims? (0x40 value means centered?)
7-9: txid ?
10-13: 0 (maybe used for flags?)
14: 0xc4 during bind, 0x04 during data phase
15: checksum (sum of bytes 0-14)

Silently lurking at this thread...
I typed my PayPal password for an MJX X800 as soon I saw Hexfet writing on this thread

@Hexfet, are you on holidays?

Tested the build with X400 (my X800 will come in several days). So I do not sure if the protocols for X400 and X600/X800/X900 are completely the same, but the result is very promising already.

Binding - no problems. No need to make any throttle movements as it is required on original TX.

Flying - AIL and RUD channels should be reversed. Pitch and yaw rates seem to be maximum, but it is hard to say exactly, as this build works in flip-on or auto-flip mode. I mean that may be flip flag on or may be it is third mode of original TX that is auto-flip.

Durete wrote: @Hexfet, are you on holidays?

LOL just without a paying project, but that just changed
These protocols are very simple, and at this point it's mostly copying an existing one and changing a few things.

vasiliy_gr wrote: Tested the build with X400 (my X800 will come in several days). So I do not sure if the protocols for X400 and X600/X800/X900 are completely the same, but the result is very promising already.

Binding - no problems. No need to make any throttle movements as it is required on original TX.

Flying - AIL and RUD channels should be reversed. Pitch and yaw rates seem to be maximum, but it is hard to say exactly, as this build works in flip-on or auto-flip mode. I mean that may be flip flag on or may be it is third mode of original TX that is auto-flip.

Excellent! Thanks for testing

I'll wait to see if the channels are reversed for dc before making changes. You described the flip situation well - I understand. Need captures of the special function controls to get that sorted.

Hi Hexfet,
I uploaded MJX function key data:
04-Auto Filp (one press automatically forward filp) I captured it twice
05-Headless ON then OFF
www.mediafire.com/download/zgx3gyx9govr1c5/MJX600-SPI-05-06.zip

My stock TX RTH key is broken, I will try to fix it ASAP,sorry about this.

Test Build:
1, As same as vasiliy_gr's report,AIL&RUD set to reversed, it works fine with my X600 hexacopter.
2, Different fixed IDs, No problem.
3, Need to press "BIND"/"Re-bind" button to bind (Bayang protocol can bind automatically after turn on TX power)
4, No need to DISARM
5, Default DR=100% , it will filp when you move stick over 90% movement , if you don't want to filp, set DR<90%(89%)
then it will not filp!

I've uploaded a new build with aileron and rudder reversed, flip control on channel 6, and headless control on channel 9. It also adds the fixed ID to the txid value from the SPI capture (the fixed ID wasn't used in previous build). If you set fixed ID to none the known working txid will be used. Please try some other fixed ID - if one works they all will.

3. It should be trying to bind at power-on if the model is the selected model. Is the binding dialog displayed?
5. Is there a switch or button on the stock tx to disable auto-flips?

hexfet wrote: I've uploaded a new build with aileron and rudder reversed, flip control on channel 6, and headless control on channel 9. It also adds the fixed ID to the txid value from the SPI capture (the fixed ID wasn't used in previous build). If you set fixed ID to none the known working txid will be used. Please try some other fixed ID - if one works they all will.

OK,No problem! I'll get it a try ..... after work.

3. It should be trying to bind at power-on if the model is the selected model. Is the binding dialog displayed?

There is "NO" binding dialog displayed when I turn on 7e power, but it had beep (seems like it's binding), but it didn't bind.

5. Is there a switch or button on the stock tx to disable auto-flips?

[/quote]
There is no other button to disable auto-filp, if I pressed that button it flip one time then back to normal ,
Maybe it just sent a "100% ELE" signal to copter, make a forward flip !
I don't really think this function is needed, it can just flip forward .... just my own opinion .

Tested the new build a little bit... AIL/RUD now ok. Headless - can't test as X400 does not support. Flips on ch6 - as on stock TX. I mean - after this channel momentary up (so it should be trim button or display button, not switch) quad immediately performs flip in some direction. I do not know how it choose direction of flip.

So as for flips it is not as simple as it could be... There are two flip modes - one is from button, the other is from stick in third rate mode. And I sure we need them both. And it means that we need a channel for rate mode switching as on stock TX: low - medium - high (high means with auto-flips). The idea with limiting AIL/ELE to 90 in mixers to disable auto-flips is not good. I already understood why... My X400 was noticably drifting forward without much help from gyro calibration - so I has to use devo's trim backward. The result you can imagine - X400 flipped directly in my head on full backward to my big surprise.

And as for fixed ids - something wrong with it. I used value of 25963 - and received high delays in controls. Something similar we had on yd829. I repeated the experiment three times with turning TX and X400 both off between them - nothing changed with delays. But when I used empty id - no delay. Sorry for not trying other id values - I moved to testing flips and exhausted my both batteries...

As for binding procedure I have nothing unusual with both builds. It binds automatically on devo power on.

In addition to my previous post.

Tested fixed id-s 1, 12, 123, 1234, 12345, 123456. On 1234 - binds and works with delays. On all others - no bind.

And about direction of manual flips - tried several times and all the times it was flip forward.

I installed test build "c7b2ea6" and gave it a try.

1, 7E Power on automatically binding sometimes work,sometimes not work.
2, Sometimes it was fail to bind, press 'Re-bind' and it would be OK.
3, With fixed ID '12' , got a big delay , '25963' OK, 'NONE' OK , '12345' OK (exhausted my battery......)
4, CH6 filp function, it seems AUTO-FLIP with stock TX, when I turn it ON & OFF, it will have a forward filp automatically.
5, CH9 Headless , works fine , no problem.

My X600 TX RTH function is not fixed yet, I can't caputre this data now.

EDIT : With this build , I lost Bayang protocol , I'm sure it's in protocol directory but I can't select it in model config.