Flysky AFHDS 2A, protocol as used i10, i6, iT4,

That's normal, this is 3-wire SPI, Master In (MISO) and Master Out (MOSI) share the same pin (SDIO)

Bad captures

Please retry with higher sample rate and/or shorter wires.

Higher sample rate only should be fine.

This is why you need to sample at least at twice the speed of the clock signal:
en.wikipedia.org/wiki/Nyquist%E2%80%93Shannon_sampling_theorem

Looks fine, thanks !

As I said I do not have much time to look at that for now, but that will help, for sure

Also, if someone else wanna have a look, here's my A7105 decoder python script (based on victzh's nrf24l01 decoder), it's working fine with dc59's .csv files:
gist.github.com/goebish/e6a486a87fba5a233c56

It doesn't look very complex, I think the hardest part will be to figure out the channel hopping sequence for arbitrary txid/rxid (as usual ).

edit: I think I figured it already, channels list is sent with bind packets, seems it has nothing to do with txid/rxid (well, hopefully, or I don't see the point to send them along, also I've looked at a ROM / EEPROM dump and I can see the channel list is stored there, next to txid, so there's a good chance it is semi random, not computed from txid, but I need to make tests with an actual RX to confirm that... but perhaps I'm wrong and it relies on a tx_channels table as older AFHDS , oh well, worst case I'll have to fire up the jtag probe, openocd and IDA and trace the sequence generation, this is a good opportunity to learn new tricks ...).

this is a bind packet:
150 W_REGISTER(05_FIFO_DATA) BB 44 2A 37 77 FF FF FF FF 01 00 2B 62 1D 50 0F 41 3C 92 71 6C 32 79 58 7F 86 8B FF FF FF FF FF FF FF FF FF FF 00

and channels hopping sequence for data packets is:
2B 62 1D 50 0F 41 3C 92 71 6C 32 79 58 7F 86 8B

TXID is 44 2A 37 77, the 4 following FF are RXID, which is received from the RX later.
(from the 3 differents captures I've seen, txid 3rd byte is 36 or 37, and 4th byte is always 77)

Looks like data packets don't have a checksum or CRC, just
packet type ? (0x58) | txid | rxid | channels data (1000-2000, 16 bit, little endian) | 00

Telemetry packets should be easy to figure out as well:
5223 R_REGISTER(05_FIFO_DATA) AA 44 2A 37 77 25 31 91 41 00 00 F3 01 FE 00 00 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

0x01F3 = 499, seems this is your RX voltage (4.99V)

They can bind to older RXs, but AFHDS 2A is a new protocol, looks like TXID doesn't match with former table (row + chan offset).
Also, bind is bi-directional, RX sends its ID.

Yes, I know this protocol well, but looks like it doesn't match, here are the TXID / channels data I collected:
Take the first one:
0x5a893677 % 16 = 7 (8th line of the table)
0x77 / 16 = 7

first value of line 8th line in the table is 0x64
0x64 - 7 != 0x1d

Also, last byte of txid seems to always be 0x77, so channel offset would always be 7, which is unlikely.

Note that I only had a quick look, maybe I got something wrong