Devo.txt

A 16 byte data packet is sent every 2.4msec
If telemetry is disabled, register 0x04 is checked 1.2msec after transmit to verify transmit status and ACK from Rx
If telemetry is enabled, register 0x04 is polled starting 0.9msec after transmit to verify transmission complete.
    Polling is repeated every ~11 usec.

The 1st byte of the data packet indicates the packet type.
The upper nibble indicates the number of channels:
2402D : 0x60 (Note that this is a 4 channel transmitter, so it is 'weird'.
              Also, it does not send 0x67 or 0x6c packets)
Devo6 : 0x60
Devo7 : 0x70
Devo8 : 0x80
Devo10: 0xa0
Devo12: 0xc0

The packet types are as follows:
0x85 -
       This appears to be used to transmit model data between transmitters
0x87 -
       Sent every 10 packets
       This packet contains the fail-safe info for the 1st 8 data-channels
       bytes 1-8 represent a signed 8-bit value -125 to 125 for each of the 1st
       8 channels byte 9 is a bit-field indicating for which channels failsafe
       is enabled (bit 8 represents channel 1, bit 0 channel 8).   Bytes 10 - 15
       are the same as for packets 0x8b and 0x8c
0x88 -
       This packet is never sent for <=8 channel transmitters
       For 10ch and 12ch transmitters it is sent (as 0xa8 or 0xc8) alternating
       with 0x87 to provide failsafe info for the upper 8 channels
0x8a -
       Only sent for the 1st 10sec or so.
       bytes 1 and 2  are a LSB-first word indicating the number of packets
       left before we stop sending 0x8a packets bytes 3, 4, 5 are the transmit
       channels that will be used to transmit data in a round-robin
       configuration bytes 6-9 contain the cyrf6936 ID.  This is used as an XOR
       for 0x87, 0x8b, and 0x8c packets
       bytes 10-12 are the same as for the 8b/8c packets (but are not scrambled)
       bytes 13-15 are the Fixed ID (though it isn't actually enabled) and ARE
       scrambled with the least-significant 3 bytes of th cyrf6936 ID
       This packet is sent before every 0x8b or 0x8c packet for the 1st 10 seconds)
       If FixedID is in use, 0x8a is never sent, and 0x87 is sent instead
0x8b -
0x8c -
       0x8b and 0x8c packets are alternating packets.  These are the channel
       data each packet contains 4 16bit values (bytes 1 - 8) which are LSB 1st
       The sticks return '0' when centered and seem to max out at 0x640 at
       either end the upper-nibble of byte 9 indicates whether the channel value
       is positive/or negative I.e at the end of stick travel the value is 0x640
       and bit 9.x indicates which end the stick is at

Packets 0x87, 0x8a, and 0x8b are 'encrypted' by xoring with the cyrf6936 id.
       This is a 4 byte value.
       xoring is done by xoring all but the 1st byte of the  packet (i.e.
       everything but the cmd byte) with the id.  i.e.
       pkt[1..4] ^ id,
       pkt[5-8] ^ id,
       pkt[9-12] ^ id,
       pkt[13-15] ^ (least significant 3 bytes of id)

The transmit channel is changed every 4 packets.  It appears to cycle between 3
        values, 4 channels apart.  For instance:
       0x04, 0x08, 0x0c, 0x04, 0x08, 0x0c, ...

Packet 0x8b
0x8b:  aaaa bbbb cccc dddd ee ff gg hh iiiiii
    aaaa: Elevator 9.7 is set when stick is below center
    bbbb: Aileron  9.6 is set when stick is right of center
    cccc: Throttle 9.5 is set when stick is below center
    dddd: Rudder   9.4 is set when stick is right of center
    ee: The upper nibble of byte 9 corresponds to whether the current stick value is positive or negative
        The lower nibble is '0x0b' (except for the 2402D which is '0x09')
    ff: The upper nibble is one of '0x00', '0x80', '0xc0'
        The lower nibble is the number of packets that will be transmitted (after this one) before the next
        transmitter channel is selected
        The upper nibble 0x00 corresponds to non-fixed-id, and 0x80 corresponds to using a fixed-id
        An upper nibble of 0xc0 is used to indicate fixed-id binding is in progress
    gg: The next transmitter channel that will be selected
    hh: The transmitter channel that will be selected after the next one (2 away)
    iiiiii: The Fixed ID value (LSB 1st, 24bit value)

