SYMA X5C-1, X11, X12

Durete wrote:

SeByDocKy wrote: It's a SYMA X5C. In fact, I didn't bind the quadcopter ... but yes I can control perfectly the quad with your new syma implementation...
Maybe do you want some new capture with the quad turned on too ?

Maybe a Syma X5S (Explorers 2) ? not an X5C

Yes I mean X5SC

Can the X5S transmitter control an X5C-1? The bind packets are different. I'm wondering if the X5S is backwards-compatible with X5C-1 by accident or on purpose.

Doesn't matter if the quad is on because the tx doesn't receive anything from the rx in this protocol.

Please check if headless mode works in the attached build. Control is on channel 9. This build is the latest nightly plus the SymaX changes (headless mode and rf channel fix).

Protocol differences from SymaX:

• 1 of the 4 rf channels used for binding is different, so X5S will only see 75% of the SymaX bind packets (and until I fix a wrong channel constant in the current code, only 50%).
• Initialization of the rf module uses mostly the same values as SymaX but sent in different order. Differences are that power output is set to -12dBm for the bind phase, and the rf chip retransmit feature is disabled.
• Two types of bind packets are sent, alternating every 8 packets. The first type contains the tx address, but the first byte is 0xa1 (SymaX uses 0xa2). The two bytes before the checksum are 0xbbb1 (SymaX sends 0xaa00). Perhaps one or more of these is a version indicator.
• The second bind packet type contains the same values used as starting points in the set_channels() algorithm in SymaX. Possibly this version of the protocol allows changing the starting values for choosing the rf channels used in data phase? Since SymaX does not send this packet type the X5S likely defaults to the same values used for X5C-1.
• X5S re-initializes the rf module after sending the bind packets. All the initialization values are written again, but the only one that's changed is output power, to 0dBm (the maximum).
• During the data phase every 16th packet is sent with a bad checksum. The value is always 4 regardless of the data in the packet.

hexfet wrote: Can the X5S transmitter control an X5C-1? The bind packets are different. I'm wondering if the X5S is backwards-compatible with X5C-1 by accident or on purpose.

Doesn't matter if the quad is on because the tx doesn't receive anything from the rx in this protocol.

Please check if headless mode works in the attached build. Control is on channel 9. This build is the latest nightly plus the SymaX changes (headless mode and rf channel fix).

Protocol differences from SymaX:

• 1 of the 4 rf channels used for binding is different, so X5S will only see 75% of the SymaX bind packets (and until I fix a wrong channel constant in the current code, only 50%).
• Initialization of the rf module uses mostly the same values as SymaX but sent in different order. Differences are that power output is set to -12dBm for the bind phase, and the rf chip retransmit feature is disabled.
• Two types of bind packets are sent, alternating every 8 packets. The first type contains the tx address, but the first byte is 0xa1 (SymaX uses 0xa2). The two bytes before the checksum are 0xbbb1 (SymaX sends 0xaa00). Perhaps one or more of these is a version indicator.
• The second bind packet type contains the same values used as starting points in the set_channels() algorithm in SymaX. Possibly this version of the protocol allows changing the starting values for choosing the rf channels used in data phase? Since SymaX does not send this packet type the X5S likely defaults to the same values used for X5C-1.
• X5S re-initializes the rf module after sending the bind packets. All the initialization values are written again, but the only one that's changed is output power, to 0dBm (the maximum).
• During the data phase every 16th packet is sent with a bad checksum. The value is always 4 regardless of the data in the packet.

Ok ... I will try, can you provide me also the source file directly ? coz I think I will test more easily with my Devo10

I am suprized that with such changes, it's already perfectly working with the actual SymaX protocol ....

Ok I tried ... and it's working for the headless mode ....

Now I think after your remarks I Will also capture for headless for the syma X8C in case if there are some difference

You know maybe, it's not related but I noticed rates (pitch, yaw, ect ...) are better/faster with the deviationTX hacking than the original Syma X5SC radio.... maybe, the slight difference you saw can be explained by this fact ?

SeByDocKy wrote: You know maybe, it's not related but I noticed rates (pitch, yaw, ect ...) are better/faster with the deviationTX hacking than the original Syma X5SC radio.... maybe, the slight difference you saw can be explained by this fact ?

