DSM2 Reports

PB, if I comment two lines at dsm2.c, 8-channel and 9-channel mode working just fine. All channels working!!!

static void build_data_packet(u8 upper)
{
u8 i;
const u8 *chmap = ch_map[num_channels - 4];
// if(upper)
// chmap += 7;
#if DSMX
packet[0] = cyrfmfg_id[2];
packet[1] = cyrfmfg_id[3] + model;
#else

Thanks!

Seems JR 12X has next sequence of channels:

JR12X - R1221

1 frame - 1, 4, 10, 2, 3, 7, ff
2 frame - 8, 9, 12, 6, 5, 11, ff

Ooops. Some messages are lost. But anyway, next test with 11 bit mode only - 6/7 channels:

1. Spektrum AR6210, 6 channels mode - doesn't work, all messed.
2. Spektrum AR6210, 7 channels mode - doesn't work, all messed.

3. JR R921, 6 channels mode - doesn't work, nothing at all.
4. JR R921, 7 channels mode - doesn't work, nothing at all.
5. JR R921, 8 channels mode = OK, all channels work fine.
6. JR R921, 9 channels mode = OK, all channels work fine.

As I expected, DSM2 at <8 channels have to work with 10 bit.

Maybe High Speed DSM2 receivers (7 channel) can work with 11 bit mode? AR7600, AR7610.

2048 Resolution
High-speed 11ms frame rate (when paired with DX7se)

Interesting result:

If at 'dsm2.c' I extend/double ch_map tables for 6 and 7 channels:
Set Tx capability byte always = 0x12:
Set bits always 11:
Comment one frame transmittion and enable always two frames transmittion (11ms):
I can get next results:

1. Spektrum AR6210, 6 channels mode - doesn't work, all messed.
2. Spektrum AR6210, 7 channels mode - doesn't work, all messed.

Seems that AR6210 ignore high bit of data and servo do full travel twice for 1 full travel of Tx channel (throttle with 150% scale). Channels with 100% scale (or centered?) don't work at all.

3. JR R921, 6 channels mode = OK, all 6 channels work fine.
4. JR R921, 7 channels mode = OK, all 7 channels work fine.

I think, at interchange between Tx and Rx, the most significant byte is capabilities byte, not number of channels.

DSM2:
0x01 = 1 frame, 10 bit, <= 7 channels, 22ms, DSM2
0x02 = 2 frames, 10 bit, > 7 channels, 22ms, DSM2
0x12 = 2 frames, 11 bit, > 7 channels, 22ms, DSM2
0x12 = 2 frames, 11 bit, >= 7 channels, 11ms, High Speed DSM2)

DSMX:
0xA2 = 1 frame, 10/11 bit, <= 7 channels, 22ms, DSMX
0xB2 = 2 frames, 10/11 bit, > 7 channels, 22ms, DSMX
0xB2 = 2 frames, 10/11 bit, >= 7 channels, 11ms, High Speed DSMX)

Which interchange?
There are 2 bytes:
11) # of channels
12) capabilities

I think I'm misunderstanding what you are saying.

The Tx sends info on what format it wants to transmit
The Rx sends back a subset of that corresponding to what it supports.

So you should never see a transmitter send '6 channel, 22ms' and get back '9ch 11ms' (I think)

Unfortunately I don't really know what Rx return on each possible Tx request (# of channels and capabilities). But for example, AR8000 always send back 7 channels and really support 8 channels. I just wanted to say that the number of channels is not a reliable parameter.

With what kind of tx?
If the tx asked for 7 channels, the rx will respond 7 channels...

FDR wrote: With what kind of tx?
If the tx asked for 7 channels, the rx will respond 7 channels...

I thinks one probelm is that Spektrum didn't really think out their original protocol spec, and tried to extend it as new capabilities were needed. So some Rx may not send back anything, some won't understand newer capabilities, etc. So I don't think there is a clear definition, but more a bunch of corner cases that need to be understood to provide complete support.

I have just updated the code so that channels are calculated via interrupt. If I got everything right, it should give a much smoother response, but it definitely needs testing. The changes also dramatically change how the emulator works. This was the last big change I am planning before the release. At this point I'm planning to start working on documentation. If there are any issues/changes/fixes that do not have an open report on bitbucket, this is a good time to add them. Do not assume that because it is discussed in a thread here that I've remembered about it.

I've found several dumps and channels order is not always the same as at dsm2.c:

The DX7 has:

Aileron
Flaps (Pitch)
Gear
Elevator
Aux2
Throttle
Rudder

For example a centre stick packet from a DX7 is (HEX values):

(0301) 0601 1600 10AA 0A00 18AB 015F 0DFC

#ch 0001 0101 0100 0010 0110 0000 0011

(0x01) 1 5 4 2 6 0 3
=======================================

The DX6i has a different channel order:

Aileron
Flaps (Pitch)
Elevator
Rudder
Throttle
Gear
Aux2 = fixed value

(0301) 05FF 1765 09FF 0DFF 01FB 1365 1800=fixed value '0'

#ch 0001 0101 0010 0011 0000 0100 0110

(0x01) 1 5 2 3 0 4 6-have to be 0xff???
=======================================

The DX8 has:
(02EE) 0BF8 2EAA 13F0 1C1B 3156 FFFF FFFF
#ch 0001 0101 0010 0011 0110 ffff ffff

(02EE) A156 0156 3EAA FFFF FFFF FFFF FFFF
#ch 0100 0000 0111 ffff ffff ffff ffff

(0x12) 1 5 2 3 6 ff ff
(0x12) 4 0 7 ff ff ff ff
=======================================

Will be interesting to check DX7 channels order (1, 5, 4, 2, 6, 0, 3) with Tarot ZYX-S at 7-channel mode.

You need turn on the Tx, set throttle scale 100%, set the throttle stick in the highest position, plug the flight battery in. After the beep, set the throttle stick in the minimum position, unplug the flight battery and turn off the Tx.

This way you recalibrate ESC at your Ultra Micro.

If it doesn't help, try to rebind your Ultra Micro.