SYMA X5C-1, X11, X12

Hi,

I collected some SPI data from a SYMA X11. It's also the same protocol for the X12 and the X5C-1.

mon-partage.fr/f/9TTsufDq/

Hexfet, if you can have a look since you did the SYMA X4. Maybe, you can add an option to the current SYMA if you manage to hack this new variation ?

I would love to see this as well, but in the meantime I'm swapping a Hubsan receiver into my X11 as soon as it shows up

Need another capture of the left stick up/down - it didn't seem to cover the full range. Is the tx mode 2? Does this quad have hi/lo rate modes? Also need a capture changing the trims if it has them. What do the shoulder buttons do?

Do you know what chip is used? The trace shows setting the 250kbps data rate, but it also shows setting the Bekin 2421 registers and the 2421 doesn't support 250 kbps (according to the data sheet).

The packet check byte doesn't seem to be a simple checksum. Attached file is a list of data packets if anyone can spot the checksum algorithm. Last byte is the checksum.

We can try without the checksum - maybe the receiver won't check Should have something to try in a couple days.

hexfet wrote: Need another capture of the left stick up/down - it didn't seem to cover the full range. Is the tx mode 2? Does this quad have hi/lo rate modes? Also need a capture changing the trims if it has them. What do the shoulder buttons do?

Do you know what chip is used? The trace shows setting the 250kbps data rate, but it also shows setting the Bekin 2421 registers and the 2421 doesn't support 250 kbps (according to the data sheet).

The packet check byte doesn't seem to be a simple checksum. Attached file is a list of data packets if anyone can spot the checksum algorithm. Last byte is the checksum.

We can try without the checksum - maybe the receiver won't check Should have something to try in a couple days.

Yes it's mode 2 TX ... for the Left stick throttle max up, since I didn't want to remove props.... I was not able. Values from right stick is probably the same... But in worst case, I will recapture max deviation for throttle.

The left shoulder button selects the dual rate and right activâtes flips
With the files, you have some with "left_shoulder_button", it means that I engaged the dual rate so you can see max deviation in this mode


Ho it's 250kbits based? the nRF24L01+ can do 250kbits.... It's main probably a BK2423 supporting this rate IMHO ....

It's interesting now they are supporting 250kbits ... I guess to improve the range control (since it's for the X5C-1)

Looked at the datasheet for the 2423 and agree with you.

Can do without the throttle trace but do need the trims if possible.

This protocol is more similar to the green board cx10 than yd717 - does frequency hopping but does not use the auto-acknowledge. It would be messy to make it a yd717 option. Leaning towards changing the current SymaX protocol to be the X11 version, and moving the X2 support to a yd717 option.

Looked at the datasheet for the 2423 and agree with you.

Can do without the throttle trace but do need the trims if possible.

This protocol is more similar to the green board cx10 than yd717 - does frequency hopping but does not use the auto-acknowledge. It would be messy to make it a yd717 option. Leaning towards changing the current SymaX protocol to be the X11 version, and moving the X2 support to a yd717 option.[/quote]

In this case, don't forget to include the Ni Hui variant .... from Bjork...
He added already a fourth option for the tiny quadcopter ...

Please give this a try. Hopefully it will at least bind. I hard-coded the checksum for the bind packets since they're all the same.

The SymaX protocol in this build is for the X11. I added the Ni Hui and SymaX2 protocol options to the YD717 protocol. Models using the current SymaX protocol should be changed to YD717 with the SymaX2 option. Do you have Ni Hui and X2 models to test?

Thanks!

hexfet wrote: Please give this a try. Hopefully it will at least bind. I hard-coded the checksum for the bind packets since they're all the same.

The SymaX protocol in this build is for the X11. I added the Ni Hui and SymaX2 protocol options to the YD717 protocol. Models using the current SymaX protocol should be changed to YD717 with the SymaX2 option. Do you have Ni Hui and X2 models to test?

Thanks!

Ok I will try .... I have only the Ni Hui to test (my smallest nano FPV in the world )

Ok...

So it's not working with Syma X11 .... but the option in YD717 is working for the Nu Hui...

For the Syma X11, leds are flashing twice slower but not becoming solid ...

The LED changes behavior when you try to bind? That's progress

