which is MJX use protocol ?

dc59 wrote:

@DC59
Thanks for testing
So now, we need to figure out how to enable Headless in Medium rate.
Probably the receiver is erratic since is receiving a not recognized flag.
Please, could you take an SPI capture for headless mode on/off in Medium Rate (no autoflip)?
Probably this capture is not needed for anyone with programming skills, but since I'm not an expert I need to see it

No problem! I'll capture it, but it will take some time because I'm very busy these days,I'll try my best ASAP,Thanks!

Thanks !

I forgot to post this video here

@Durete

Nice video!

I captured X600 Headless ON-OFF SPI data by Low/Mid/High rate :
www.mediafire.com/download/a4nusro9u21fa...JX-X600-Headless.zip

Hope it could help,thanks!

Thanks for your captures

Unfortunately, I don't know what's wrong at the code
This is packet for headless off (medium mode):
And this is the packet for headless On:
And this is the code I'm using for packet 14:
I tested with the emulator and seems to be working as should be:

I don't know what's is wrong

That's a bad news .............

No worries
I'm fairly confident someone will come to help us

Well the headless bit is correct so not sure about that issue, but there are a couple of other questions.

Both the latest captures and Durete's earlier ones show the high rate bit in packet byte 14 is 0x4, and the mid-rate is 0x2 (and low rate is 0). Durete's latest code sets that value to 2 and has the FLIP channel controlling bit 0x4, so I think that means auto-flips are always enabled in high rate mode. Is the only difference between mid rate (2) and high rate (4) the addition of the auto-flip? Do they both give the same max angle at max stick?

The other concern is the fixed 0x10 value in packet byte 10. This was not in the X600 captures. I don't know if it might cause problems in the X600. It could be part of the txid or maybe a tx model identifier? Durete, how does the X800 behave if that bit is 0?

I think there is no difference between mid and high modes other than auto flip enabled at max stick position. Both modes gives us the same max angle.
The X800 works ok with packet 10 to 0. Only no light control.
I need to check about the flip by button function, since with my X800 this bit is at packet 10 and the X600 has this bit at packet 14.
My guess, as you wrote before the packet 10 is a TX model identifier, and they move some functions between packet 10 and 14 (even disabling Headless when packet 10 is 10).

I forgot to add some info...
My X800 flip OK (using flip button) using 0x10 at packet 14 as latest code from Hexfet's repo. This code uses 0x00 at packet 10.
Also my X800 flip ok (flip button) using 0x01 at packet 10 (this is my modified code) since my X800 captures show this bit used by flip button.
The weird thing, my capture show 0x10 at packet 14 for Video function at X800. Same bit used for different functions depending on packet 10?

@dc59
Did you capture Picture/Video functions at your X600 TX?
I guess the X600 TX has at least video function, so probably will be useful to see where is this bit located for these transmitter.

I guess probably we will need another protocol option for those 2 variants

Durete wrote: I forgot to add some info...
My X800 flip OK (using flip button) using 0x10 at packet 14 as latest code from Hexfet's repo. This code uses 0x00 at packet 10.
Also my X800 flip ok (flip button) using 0x01 at packet 10 (this is my modified code) since my X800 captures show this bit used by flip button.
The weird thing, my capture show 0x10 at packet 14 for Video function at X800. Same bit used for different functions depending on packet 10?

@dc59
Did you capture Picture/Video functions at your X600 TX?
I guess the X600 TX has at least video function, so probably will be useful to see where is this bit located for these transmitter.

I guess probably we will need another protocol option for those 2 variants

Hi Durete,
I didn't buy X600 with camera version so I didn't capture cam/video function data, but I read manual again, it shows cam function use same button as auto-flip , it seems when cam plugged to quad that button become cam function, I can't find any information about video function in manual.
Thanks!

dc59 wrote:

Durete wrote: I forgot to add some info...
My X800 flip OK (using flip button) using 0x10 at packet 14 as latest code from Hexfet's repo. This code uses 0x00 at packet 10.
Also my X800 flip ok (flip button) using 0x01 at packet 10 (this is my modified code) since my X800 captures show this bit used by flip button.
The weird thing, my capture show 0x10 at packet 14 for Video function at X800. Same bit used for different functions depending on packet 10?

@dc59
Did you capture Picture/Video functions at your X600 TX?
I guess the X600 TX has at least video function, so probably will be useful to see where is this bit located for these transmitter.

I guess probably we will need another protocol option for those 2 variants

Hi Durete,
I didn't buy X600 with camera version so I didn't capture cam/video function data, but I read manual again, it shows cam function use same button as auto-flip , it seems when cam plugged to quad that button become cam function, I can't find any information about video function in manual.
Thanks!

Thanks!
That makes sense, since my Video button capture and your Autoflip button capture uses the same bit at data packet
Probably I could test camera functions with this implementation with a MJX X300C but this will be in a while, probably 2 weeks. I guess the MJX X300C will be on the same protocol.

dc59 wrote:

Durete wrote: I forgot to add some info...
My X800 flip OK (using flip button) using 0x10 at packet 14 as latest code from Hexfet's repo. This code uses 0x00 at packet 10.
Also my X800 flip ok (flip button) using 0x01 at packet 10 (this is my modified code) since my X800 captures show this bit used by flip button.
The weird thing, my capture show 0x10 at packet 14 for Video function at X800. Same bit used for different functions depending on packet 10?

