FlySky (1-way) new protocol variant

goebish wrote: I'll have a look into that.

Problem is that the flysky protocol is already using 8 channels when wltoy "extension" is enabled, that means we would need 16 channels to control everything ?

goebish wrote: So,

WLToys v686

a7105 3 wire spi

packet size: 21 bytes

packet format:
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 
aa bb cc dd ee ff gg hh ii jj kk ll mm nn oo pp qq rr ss tt uu

aa: 
    packet type, 0xAA = bind, 0x55 = data
bb cc dd ee: 
    tx id ? 0xCE543102
ff gg: 
    channel data, 1000-2000 LSByte first ? DC05 = 05DC = 1500
hh ii: 
    channel data, 1000-2000 LSByte first ?
jj kk: 
    throttle channel data, 1000-2000 LSByte first ?
ll mm: 
    channel data, 1000-2000 LSByte first ?
nn: 
    bit 8 (0x80): HIGH for headless mode
    bit 7 (0x40): 0
    bit 6 (0x20): 0
    bit 5 (0x10): 0
    bit 4 (0x08): 0
    bit 3 (0x04): 0
    bit 2 (0x02): 0
    bit 1 (0x01): 0
oo:
    bit 8 (0x80): HIGH = flip button is pushed ?
    bit 7 (0x40): HIGH = Light on ?
    bit 6 (0x20): HIGH = headless mode button is pushed ? toggles nn.8 
    bit 5 (0x10): HIGH = take picture button is pushed ?
    bit 4 (0x08): HIGH = headless_mode_two button ? ("RTH"?)
    bit 3 (0x04): 0
    bit 2 (0x02): 0
    bit 1 (0x01): HIGH = camera record on ?
 
pp: 0x10
qq: 0x10
rr: 0xAA
ss: 0xAA
tt: always changing, not a checksum because it changes even if other bytes don't
uu: 0x02

quad_on_TX_on_photo_on_photo_off_several_times.logicdata tx packets:
gist.github.com/goebish/15b8f73bd0b4fbffc0bc

This is the first time I'm having a look at a "FlySky" protocol, and there's something weird when i compare this to deviation code, channels data are not encoded the same way, in the v686 capture we have a simple 1500 = 05DC = DC05 for neutral, but in deviation flysky code I see:

s32 value = (s32)Channels[i] * 0x1f1 / CHAN_MAX_VALUE + 0x5d9;
if (value < 0)
    value = 0;
packet[5 + i*2] = value & 0xff;
packet[6 + i*2] = (value >> 8) & 0xff;

(or maybe I'm wrong and this code just converts the deviation value to 1500 neutral, I haven't touched deviation code for a while )

I still haven't really looked at bind procedure and channel hopping sequence, but are you sure an older TX is compatible with this model ?

goebish wrote: Ok, I'll build a test firmware with a WLToys v6x6 option setting.

For which TX should I build it ?

goebish wrote: I need to know a few more things:

Are headless mode, headless mode 2 (?), take picture and flip some momentary buttons ?

Oh, and we will need 10 channels to control everything ...

goebish wrote: Ok, what is the "quad_on_TX_on_light_headless_mode_twol_times.logicdata" capture file, is it RTH ?

goebish wrote: You can checkout this branch:
bitbucket.org/goebish/deviation/branch/WLToys%20V6x6

or just this patch:
bitbucket.org/goebish/deviation/commits/...534d7e0e6b9e95ad8d22

There's a new option in FlySky protocol settings screen:

WLToys ext. : Off / V9x9 / V6x6

When V6x6 is enabled:

Channel 5: Lights
Channel 6: flip button
Channel 7: take picture button
Channel 8: record video
Channel 9: headless mode
Channel 10: RTH

I'm not sure headless & RTH does work, please report

mwm wrote: Channels 5-8 in the older flysky protocol aren't used by the Rx. They are used in the Tx to cause bits to toggle in the lower four channels.

We've looked into this for v912/915 support, which uses some of the older channels, and some new stuff as well. One thing that might be useful is that I did a build that let you set values in channels 5-10 that set the WLToys bits in channels 1-6. I don't believe we ever got confirmation about what was and wasn't working.

If the v686 uses normal values on channels 5-8, then it won't be compatible with the old WLToys options. Adding a "WLToys2" option may be required.