It could be the crc. Could you try the attached version? It has a hard-coded data packet extracted from the trace so it should be valid. If it binds you won't have any control, but it will show the only issue is the crc. If it still doesn't bind it's some other issue.

hexfet wrote: The LED changes behavior when you try to bind? That's progress

It could be the crc. Could you try the attached version? It has a hard-coded data packet extracted from the trace so it should be valid. If it binds you won't have any control, but it will show the only issue is the crc. If it still doesn't bind it's some other issue.

No it's doesn't work too ... In fact led are flashing slowly automatically after few seconds ....

Fixed a bug that was sending bind packets with the wrong address.

The zip with TEST in the filename has the fixed packet data with the correct checksum. The other version is normal.

hexfet wrote: Fixed a bug that was sending bind packets with the wrong address.

The zip with TEST in the filename has the fixed packet data with the correct checksum. The other version is normal.

Good news !!!!! It's binding (I tried directly the normal version)...
Ok I think nominal low values and max values are not good....
Well when I push throttle above 50%, the quad starts take off at full speed.... I will see first what I can do with the radio programming. I have to check if other commands are working but basically it's on the right track

I performed two new capture

1) With full throttle (I removed props)
2) Playing with ruddler trim button


mon-partage.fr/f/VlyXVdaN/

Awesome! The throttle should be sorted in the attached. Other channels may still need attention.

For the trim capture did you increase to one endpoint, then back to center? Or was it from one endpoint all the way to the other end?

There should be flip control on channel 5, and rates on channel 6.

Apparently the receiver ignores the crc I have been looking at it but haven't made much progress. The reveng tool reports "no models found". A list of all the data packets captured so far is attached in case anyone is interested in a puzzle. The checksum is the last byte in the row.

The good news is the checksum does not depend on anything other than the data. I think a table lookup solution will work. Probably worth the effort in case a different model does check the sum.

To create the table more data is needed. Currently we have 224 of the 256 possible sums. Please make a capture that's as long as possible and moves the sticks all around to vary the data.

That and data on the cyclic trims should get us very close!

hexfet wrote: Awesome! The throttle should be sorted in the attached. Other channels may still need attention.

For the trim capture did you increase to one endpoint, then back to center? Or was it from one endpoint all the way to the other end?

There should be flip control on channel 5, and rates on channel 6.

Apparently the receiver ignores the crc I have been looking at it but haven't made much progress. The reveng tool reports "no models found". A list of all the data packets captured so far is attached in case anyone is interested in a puzzle. The checksum is the last byte in the row.

The good news is the checksum does not depend on anything other than the data. I think a table lookup solution will work. Probably worth the effort in case a different model does check the sum.

To create the table more data is needed. Currently we have 224 of the 256 possible sums. Please make a capture that's as long as possible and moves the sticks all around to vary the data.

That and data on the cyclic trims should get us very close!

1) yes I increased to end-point (well to high value point since don't have a lot of time to do everthing within 25s) and decreased


Ok I will do more longer capture. Do I need to move sticks to increase probability to collect all the 256 combinaisons ?

I will test now your new version

Well with this new version the throttle is not solved... In fact, I am starting throttle (almost at full speed) by player with the AIL... seems that it's not a AETR but maybe more a TRAE, well you see what I mean

The last left stick up/down capture shows only the first data packet byte changing with left stick up/down. I've checked the emulator and things seem correct just using the default model (simple mixers AETR). The first data byte changes according to left_v, and has no interaction with any of the other stick inputs.

Any chance the model is doing some mixing? The only ch3 output should be from thr source.

If not then I'm confused...

hexfet wrote: The last left stick up/down capture shows only the first data packet byte changing with left stick up/down. I've checked the emulator and things seem correct just using the default model (simple mixers AETR). The first data byte changes according to left_v, and has no interaction with any of the other stick inputs.

Any chance the model is doing some mixing? The only ch3 output should be from thr source.

If not then I'm confused...

Not improvement for the throttle ....
I am uploading a video .... I checked mixer ... each channel are completly independent...

A video



Throttle starting when it's at 100%... but not always and stop at 0% but not always ... maybe some CRC ... not validated the quad don't take into account commands ... I don't know