- Posts: 610
which is MJX use protocol ?
- Durete
- Offline
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
Please Log in or Create an account to join the conversation.
- dc59
- Offline
- Posts: 799
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!
Please Log in or Create an account to join the conversation.
- Durete
- Offline
- Posts: 610
Unfortunately, I don't know what's wrong at the code
This is packet for headless off (medium mode):
2.744256 > TX_PAYLOAD a0 8a 00 00 00 40 40 40 f8 4f 1c 00 00 00 00 02 af => 0e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
And this is the packet for headless On:
2.747980 > TX_PAYLOAD a0 8a 00 00 00 40 40 40 f8 4f 1c 00 00 00 00 22 cf => 0e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
And this is the code I'm using for packet 14:
packet[14] = bind ? 0xc0 : 0x02 | GET_FLAG(CHANNEL_FLIP, 0x04)
| GET_FLAG(CHANNEL_PICTURE, 0x08)
| GET_FLAG(CHANNEL_VIDEO, 0x10)
| GET_FLAG(CHANNEL_HEADLESS, 0x20);
I tested with the emulator and seems to be working as should be:
next chan 0x3a, bind 0, data 00 00 80 00 40 40 3f 12 4f 1c 10 00 00 00 02 ce
next chan 0x42, bind 0, data 00 00 80 00 40 40 3f 12 4f 1c 10 00 00 00 02 ce
next chan 0x42, bind 0, data 00 00 80 00 40 40 3f 12 4f 1c 10 00 00 00 02 ce
next chan 0x0a, bind 0, data 00 00 80 00 40 40 3f 12 4f 1c 10 00 00 00 02 ce
next chan 0x0a, bind 0, data 00 00 80 00 40 40 3f 12 4f 1c 10 00 00 00 02 ce
next chan 0x46, bind 0, data 00 00 80 00 40 40 3f 12 4f 1c 10 00 00 00 22 ee
next chan 0x46, bind 0, data 00 00 80 00 40 40 3f 12 4f 1c 10 00 00 00 22 ee
next chan 0x3a, bind 0, data 00 00 80 00 40 40 3f 12 4f 1c 10 00 00 00 22 ee
next chan 0x3a, bind 0, data 00 00 80 00 40 40 3f 12 4f 1c 10 00 00 00 22 ee
next chan 0x42, bind 0, data 00 00 80 00 40 40 3f 12 4f 1c 10 00 00 00 22 ee
next chan 0x42, bind 0, data 00 00 80 00 40 40 3f 12 4f 1c 10 00 00 00 22 ee
next chan 0x0a, bind 0, data 00 00 80 00 40 40 3f 12 4f 1c 10 00 00 00 22 ee
next chan 0x0a, bind 0, data 00 00 80 00 40 40 3f 12 4f 1c 10 00 00 00 22 ee
next chan 0x46, bind 0, data 00 00 80 00 40 40 3f 12 4f 1c 10 00 00 00 22 ee
next chan 0x46, bind 0, data 00 00 80 00 40 40 3f 12 4f 1c 10 00 00 00 02 ce
next chan 0x3a, bind 0, data 00 00 80 00 40 40 3f 12 4f 1c 10 00 00 00 02 ce
next chan 0x3a, bind 0, data 00 00 80 00 40 40 3f 12 4f 1c 10 00 00 00 02 ce
next chan 0x42, bind 0, data 00 00 80 00 40 40 3f 12 4f 1c 10 00 00 00 02 ce
I don't know what's is wrong
Please Log in or Create an account to join the conversation.
- dc59
- Offline
- Posts: 799
Please Log in or Create an account to join the conversation.
- Durete
- Offline
- Posts: 610
I'm fairly confident someone will come to help us
Please Log in or Create an account to join the conversation.
- hexfet
- Offline
- Posts: 1891
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?
Please Log in or Create an account to join the conversation.
- Durete
- Offline
- Posts: 610
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).
Please Log in or Create an account to join the conversation.
- Durete
- Offline
- Posts: 610
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
Please Log in or Create an account to join the conversation.
- dc59
- Offline
- Posts: 799
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!
Please Log in or Create an account to join the conversation.
- Durete
- Offline
- Posts: 610
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.
Please Log in or Create an account to join the conversation.
- Lukappaseidue
- Offline
- Posts: 15
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.
Please Log in or Create an account to join the conversation.
- homl
- Offline
- Posts: 2
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.
Please Log in or Create an account to join the conversation.
- dc59
- Offline
- Posts: 799
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!
Please Log in or Create an account to join the conversation.
- homl
- Offline
- Posts: 2
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.
Please Log in or Create an account to join the conversation.
- Lukappaseidue
- Offline
- Posts: 15
Please Log in or Create an account to join the conversation.
- Durete
- Offline
- Posts: 610
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?
Please Log in or Create an account to join the conversation.
- dc59
- Offline
- Posts: 799
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.
Please Log in or Create an account to join the conversation.
- Durete
- Offline
- Posts: 610
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
Please Log in or Create an account to join the conversation.
- dc59
- Offline
- Posts: 799
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.
Please Log in or Create an account to join the conversation.
- Morphin
- Offline
- Posts: 6
Which build to use now for X600?
I'm at deviation-devo7e-v4.0.1-ee51ea2
Please Log in or Create an account to join the conversation.
- Home
- Forum
- Development
- Protocol Development
- which is MJX use protocol ?