18 channels for DSM2 / DSMX ?

OK, it is possible that transmitted only active xchannels. But, if is active only one xchannel, what is transmitted with second packet of the frame?

It is how it implemented by PB, only DSM2 10bit and DSMX 11 bit. It works at many cases. For full support Tx need read and interpret Rx capability responce.

"Here's a little more detail about the format of the transmitted bind packets in DSM2/X

Packet sent from TX

Bytes 1 - 4 GUID of the radio
Bytes 5 - 8 = copy of bytes 1 - 4
Bytes 9 and 10 = checksum of bytes 1-8 (add bytes 1 thru 8 together and then add 0x170.
Byte 11 always equals 1 in every Spektrum radio I've seen - don't know its function
Byte 12 = number of transmitter channels
Byte 13 = capabilities of the transmitter

DSM2 transmitter = 0x01 or 0x02 (I think it is the number of packet pairs needed for a complete frame 7CH TX = 0x01, 8+ CH = 0x02)
High speed DSM2 = 0x11 or 0x12
DSMX 7 channel TX = 0xA2 (DSMX and 11 bit resolution)
DSMX 8+ channel TX that supports high speed = 0xB2

Byte 14 always 0x00
Bytes 15 & 16 = another checksum created by adding bytes 9 - 14 together with the checksum at bytes 9 & 10

================================================================

The receivers always respond with a 10 byte packet that has the format:

Bytes 1 - 4 = GUID of the TX
Bytes 5 = always 1
Byte 6 number of channels of the receiver (can't always be relied on; my AR8000 always says 7)
Byte 7 = capabilities of the receiver in the same format as Byte 13 above
Byte 8 = always zero
Bytes 9 & 10 = checksum"

Cesco, I don't understand about xchannel number.

The D bit is always 0. It have sense, since it have to be 0 for 1st data packet, 1 for 1st channel in 2nd data packet.
If it is the first packet of frame, 0-3 xchannel number equal 0-3 xchannel number.
If it is the second packet of frame, 0-3 xchannel number equal 4-7 xchannel number (+4).

Is it right?

Cesco wrote: If channel 0 is in the same packet add 4, if channel 1 is in the same packet add 0.

Channel transfer structure:
packet 1 -> 1 5 2 4 6 10 12
packet 2 -> 0 7 3 8 9 11 12

vlad_vy wrote: The D bit is always 0. It have sense, since it have to be 0 for 1st data packet, 1 for 1st channel in 2nd data packet.
If it is the first packet of frame, 0-3 xchannel number equal 0-3 xchannel number.
If it is the second packet of frame, 0-3 xchannel number equal 4-7 xchannel number (+4).

I think it's right.

Order of channels in packets may be variable. I don't check it, but I think it may depends from Tx model type: ACRO, HELI, SAIL. This way Tx group channels for main controls, for HELI ch2, ch3, and ch6 placed in the same packet for minimal delays.

Cesco, I'm not sure it will work. I can't test X-Plus by any way. It's for testing purposes only. DSM2 2048 22ms for >7 channels (DSM2 <8 channels will not work). DSMX 2048 22ms. Total 20 output channels, 12 normal channels + 8 X-Plus channels. Unused X-Plus channels have 256 value.

Firmware for Devo12, based on last v3.1.0-beta-03 rbe2012 build.

DELETED

It can be that my code have errors. It possible since you tested it with DX18 and all works.

I will check my code again. Also, we need to know what is transmitted in case unused X-Plus channel. For example, if enabled X-Plus 1 only, what is transmitted with the second packet. Possible it can be 0xFFFF.

Possible I catch my error. Since you can test it with DSMX protocol, I implemented X-Plus channels parsing for DSMX protocol only and do not mess DSM2 protocol.

Total 20 output channels, 12 normal channels + 8 X-Plus channels. Unused X-Plus channels have 256 value.

Firmware for Devo12, based on last v3.1.0-beta-04 rbe2012 build

DELETED

Now I send x-channels with next sequence (not optimal, but easy to undestand):
ch13 = x1 (22ms)
ch14 = x2 (44ms)
ch15 = x3 (66ms)
ch16 = x4 (88ms)
ch17 = x5 (88ms)
ch18 = x6 (88ms)
ch19 = x7 (88ms)
ch20 = x8 (88ms)

I can reorder x-channels for better arrangement in packets:
ch13 = x1 (22ms)
ch14 = x5 (22ms)
ch15 = x2 (44ms)
ch16 = x6 (44ms)
ch17 = x3 (66ms)
ch18 = x7 (66ms)
ch19 = x4 (88ms)
ch20 = x8 (88ms)

Delays listed in order adding number of channels, 13 or 14 or 15 ...

Cesco, can you test next firmware version, with disabled (probably) unused X-Plus channels?

If you will add number of channels, 13 or 14 or 15 ..., you have to get 1 or 2 or 3 ... x-channels. I hope it will be like this.


DELETED

The choice between 1024 / 2048 for dsm2 will be with future releases, after 3.10, since we decided do not implement any new features with v3.10, only fixes.

Cesco, can you test next firmware version, with disabled unused X-Plus channels and more optimal x-channels arrangement?

Now you have tested:
ch13 = x1 (22ms)
ch14 = x2 (44ms)
ch15 = x3 (66ms)
ch16 = x4 (88ms)
ch17 = x5 (88ms)
ch18 = x6 (88ms)
ch19 = x7 (88ms)
ch20 = x8 (88ms)

Next firmware have x-channels arrangement:
ch13 = x1 (22ms)
ch14 = x5 (22ms)
ch15 = x2 (44ms)
ch16 = x6 (44ms)
ch17 = x3 (66ms)
ch18 = x7 (66ms)
ch19 = x4 (88ms)
ch20 = x8 (88ms)

If you can test/compare delays with both versions, it will be nice.

SORRY, I FOUND ERROR IN CODE. FIRMWARE DELETED.

P.S. I'm not sure, but probably for new channel number to become active will be enough press 'Bind' button.

P.S. Since you got positive result with unused X-Plus channels, I can say that unused X-Plus channel has data format 0xFFFF, the same as unused normal channels.