Sky Walker protocol for XINXUN X39

Hi,

I just received a new chinese quad, i.e the XINXUN X39
www.tmart.com/XinXun-X39-4-Channel-2.4G-...RTF-Red_p242253.html
which is compatible with the Skywalker protocol (just need to invert RUD channel). Thanks again to HexFet for his work.
3 others quad should share the same protocol: X28, X33, X40

Compared to the original TX, the yaw rate of the quad controled by the Devo is slower (at least 30%). I changed scale up to 125% but no real improvement. Does some extreme values must be hard-coded in the protocol ?

The stock transmitters for this protocol send trim values separate from channel control in the data packets. Since Deviation trim doesn't work that way, the protocol drives the trims to get extra control range.

Since you had to invert rudder, now the driven trims are working against the control inputs. The Ares QX75 should have the same trouble on roll since it requires inverted aileron.

I'll look at the code and see if it's possible to detect inverted channels. Then I could reverse the trim appropriately. If not, I'll add a protocol option to not drive the trim channels.

Thanks for the report!

hexfet wrote: The stock transmitters for this protocol send trim values separate from channel control in the data packets. Since Deviation trim doesn't work that way, the protocol drives the trims to get extra control range.

Since you had to invert rudder, now the driven trims are working against the control inputs. The Ares QX75 should have the same trouble on roll since it requires inverted aileron.

I'll look at the code and see if it's possible to detect inverted channels. Then I could reverse the trim appropriately. If not, I'll add a protocol option to not drive the trim channels.

Thanks for the report!

Well .... the RX board died (a mosfet) after the second flight .... I can't even finish the reviewing ....

One more point, the flipping channel seems different too. By the way, I have to replace burnt MOSFET before to test your modded YD-717 protocol for XinXin quadcopters





If anyone know a good source to pick up such MOSFET "2310" ?

PhracturedBlue wrote: I am assuming it is this:
www.vishay.com/docs/67036/sq2310es.pdf
which looks like an n-channel high-current FET. You could likely replace it with any high-current nfet.
For instance, replace it with an AO3402 or IRLML2502 (not quite as high current, but probably more than acceptable). Both of those are available on ebay.

Thanks PB,

I think I got some IRLML2502 already ... but as you mentioned, they are not accepting the same amount of current ...

PhracturedBlue wrote: is it noticeable? I'm surprised you can put 4 Amps through those motors. Of course they may need to be balanced between all motors, so that might be a problem.

Yes ... I need some extra work to replace all MosFet I am not good to unsolder such tiny stuff.

The RX Board looks very similar to the (red PCB) Xinxun X30 board (also YD-717 protocol). It even has the camera port.

Too bad the FET burned - anyway don't fear to solder, plenty of room there

I'd try with replacing only the burnt one first - not too sure if you will notice different motor speeds due to different internal resistance. But I cannot see a problem due to maximum load - but you should ensure that the motor or wires are not shortened before trying again.

Just desolder the old one: Have something to grab under the FET in place, heat single pin first and try to raise FET so it no longer in contact when solder cools down. Next two should be even easier then.

Then add some solder to the pads, place new FET at right place (should have some tool to hold it in position) and heat each pin until solder flows, gently pressing FET down with tool.

Good luck with that !

btoschi wrote: The RX Board looks very similar to the (red PCB) Xinxun X30 board (also YD-717 protocol). It even has the camera port.

Too bad the FET burned - anyway don't fear to solder, plenty of room there

I'd try with replacing only the burnt one first - not too sure if you will notice different motor speeds due to different internal resistance. But I cannot see a problem due to maximum load - but you should ensure that the motor or wires are not shortened before trying again.

Just desolder the old one: Have something to grab under the FET in place, heat single pin first and try to raise FET so it no longer in contact when solder cools down. Next two should be even easier then.

Then add some solder to the pads, place new FET at right place (should have some tool to hold it in position) and heat each pin until solder flows, gently pressing FET down with tool.

Good luck with that !

Thanks for the tips ....

Good news if X30 is also supported. I guess all XinXun quads: X28, X30, X33, X35, X38, X40 .... to be confirmed

I've got a fix for the trim reversal, but I have a concern it might break the Ares if that quad already has the trim channel reversed on aileron. I've pm'd John-Boy and asked if the roll rate on that quad is about the same as the pitch rate when ailerons are reversed.

If the Ares works fine with the current code I'm thinking a protocol option for "reverse extra drive" or maybe just to disable driving the trim channels. I don't want to give up the wider limits completely - they make the YD717 fun to fly and I still fly it often.

I'd make a build for you to try SeByDocKy but not sure how to build the nightly. I had to set HAS_MULTIMOD_SUPPORT to 0 in target_defs.h to get a version that works in the emulator. Otherwise uncommenting enable-nrf24l01 in hardware.ini results in a "Missing Module: MultiMod" error when starting the emulator. Haven't tried it in the real tx yet (getting late here). Hoping someone who knows the answer will post Should HAS_MULTIMOD_SUPPORT be set to 0 unless the multimodule is installed?

