which is MJX use protocol ?

@Durete. Can you share to us your config file and modified hex file (c fille) ?

SeByDocKy wrote: @Durete. Can you share to us your config file and modified hex file (c fille) ?

Sure! As soon I return home, I'm out now.
Anyway, it's the latest code from Hexfet with driven trims at rudder channel disabled and using a fixed center value (0x40 if I remember good)
I will start to test with lower values at rudder driven trim, but not too much free time last days (even in vacations )

I decoded the lights, Rates, Picture and Video SPI captures and this is what I found:

Lights On:
Lights Off:
Packet 10?

Picture (Seems to be packet 14. Same flag as WLH-08 protocol ):
Video (Seems to be packet 14. Same flag as WLH-08 protocol ):
Also, I found the difference between medium/high rates mode and maybe this flag could disable the annoying autoflip feature :
In medium mode, the packet 14 is always at 02 valueIn high mode (autoflip at 90% stick position) the packet 14 is always at 04 value
I guess using this flag we can enable/disable the autoflip feature assigning to the Flip channel (6 as always)

Hope this info will be helpful

Also, I found something weird decoding the Autoflip feature (pressing button at stock TX, not flip at extreme stick position)

According my captures, the packet 10 change from 0x10 value to 0x11 pressing the flip button.

So maybe the packet 10 is:
0x10 Lights on
0x11 Perform automatic flip (with TX button)
0x12 Lights off

Thoughts?

Edit: UPPS....!!!! My bad. I didn't notice I captured the flip button with 0 throttle. Perhaps this weird Flag instead the 0x01 Flag at Packet 14 in Hexfet's code

Edit 2. I confirmed this info.It's not related to 0 throttle, Packet 10 is used by the flip button. Weird, since the X600 captures are using packet 14 for flip button...

Just tested and confirmed the light control and Autoflip feature disable
Packet 10 with 0x12 value turns off the lights.
Packet 14 with 0x02 value disable the Autoflip feature even with 100% stick mouvements. Probably using 0x00 value enable the low rate mode (useless for us since we limit the rates using the Deviation Mixer).

Since you know my programming skills are very basic, I tested modifying Hexfet's code at hand
So can't provide a code with those changes
I'm only trying to do my best helping to finish the protocol
(and BTW learn some C programming )

@ SebyDocky