Packet 0x87
0x87:  aa bb cc dd ee ff gg hh ii jj kk ll mmmmmm
    aa: Elevator -125 to 125
    bb: Aileron  -125 to 125
    cc: Throttle -125 to 125
    dd: Rudder   -125 to 125
    ee: Ch 5     -125 to 125
    ff: Ch 6     -125 to 125
    gg: Ch 7     -125 to 125
    hh: Ch 8     -125 to 125
    ii: Failsafe on/off bit.  MSB=ele, LSB = Ch8
    j, k, l, m match f, g, h, i from 0x8b above

Telemetry
    23usec after the Tx packet is ACKed, a telemetry query starts
    It consists of configuring the GPIO for Rx
    60usec after GPIOs are configured, the IRQ_RX_STATUS_ADDR (0x07) is polled for incoming data
    Polling continues until it is time to send the next data packet at which point the GPIO is reconfigured for Tx

    If Register 0x07 sets bit 5 (RXB16) indicating a 16byte packet has been received, the packet is fetched.  Next the
    RX_STATUS_ADDR is checked for completion, and the CYRF state is reset for receive by sending 0x87 to Register 05

    The telemetry packet is as follows:

    Telemetry data is transmitted as 2 16 byte packets
    Packets are sent every 2.4msec.  They are processed between data packets (apparently after the ACK is checked)

    The 1st byte of the packet is either 0x30 or 0x31
    All bytes except for the 1st are scrambled with the Transmitter MfgId as per the Tx packets
    Like the Tx packets, each telemetry packet appears to contain 4 16bit LCB-1st channels

Given the the only available telemetry module at the moment is the ladybird, which only reports voltage,
most of the telemetry data is still unknown
Packet 0x30
  30   0000 2800 0000 0000 00 00 f4 01 284209
0x30:  aaaa bbbb cccc ???? ?? ?? gg ?? iiiiii
    aaaa: Voltage1 measured in 1/10 of a volt (3.5v will be 35 or 0x0028) (guess)
    bbbb: Voltage2 measured in 1/10 of a volt (output of ladybird confirmed)
    aaaa: Voltage3 measured in 1/10 of a volt (3.5v will be 35 or 0x0028) (guess)
      gg: LSB represents which channels are active  Value=4 indicates Voltage2 (guess)
    iiiiii: The Fixed ID value as per the 8b/8c packets

Packet 0x31
  31   ffff ffff 0000 0000 0000 0000 284209
0x31:  ???? ???? ???? ???? ???? ???? iiiiii

    The GPIO setting to change from Tx to Rx are as follows:
    Register      Value
     0x0E          0x20
     0x0F          0x28
     0x05          0x87  : Put CYRF6936 into Rx mode

    The GPIO setting to change from Rx to Tx are as follows:
    Register      Value
     0x0E          0x80
     0x0F          0x2C

Initialization:
The Devo initially sets the CRC value and SOP table to 0x00 during binding.
Once binding is complete the CRC and SOP seem to be changed based on the MfgID
the SOP can have values 0-9 (a pointer to one of the 10 PN strings)
the CRC can have values 0x01 to 0xFF (0x00 is reserved for bind mode)

Known values:
MFGID:               SOP      CRC
f8 a4 79 00         0x03     0x73
70 38 73 4b         0x07     0xE3

The SOP table is the Cypress recommended one.  See:
WirelessUSB LP/LPstar and PRoC LP/LPstar Technical Reference Manual
http://www.cypress.com/?docID=30520
0x91CCF8E291CC373C
0x0FA239AD0FA1C59B
0x2AB18FD22AB064EF
0x507C26DD507CCD66
0x44F616AD44F6E15C
0x46AE31B646AECC5A
0x3CDC829E3CDC78A1
0x7418656F74198EB9
0x49C1DF6249C0B1DF
0x72141A7F7214E597

It appears that Walkera calculates the SOP and CRC as per:
Cypress AN6066: Wireless Binding Methodologies
http://www.cypress.com/?docID=31871

SOP: ((MfgID[0] << 2) + MfgID[1] + MfgID[2]) % 10
CRC: (MfgID[0] + (MfgID[1] >> 6) + MfgID[2]) & 0xff (this value is repeated in the upper and lower byte)