The pitch, roll and yaw rates are higher in "old" Syma quadcopters also using SymaX protocol (X11, X11C, X5C...)
I think this is because Hexfet used the trim values to maximize the rates.
So not only in newer X5S, X8C Quadcopters.

Durete wrote:

SeByDocKy wrote: You know maybe, it's not related but I noticed rates (pitch, yaw, ect ...) are better/faster with the deviationTX hacking than the original Syma X5SC radio.... maybe, the slight difference you saw can be explained by this fact ?

The pitch, roll and yaw rates are higher in "old" Syma quadcopters also using SymaX protocol (X11, X11C, X5C...)
I think this is because Hexfet used the trim values to maximize the rates.
So not only in newer X5S, X8C Quadcopters.

Good to know and I like this behaviour in practice

SeByDocKy wrote:

Durete wrote:

SeByDocKy wrote: You know maybe, it's not related but I noticed rates (pitch, yaw, ect ...) are better/faster with the deviationTX hacking than the original Syma X5SC radio.... maybe, the slight difference you saw can be explained by this fact ?

The pitch, roll and yaw rates are higher in "old" Syma quadcopters also using SymaX protocol (X11, X11C, X5C...)
I think this is because Hexfet used the trim values to maximize the rates.
So not only in newer X5S, X8C Quadcopters.

Good to know and I like this behaviour in practice

Yep! 100% agree
The X11 it's a totally different quadcopter flying with SymaX protocol

Thanks for testing! The code is in my repo and I've made a pull request.

Durete is correct about the protocol using the trim data to extend control range. Both yd717 and symax use this technique.

hexfet wrote: Thanks for testing! The code is in my repo and I've made a pull request.

Durete is correct about the protocol using the trim data to extend control range. Both yd717 and symax use this technique.

Ok ... I will test at home when return from work

Two things in your code

1) the
must be remove from SYMAX_cms as far I understood w

2) in build_packet_x5c, I think for packet[14], the |(flag & FLAG_HEADLESS ....) is missing .... but it's a detail ....



I don't understand why we have 0x10 for video ? and not 0x02 as definied at beginning

The PROTOCMD_SET_TXPOWER code was removed a while ago. Are you looking at the pull request or symax_x11 branch in my repo?

Did I miss a capture of the X5C headless control? Do you know what bit is used for headless control in packet[14]?

The FLAG constants indicate whether the function is on or off in the flags variable. Just coincidence if it's same bit position used for the control in the packet.

hexfet wrote: The PROTOCMD_SET_TXPOWER code was removed a while ago. Are you looking at the pull request or symax_x11 branch in my repo?

Did I miss a capture of the X5C headless control? Do you know what bit is used for headless control in packet[14]?

The FLAG constants indicate whether the function is on or off in the flags variable. Just coincidence if it's same bit position used for the control in the packet.

Can you give me the exact URL of this Depo ? maybe I looked wrong ...

SeByDocKy wrote: Can you give me the exact URL of this Depo ? maybe I looked wrong ...

The symax implementation included in the build above is here .

Help! I'm clueless! I just installed the nrf module in my Devo 7E tonight. I downloaded the walkera upgrade software, update to Devention (from the download page - just tonight.. ) I'm trying to find out how to get this to work with my Syma X5C-1, so far I've tried editing the tx.ini file to:

enable-nrf24l01=A13 has_pa-nrf24l01=1

But I don't see the protocol listed when I try to edit the model.. I also found someone elses model file and copied that to no avail.

Did I do something wrong? What can I post to help you help me?

You upgraded to Deviation, not Devention, right? The SymaX protocol is only in the nightly builds - install the latest version listed there.

In the nightly builds the module config is moved to the new hardware.ini file. Enable your module by editing that file.

If you have more questions please start a new topic in General Discussions.

Calibration Command:
Syma X5C-1 TX send Calibration command when hold two stick together right/down.
Some One know which value in wich bit/byte need to be send to give this command?
Thanks Ariel

Have you tried sending the equivalent of those stick positions? Stick commands are usually detected in the receiver on the stick channels, not by the tx sending a special command.

Hello
please tell me .
I lost my syma x12 . But i have transmitter. I can bind my transmitter with this
www.banggood.com/Syma-X5C-Explorers-RC-Q...er-BNF-p-948193.html

Thanks

Yup, assuming you have the nrf module installed and the nightly builds installed