I attached my model file, icon file and C file (99.9999999999% Hexfet's code )
I only disable the driven trims at rudder channel, and disable the autoflip feature modifying packet 14 value.
Credits for the icon file to some user from Deviation Forum, sorry I don't remember where I found.
Be careful when testing

Ok, almost there ...
I have fully working light control, Autoflip enable/disable with max stick position and Autoflip button, at least on my X800.
Channel 5 is light control
Channel 6 is autoflip enable/disable (with max stick input)
Channel 7 is Picture
Channel 8 is Video
Channel 9 is Headless
Channel 10 is RTH
Channel 11 is Autoflip button.

Since my programming skills are very very basic, I don't know how to reverse the functions at the code, so channel 5 (light control) is working reversed. At -100 value lights are on, at 100% value are off.

I can't test Headless and RTH since the X800 doesn't have those functions, but I guess continue working.
Anyone with an X400/X600 or even X900 can test? Especially interested to test the extra functions (Headless, RTH, Lights, Autoflips, Picture, Video ...)
Here is the build:
dl.dropboxusercontent.com/u/14941708/dev...e-v4.0.1-eabe723.zip

Since I'm not a coder, and maybe the code is not right, or even unsafe to use, I will not post the code to everyone. Only to recognised developers (Hexfet, are you reading ? )

As I wrote before, this is 99.99999999% Hexfet's code, so thank you again for you hard work for Deviation Community


My model file valid for 7e with 2 extra switches:
Throttle Trim Up . Picture
Throttle Trim Down. Video.
Rudder Trim right. On/Off lights
SWB Switch . 3 rates.
Hold 1. Cut throttle
Fmod1 Activate Flips at full stick input.
Exit. Autoflip button.

I checked this build with X800 and X400 (v1). So - no headless nor RTH, as they do not have it both. Also no camera. Light on ch5 works for X800 but not X400. I think it is normal as X400 do not have light control on stock TX. Flips on channels 6 and 11 both work as expected on both. Pitch rate is great on both. Yaw rate is not great but as on stock TX, as far as I remember. By the way - there is no visible difference in yaw on 100 and 80 value. I checked it with values 60-80-100 on SWA. 60 seems to be little bit slower than 80. 100 gives nothing above 80. So may be there are some reserves to improve yaw?..

Great! Thanks for testing.
This is good news because at least we know the flip controls are working also on a different quadcopter than X800 (X400).
The pitch and roll channels are using Dynamic Trims (Hexfet code) but I disabled Dynamic Trims at rudder channel because I found a weird behavior on this channel when using Dynamic trims. I guess the receiver is not receptive to use this trick . So is unlikely we can increase the stock yaw rate. In my opinion the yaw rate is not too bad since I think the X800 and his bigger brothers are outdoor flyers. Anyway probably should be better a faster yaw rate for the X900.
I also noticed Vasily's impression about the rudder channel with bigger values than 80%, I think the yaw rate is even slightly decreased when we reach values near 100%.
The rudder channel is using now the same values as stock TX, so perhaps the stock TX is using an expo curve? Who knows...
@Vasily
Did you noticed any similar behavior at rudder channel using the stock TX? Since I only have my X800 for about a week, I have flown with stock tx about 2 times...

Now we need someone test this build using the X600, X900 and maybe ¿X500? It's very important to test the extra functions to check those functions continues working in other models.
Probably I could test picture and video functions with an X300C in a few days/weeks.

Ok, just tested with Stock TX and I think the behaviour is the same.
The yaw rate is increased till about 80%. After this point the rate isn't increased any more. I have the feel the rate is even slightly decreased from about 90-95% till 100%.
Tested on X800.

Hi Durete,

I don't have time to do more test these days,sorry,I tested only few minutes on my X600.

Channel 5 is light control => No function (X600 stock TX has no this function.)
Channel 6 is autoflip enable/disable (with max stick input) => OK
Channel 7 is Picture => Not tested, I don't have x600 cam.
Channel 8 is Video => Not tested, I don't have x600 cam.
Channel 9 is Headless => Light is flashing,but orientation is not locked,need more test,I can't figure it out now.
Channel 10 is RTH => No works,same as normal mode after i activated it.
Channel 11 is Autoflip button. => OK

I will do more test for headless funtion if I have time these two days,thanks Durete for your help!

Damn!
@DC59
Did you use my model file?
I found, I uploaded a model file with safety switch at channel 10 (RTH) . If you used my model file that's the problem with RTH because I didn't modify code on this packet from last (working) version from Hexfet.
About the Headless feature, makes more sense to not work since a modify the Packet related Please test more when you have more time.

I uploaded my model file at my previous post removing the safety feature at channel 10.
I tested the build using the emulator and is working as expected (0x01 at packet 11 when enable RTH)

Durete wrote: Ok, almost there ...
Since I'm not a coder, and maybe the code is not right, or even unsafe to use, I will not post the code to everyone. Only to recognised developers (Hexfet, are you reading ? )

Seems to me you're doing fine! Anyone building your changes would know to be careful.

Best would be to make a pull request against my repo. Or you can pm a link to your code.

Durete wrote: Damn!
@DC59
Did you use my model file?
I found, I uploaded a model file with safety switch at channel 10 (RTH) . If you used my model file that's the problem with RTH because I didn't modify code on this packet from last (working) version from Hexfet.
About the Headless feature, makes more sense to not work since a modify the Packet related Please test more when you have more time.

I uploaded my model file at my previous post removing the safety feature at channel 10.
I tested the build using the emulator and is working as expected (0x01 at packet 11 when enable RTH)

Yes , I used your model file, sorry I didn't check ch10 setting before I tested it!
I'll confirm that ASAP.
Thanks!

Durete wrote: Ok, just tested with Stock TX and I think the behaviour is the same.
The yaw rate is increased till about 80%. After this point the rate isn't increased any more. I have the feel the rate is even slightly decreased from about 90-95% till 100%.
Tested on X800.

Perhaps dynamic trim needs to be configured with this in mind.

@Durete

I tried X600 one more times with new model file , CH10 RTH is now working good!

CH9 Headless mode still not OK, it's weird , when I activated headless if head orientation is 12 o'clock to 3 o'clock it's like normal ,nothing is changed, when I turned it to 6 o'clock or 9 o'clock I can fill DR rate is changed , it moved very slow and X600 always move to left side whatever you moved any stick,I can't control it.

hexfet wrote:

Durete wrote: Ok, almost there ...
Since I'm not a coder, and maybe the code is not right, or even unsafe to use, I will not post the code to everyone. Only to recognised developers (Hexfet, are you reading ? )

Seems to me you're doing fine! Anyone building your changes would know to be careful.

Best would be to make a pull request against my repo. Or you can pm a link to your code.

Thanks for your kind words
I'm trying to do my best in the hope to help as much as possible.
But since I'm a hardware man and never programmed in C before, is really difficult to me. I'm learning on the way .
This a challenge to me
I will send to you by PM your code modified by me to amend my mistakes


@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

Thanks!

For everyone.
Should be helpful a test for light controls/Headless/RTH with an X900 (I guess the X900 has Headless/RTH)

May be best to calibrate headless mode before flying to rule out confusion on heading.

Better than relying on calibration at startup.

@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!

Richard96816 wrote: May be best to calibrate headless mode before flying to rule out confusion on heading.

Better than relying on calibration at startup.

Yes, I calibrated headless mode every time I landed or crashed or before took off .... but it still the same