@dc59
Did you capture Picture/Video functions at your X600 TX?
I guess the X600 TX has at least video function, so probably will be useful to see where is this bit located for these transmitter.

I guess probably we will need another protocol option for those 2 variants

Hi Durete,
I didn't buy X600 with camera version so I didn't capture cam/video function data, but I read manual again, it shows cam function use same button as auto-flip , it seems when cam plugged to quad that button become cam function, I can't find any information about video function in manual.
Thanks!

Hi
I own an X600 with C4005 FVP Cam connected,and I can say that while flying, that button (upper right) is needed to flip or enter headless mode; Video and pics can be taken from wifi device connected to the cam. Anyway I will test again to be sure.
Thank to everyone for your work.

Thanks to all involve with the protocol.
Just received my X800 today. Unfortunately, I can't properly bind to the X800 with my 7E. It seems to responding the the bind with changes in light flashes, but no responses to the movements of the controls. Is there a trick to binding or settings changes needed for the X800? I read through the thread, but must have missed something.
Thanks.

Lukappaseidue wrote: Hi
I own an X600 with C4005 FVP Cam connected,and I can say that while flying, that button (upper right) is needed to flip or enter headless mode; Video and pics can be taken from wifi device connected to the cam. Anyway I will test again to be sure.
Thank to everyone for your work.

You are right,if you used C4005/C4006 FPV cam , the upper right button is still to be flip function , but if you used C4002 cam this button will be changed to be a cam trigger!

homl wrote: Thanks to all involve with the protocol.
Just received my X800 today. Unfortunately, I can't properly bind to the X800 with my 7E. It seems to responding the the bind with changes in light flashes, but no responses to the movements of the controls. Is there a trick to binding or settings changes needed for the X800? I read through the thread, but must have missed something.
Thanks.

Got it working.
Replaced my model setup ini with the one posted by Durete. Thanks Durete.

you are right too.

Hi guys.
I'm on a travel last days so can't follow too much the forum nor even test nothing.
Only a quick update about this protocol.
Some days ago a friend got the MJX X300C (including integrated Wi-Fi FPV).
He tested with last build I provided some days ago, and messaging me everything is working as expected on this model. Even light control and headless mode. The only weird thing he found, when active headless mode, works ok in headless mode but with reduced rates, looks like the quadcopter enter in low mode when active headless mode.

@dc59 could be this issue what you found when you tested headless needed on your X600?

Durete wrote: Hi guys.
I'm on a travel last days so can't follow too much the forum nor even test nothing.
Only a quick update about this protocol.
Some days ago a friend got the MJX X300C (including integrated Wi-Fi FPV).
He tested with last build I provided some days ago, and messaging me everything is working as expected on this model. Even light control and headless mode. The only weird thing he found, when active headless mode, works ok in headless mode but with reduced rates, looks like the quadcopter enter in low mode when active headless mode.

@dc59 could be this issue what you found when you tested headless needed on your X600?

Hi Durete,

I'm terribly sorry about the test result last week,there was something wrong .....

The weather here was finally stop raining and took my x600 for a outdoor test, headless mode works fine, I can't fill any rate reduced,it's almost the same! The mistake I made last week for indoor test was I flew it too low because my room is quite small and I can't fly high.

I apologize for confusion again.

Edit : I use this build deviation-devo7e-v4.0.1-4774285, Durete's combo build.

dc59 wrote:

Durete wrote: Hi guys.
I'm on a travel last days so can't follow too much the forum nor even test nothing.
Only a quick update about this protocol.
Some days ago a friend got the MJX X300C (including integrated Wi-Fi FPV).
He tested with last build I provided some days ago, and messaging me everything is working as expected on this model. Even light control and headless mode. The only weird thing he found, when active headless mode, works ok in headless mode but with reduced rates, looks like the quadcopter enter in low mode when active headless mode.

@dc59 could be this issue what you found when you tested headless needed on your X600?

Hi Durete,

I'm terribly sorry about the test result last week,there was something wrong .....

The weather here was finally stop raining and took my x600 for a outdoor test, headless mode works fine, I can't fill any rate reduced,it's almost the same! The mistake I made last week for indoor test was I flew it too low because my room is quite small and I can't fly high.

I apologize for confusion again.

Edit : I use this build deviation-devo7e-v4.0.1-4774285, Durete's combo build.

That build is using Hexfet's code, without autoflip disabled on high rates or light control. Is using the same code from Hexfet's test build.
Makes sense headless mode is working right using that build

Durete wrote: That build is using Hexfet's code, without autoflip disabled on high rates or light control. Is using the same code from Hexfet's test build.
Makes sense headless mode is working right using that build

I apologized that I made so many mistakes ..........

Back to FW "deviation-devo7e-v4.0.1-eabe723" and test it outdoor again, I found headless function work OK if head orientation at 9/12/3 o'clock direction,the only problem is 'nose in' (6 o'clock direction) DR rate became very very low , it still can be control but moves very slow , if I turn it back to other orientation is works fine in high rate.

I'm confused
Which build to use now for X600?
I'm at deviation-devo7e-v4.0.1-ee51ea2