hexfet wrote: I've got a fix for the trim reversal, but I have a concern it might break the Ares if that quad already has the trim channel reversed on aileron. I've pm'd John-Boy and asked if the roll rate on that quad is about the same as the pitch rate when ailerons are reversed.

If the Ares works fine with the current code I'm thinking a protocol option for "reverse extra drive" or maybe just to disable driving the trim channels. I don't want to give up the wider limits completely - they make the YD717 fun to fly and I still fly it often.

I'd make a build for you to try SeByDocKy but not sure how to build the nightly. I had to set HAS_MULTIMOD_SUPPORT to 0 in target_defs.h to get a version that works in the emulator. Otherwise uncommenting enable-nrf24l01 in hardware.ini results in a "Missing Module: MultiMod" error when starting the emulator. Haven't tried it in the real tx yet (getting late here). Hoping someone who knows the answer will post Should HAS_MULTIMOD_SUPPORT be set to 0 unless the multimodule is installed?

It's amazing the number of Toyquad based on a slight variation of the same protocol .

Here's a version that should fix the yaw issue on the XinXun. Some motivation to fix the rx board

I didn't hear back from the guy with the Ares, so instead of checking for reversed channels I just added another format in the protocol option. Set the format to XinXun. You should not need to reverse the rudder channel with this setting.

Not sure about the flip enable. Does it just not work for the XinXun? Best would be to get an SPI capture. For YD717 the flip is enabled by changing one of the data bytes from 00 to 0F. We could try guessing other values but an SPI trace would be easiest. How does the stock transmitter flip work? Do you hold down the flip button, then move the cyclic in the direction you want to flip?

hexfet wrote: Here's a version that should fix the yaw issue on the XinXun. Some motivation to fix the rx board

I didn't hear back from the guy with the Ares, so instead of checking for reversed channels I just added another format in the protocol option. Set the format to XinXun. You should not need to reverse the rudder channel with this setting.

Not sure about the flip enable. Does it just not work for the XinXun? Best would be to get an SPI capture. For YD717 the flip is enabled by changing one of the data bytes from 00 to 0F. We could try guessing other values but an SPI trace would be easiest. How does the stock transmitter flip work? Do you hold down the flip button, then move the cyclic in the direction you want to flip?

File Attachment:

File Name: deviation-...1ff4.zip
File Size:118 KB

Thanks Hex,

I don't have have yet the exaxt MOSFET (I tried to have some free sammple from vishay ... but not answer yet).

Great new for the new option of the YD 717 (now I am thinking, maybe we can also insert the syma X2 protocol into this framework).

For the flipping button, you press prior the flipping button (release it) and the turn the cyclic in the direction you want to flip. In the worst case, I will plug the SPI in the TX, don't worry. First I need to have this
sq2310es FET

Sorry hexfet, i don't have any pm's in my inbox.

I didn't get to try anything, my Pop is in the hospital so things are on hold...

Keep up the good work guys...

hexfet wrote: Here's a version that should fix the yaw issue on the XinXun. Some motivation to fix the rx board

I didn't hear back from the guy with the Ares, so instead of checking for reversed channels I just added another format in the protocol option. Set the format to XinXun. You should not need to reverse the rudder channel with this setting.

Not sure about the flip enable. Does it just not work for the XinXun? Best would be to get an SPI capture. For YD717 the flip is enabled by changing one of the data bytes from 00 to 0F. We could try guessing other values but an SPI trace would be easiest. How does the stock transmitter flip work? Do you hold down the flip button, then move the cyclic in the direction you want to flip?

File Attachment:

File Name: deviation-...1ff4.zip
File Size:118 KB

John-Boy wrote: Sorry hexfet, i don't have any pm's in my inbox.

I didn't get to try anything, my Pop is in the hospital so things are on hold...

Keep up the good work guys...

Thanks for the update. Best wishes for your dad.

Protocol option is probably safer than making assumptions about the channel<->trim relationship anyway. Hopefully the manufacturers will quit tweaking the protocol before the option list gets too long.

Any chance to get the source code / diff for that ?

Seems my SLH toy quads do strange things when flown with Deviation and YD717 protocol - and I was able to fly with X30-V TX (and vice versa) w/o problems, so they should use the very same protocol.
When using Deviation (build from PB's repo, around one week old) the quad won't react to all input as if it's missing packets and receiver uses last valid packet, which e.g. means full throttle, eve that you've already cut throttle a while ago. Nearly killed my copters with that ... (luckily only 'nearly' )

I ordered the Mosfet... Hope to receive it next week and will solder it. So expecting some tests not before next week.

btoschi wrote: Any chance to get the source code / diff for that ?

Sure, I've pushed the change to my repo at bitbucket.org/hexfet/deviation.

The XinXun format only changes handling of the rudder channel, so I don't expect it to change the symptoms you describe. Sounds like some deeper difference in the protocol. Might need an SPI capture of the post-bind data to figure it out.

Likely another change will be needed for XinXun for the flip control too.

Ok

Unfortunatly, MOSFET was not some vishay but some "CYStech MTN2310N3" in SOT-23 packaging.... Up to 60V and 4A... Unfortunatly, there are very hard to find ... Only in china with my first search ...