SYMA X5C-1, X11, X12

Yes, perhaps the quad is only accepting the data packet when the checksum happens to match the fixed value I'm sending for the crc. I'll implement the table lookup with the data we have so far and see if that makes a difference.

It would be good to get more capture data, moving the sticks around to generate different data and hopefully the missing checksums.

This version gets the checksum right about 90% of the time. See if this makes a difference. Might make for interesting behavior - be careful my friend!

hexfet wrote: This version gets the checksum right about 90% of the time. See if this makes a difference. Might make for interesting behavior - be careful my friend!

It's better, it's more responding on the throttle stick (without being perfect). So I will collect maximum of date for this CRC checking....

2 long files of captures....

mon-partage.fr/f/mLzjrLFu/

Sorry but some during capture, the MISO wire was disconnected partially (due stick movements).... I hope you will be able to find something inside

Good news and bad news. The good part is the captures are fine - plenty of data to analyze with a good bit of variation in the data. The miso data is not used by the protocol so that's not an issue.

The bad news is the table lookup will not work. There are now multiple valid checksums corresponding to the same simple sum of the data. Just didn't have enough data before to see the collisions.

The reveng tool doesn't find a crc even with the additional data. I've spent some time staring at the data but don't have experience or math chops to do a real analysis. Since reveng doesn't find it probably it's not a standard crc.

Some of the packet bytes are staying at fixed values. These are probably the other trim bytes. It may be helpful to get those captures as well to see how those bytes affect the checksum.

The attached file contains the 8532 unique data packets captured so far. The last byte on the line is the checksum. Ideas welcome...

All the data bytes xor'd together plus 0x55 gives the correct checksum in all but one case in the test data.

Please give this version a try...

hexfet wrote: All the data bytes xor'd together plus 0x55 gives the correct checksum in all but one case in the test data.

Please give this version a try...

Yes it's working better now ... I mean now it's reacting well on throttle but It seems to have a kind of binary respond throttle off or throttle 100%

Ok, it's ammost flying but the aileron is actionnating flipping check if flips are not activated by default (I will check also my devo config)
I will upload a small video ...

Ok the video



Notice than all my channels are min limit = -150, max limit = 150, scale - = 100, scale + = 100, subtrim = 0.0

The videos are very helpful. And fun to watch...poor copter!

Can you try adding mixers for channels 5 and 6 and see what effect they have? If sending greater than zero on channel 5 stops the flipping then the default is backwards.

I'll check the code too. The yaw trim is in the same data packet byte as the flip bit - may be a bug there.

hexfet wrote: The videos are very helpful. And fun to watch...poor copter!

Can you try adding mixers for channels 5 and 6 and see what effect they have? If sending greater than zero on channel 5 stops the flipping then the default is backwards.

I'll check the code too. The yaw trim is in the same data packet byte as the flip bit - may be a bug there.

Well I assigned CH5 & 6 on a 2 states switch.... a no directly impact on the auto flips. It seems that :

Flips are occuring more when: I have high positives values (right stick on right or forward, left stick on right even if for the yaw, I didn't observe flip but strange erradic behaviour.

If I am flying with stick very close to central zone is more stable except but yaw right turn, right shafting and forward are slower compared to opposed movements ....

I hope I am clear

Went back to the captures and think I found a mistake in the data encoding I was using. See how the channel controls work in this version.

I removed the code to drive the trims so yaw rate may be less but there should be no unexpected flipping. Once we get the channels working well we can come back to the trims.

hexfet wrote: Went back to the captures and think I found a mistake in the data encoding I was using. See how the channel controls work in this version.

I removed the code to drive the trims so yaw rate may be less but there should be no unexpected flipping. Once we get the channels working well we can come back to the trims.

It's working great ))) Slow but perfect ... You are definitively on the right track now

Excellent! If you can get a capture of the roll and pitch trims it should be all we need (hopefully . Best would be to go from center to one endpoint, then all the way to the other endpoint, then back to center.

Do the rate and flip channels have any effect now?

hexfet wrote: Excellent! If you can get a capture of the roll and pitch trims it should be all we need (hopefully . Best would be to go from center to one endpoint, then all the way to the other endpoint, then back to center.

Do the rate and flip channels have any effect now?

1) Here is a snapshot video



2) here is some log with trimmings and max deviation in expert modes

mon-partage.fr/f/yJJEx69G/

3) I didn't try the flip button I will now

Whaoo ....

I activated dual rate on CH5 working great
and (continuous) flipping is also working in CH6

So now just integreate trim and it's working at 100%

Bravo bravo

Nice flying I like the lights on this quad.

The flip control is supposed to be channel 5 to match the yd717. So flip and rate control channels need to be swapped?

I'll look at the captures...

hexfet wrote: Nice flying I like the lights on this quad.

The flip control is supposed to be channel 5 to match the yd717. So flip and rate control channels need to be swapped?

I'll look at the captures...

No it's ok for CH5 and CH6, sorry was my swich assignation which make me wrong ....
A actually, it's CH5 = flipping and CH6 dual rate...

No problem Give this version a try. Getting close...

hexfet wrote: No problem Give this version a try. Getting close...

It's perfect now yaw, pitch and rolls rates are like the orignal

Can you send to me the YD717.c and this new file too ? I will recompile for my devo coz I modified some stuff for the FrSky protocol