New SYMA protocol

hexfet wrote: Thanks. It looks like the data packet is the same as for the YD717, including the auto-flip enable. So the problem may be in the channel ordering. The YD protocol expects AETR - aileron on channel 1, elevator on 2, throttle on 3, and rudder on 4.

Did you try the model file attached above? I believe that's where the channel ordering is set, but maybe there's a tx config also. I can check tonight.

Yes I checked with your model file .... Same problem with it ... I am feeling also a problem in the channels order ...

Looking at the code I believe the channel order is set by the protocol definition, so the posted model file should be correct.

Is your TX configured for Mode 2? Is the Syma controller mode 2?

For the latest capture files it was easy to spot the throttle channel in the left_stick data. For the right_stick data do you remember the directions in which you moved the stick? From the data it looks like down, up, left, right. If that's not correct maybe aileron/elevator need to be swapped or reversed.

It's also possible that the trims are different in the data packets. Would you please make a capture while just changing the trims, and let me know the order in which you went through them? Also would be helpful if you change the SPI display setting to Hexadecimal before exporting. Seems like there were a few missing values in the ascii export.

I've attached a version of the protocol that does not drive the trim channels if you'd like to try it.

hexfet wrote: Looking at the code I believe the channel order is set by the protocol definition, so the posted model file should be correct.

Is your TX configured for Mode 2? Is the Syma controller mode 2?

For the latest capture files it was easy to spot the throttle channel in the left_stick data. For the right_stick data do you remember the directions in which you moved the stick? From the data it looks like down, up, left, right. If that's not correct maybe aileron/elevator need to be swapped or reversed.

It's also possible that the trims are different in the data packets. Would you please make a capture while just changing the trims, and let me know the order in which you went through them? Also would be helpful if you change the SPI display setting to Hexadecimal before exporting. Seems like there were a few missing values in the ascii export.

I've attached a version of the protocol that does not drive the trim channels if you'd like to try it.

1) yes, both in mode 2 ...

2) Yes I think you are right down->up then left->right. If you want I can make another capture exactly in this order ?

3) Ok I can make capture playing with triming. I will start Trim down then trim up then trim left to finish trim right of the right stick ok ?

Ok here the log in hexa playing with right trimming

down then up then left then right


www.wetransfer.com/downloads/89aded454e0...0140203201748/955ed5

Ok,

I just tested your last version of protocol, seems to work very well


Bravo !!!

A video

SeByDocKy wrote: Ok here the log in hexa playing with right trimming

down then up then left then right

This order is fine. Can you tell when the trim is maxed out - maybe a beep from the tx? If you can move to the max, then leave there for a second before moving to the next endpoint we can find out the max range of the trim values.

Also in this capture something goes wrong from about 2.5 seconds to 7.7 seconds - all the MOSI values are FF. Maybe an intermittent connection?

The trim values are in different places for the Syma compared to the YD717. I can make an adjustment if we can figure out what data goes where.

Or just leave the trims in the data packet neutral. Glad to hear it's flying!

hexfet wrote:

SeByDocKy wrote: Ok here the log in hexa playing with right trimming

down then up then left then right

This order is fine. Can you tell when the trim is maxed out - maybe a beep from the tx? If you can move to the max, then leave there for a second before moving to the next endpoint we can find out the max range of the trim values.
:

Only beeping when I am in the central position and no LCD display so hard to know if I reach the max limit. Ok I will press 10 times. So I will keep the same sequence : Down->Up->left->right

Here is the new log ....


www.wetransfer.com/downloads/5aabfac5244...0140203213547/56afe7

That's perfect. Looks like it would take 64 clicks to get to max trim.

Thanks for the video! Fun to watch

Please try the attached, which drives the trim channels to give extra control range. If this makes the quad uncontrollable we can go back to fixed trim values.

Ok

It's working with this last build but it's like to be in "extreme sport" mode... Now this is quad is very nervous like this (haha good point). Probably, I need to setup a model file with beginner mode with lower value and sport mode like this ?

I find maybe a minor issue. For example, it's not possible to rebind a second time the quad. You have to switch off this latter.

Anyway it's flying very well with a devo TX




In general, IMHO the protocol shoud be standalone and not including with the YD-717.... Coz, with upcoming models, probably a sixth even seventh channels should be added. Of course, PB should tell his point of view

Nice flying! Yes, you can tone it down by reducing the scale on the tx. About 85 should be similar to the stock tx high rate.

Can you describe the steps to reproduce the rebind issue? If the quad is bound and you turn the tx off and on or click re-init, it should re-connect to the quad (if the rx works like the yd717). However if you turn the quad off, after turning it back on it will be waiting to bind. Then you have to re-init or turn the tx off and on.

I'll wait for comments on recommended implementation. (The current test code has a protocol option to choose the model.) I think I understand from wk2x01.c how to support multiple protocols from one source. The differences from yd717 are minor.

I am curious as to how the two protocols from different companies ended up so similar...

hexfet wrote: Can you describe the steps to reproduce the rebind issue? If the quad is bound and you turn the tx off and on or click re-init, it should re-connect to the quad (if the rx works like the yd717). However if you turn the quad off, after turning it back on it will be waiting to bind. Then you have to re-init or turn the tx off and on.

Ok I have two config file for the SYMA X4. So when your SYMA have been first binded by model 1 then if I am loading the model 2, I can't rebind without switch off->on the quad.


To answer to your last remark, I know those compagnies usually are sub-contracting the RF design. So many they are sharing the same sub-contracting compagny

HexFet, Maybe it's time to push your modified code ?

SBDK, please test the attached version with the Syma X4. I changed the implementation to create a new "SymaX" protocol. I've tested this version with the YD717 on a Devo10 and everything seems to be working.

This version includes the new small gui so I believe you'll need to update your filesystem also. For my Devo10 I copied the language, media, and layout directories. The new gui is nice!

Open to suggestions for a better name than "SymaX" for the protocol. Besides the X4 it's also likely to work for the X2 and X7. Definitely not the X1 (which already works with flysky). Syma's not making it easy to choose a name. I guess the 'X' is supposed to represent a quadcopter.

hexfet wrote: SBDK, please test the attached version with the Syma X4. I changed the implementation to create a new "SymaX" protocol. I've tested this version with the YD717 on a Devo10 and everything seems to be working.

This version includes the new small gui so I believe you'll need to update your filesystem also. For my Devo10 I copied the language, media, and layout directories. The new gui is nice!

Open to suggestions for a better name than "SymaX" for the protocol. Besides the X4 it's also likely to work for the X2 and X7. Definitely not the X1 (which already works with flysky). Syma's not making it easy to choose a name. I guess the 'X' is supposed to represent a quadcopter.

Ok I will test ..... I got the feeling that it's also working for the SYMA X3 in this case why not call it "SYMA X2+" ?

HexFet,

Just tried your new "standalone" protocol.... It's working perfectly

According to www.rcmaster.net/de-empf-nger-platiene-f...x3-x3-07-p235047.htm

the SYMA X3 seems to have the same RFchip, so it should also work your protocol hacking

Thanks for testing Good news on the X3. Will be interesting to see if it has any extra features.

From the pictures on banggood it looks like the Syma X5C and X6 still use the X1 controller. Maybe call the protocol "Syma2347"? Seems it's going to be confusing no matter what. They'll be coming out with more models too...