FYI, if there are specific captures you think will be interesting, let me know, and I'll grab them when I get a chance.

Cool. I wrote a register decoder for the CYRF69103 chip.
Here is the data I capture on the SPI, with the decoder annotation.
Annotation are in the bracket, pretty self explain.
I can confirm that using ER9x with DX4e in the "DSM2/DSMX mode"
is indeed binding to my 130x receiver chip in the DSMX mode.
I can see the channel jumping more than 2 channel.

Here are some trace after the binding process:

 20558 WRITE A9 [RX_ABORT]  00
 20558 WRITE D5 [CRC_SEED_LSB]  EF [CRC_SEED_LSB:ef]  E3
 20558 WRITE A2 [SOP_CODE]  C0
 20558 WRITE A2 [SOP_CODE]  90
 20558 WRITE A2 [SOP_CODE]  8F
 20558 WRITE A2 [SOP_CODE]  BB
 20558 WRITE A2 [SOP_CODE]  7C
 20558 WRITE A2 [SOP_CODE]  8E
 20558 WRITE A2 [SOP_CODE]  2B
 20559 WRITE A2 [SOP_CODE]  8E
 20559 WRITE A3 [DATA_CODE]  35
 20559 WRITE A3 [DATA_CODE]  D1
 20559 WRITE A3 [DATA_CODE]  FC
 20559 WRITE A3 [DATA_CODE]  97
 20559 WRITE A3 [DATA_CODE]  23
 20559 WRITE A3 [DATA_CODE]  D4
 20559 WRITE A3 [DATA_CODE]  C9
 20559 WRITE A3 [DATA_CODE]  88
 20559 WRITE A3 [DATA_CODE]  E1
 20559 WRITE A3 [DATA_CODE]  D6
 20559 WRITE A3 [DATA_CODE]  31
 20559 WRITE A3 [DATA_CODE]  26
 20559 WRITE A3 [DATA_CODE]  5F
 20559 WRITE A3 [DATA_CODE]  BD
 20559 WRITE A3 [DATA_CODE]  40
 20559 WRITE A3 [DATA_CODE]  93
 20559 WRITE 80 [CHANNEL]  32 [Channel:32]
 20561 WRITE 85 [RX_CTRL]  83 [RX_GO RXC_IRQEN RXE_IRQEN]
 20561 READ  07 [RX_IRQ_STATUS]  7A [SOPDET_IRQ RXB16_IRQ RXB8_IRQ RXB1_IRQ RXC_IRQ]  7A
 20561 READ  09 [RX_COUNT]  10 [RX_Count:10]
 20561 READ  21 [RX_BUFFER]  34  FE  0C  02  2C  50  13  FE  24  00  1B  FC  30  00  00  C0
 20561 WRITE 8F [XACT_CFG]  2C [FRC_END END_STATE:3]
 20562 READ  0F [XACT_CFG]  0C [END_STATE:3]
 20562 WRITE C1 [TX_LENGTH]  10 [TX_Length:10]  C3
 20562 WRITE A0 [TX_BUFFER]  7F  00  00  00  00  00  00  00  00  00  00  00  00  00  FF  FF
 20564 READ  04 [TX_IRQ_STATUS]  DA [OS_IRQ LV_IRQ TXB8_IRQ TXB0_IRQ TXC_IRQ]  DA
 20568 READ  0C [XTAL_CTRL]  00
 20568 WRITE A9 [RX_ABORT]  00
 20568 WRITE D5 [CRC_SEED_LSB]  10 [CRC_SEED_LSB:10]  1C
 20568 WRITE A2 [SOP_CODE]  40
 20568 WRITE A2 [SOP_CODE]  56
 20568 WRITE A2 [SOP_CODE]  32
 20568 WRITE A2 [SOP_CODE]  D9
 20568 WRITE A2 [SOP_CODE]  0F
 20568 WRITE A2 [SOP_CODE]  D9
 20568 WRITE A2 [SOP_CODE]  5D
 20568 WRITE A2 [SOP_CODE]  97
 20568 WRITE A3 [DATA_CODE]  08
 20568 WRITE A3 [DATA_CODE]  D1
 20568 WRITE A3 [DATA_CODE]  AE
 20568 WRITE A3 [DATA_CODE]  59
 20568 WRITE A3 [DATA_CODE]  5E
 20569 WRITE A3 [DATA_CODE]  E8
 20569 WRITE A3 [DATA_CODE]  F0
 20569 WRITE A3 [DATA_CODE]  C0
 20569 WRITE A3 [DATA_CODE]  90
 20569 WRITE A3 [DATA_CODE]  8F
 20569 WRITE A3 [DATA_CODE]  BB
 20569 WRITE A3 [DATA_CODE]  7C
 20569 WRITE A3 [DATA_CODE]  8E
 20569 WRITE A3 [DATA_CODE]  2B
 20569 WRITE A3 [DATA_CODE]  8E
 20569 WRITE 80 [CHANNEL]  4A [Channel:4a]
 20579 WRITE 85 [RX_CTRL]  83 [RX_GO RXC_IRQEN RXE_IRQEN]
 20579 READ  07 [RX_IRQ_STATUS]  7A [SOPDET_IRQ RXB16_IRQ RXB8_IRQ RXB1_IRQ RXC_IRQ]  7A
 20579 READ  09 [RX_COUNT]  10 [RX_Count:10]
 20579 READ  21 [RX_BUFFER]  34  FE  0C  02  2C  50  13  FE  24  00  1B  FC  30  00  00  C0
 20579 WRITE 8F [XACT_CFG]  2C [FRC_END END_STATE:3]
 20580 READ  0F [XACT_CFG]  0C [END_STATE:3]
 20580 WRITE A9 [RX_ABORT]  00
 20580 WRITE D5 [CRC_SEED_LSB]  EF [CRC_SEED_LSB:ef]  E3
 20580 WRITE A2 [SOP_CODE]  E1
 20580 WRITE A2 [SOP_CODE]  D6
 20580 WRITE A2 [SOP_CODE]  31
 20580 WRITE A2 [SOP_CODE]  26
 20580 WRITE A2 [SOP_CODE]  5F
 20580 WRITE A2 [SOP_CODE]  BD
 20580 WRITE A2 [SOP_CODE]  40
 20581 WRITE A2 [SOP_CODE]  93
 20581 WRITE A3 [DATA_CODE]  5F
 20581 WRITE A3 [DATA_CODE]  30
 20581 WRITE A3 [DATA_CODE]  3B
 20581 WRITE A3 [DATA_CODE]  56
 20581 WRITE A3 [DATA_CODE]  96
 20581 WRITE A3 [DATA_CODE]  45
 20581 WRITE A3 [DATA_CODE]  F4
 20581 WRITE A3 [DATA_CODE]  A1
 20581 WRITE A3 [DATA_CODE]  03
 20581 WRITE A3 [DATA_CODE]  BC
 20581 WRITE A3 [DATA_CODE]  6E
 20581 WRITE A3 [DATA_CODE]  8A
 20581 WRITE A3 [DATA_CODE]  EF
 20581 WRITE A3 [DATA_CODE]  BD
 20581 WRITE A3 [DATA_CODE]  FE
 20581 WRITE A3 [DATA_CODE]  F8
 20581 WRITE 80 [CHANNEL]  24 [Channel:24]
 20583 WRITE 85 [RX_CTRL]  83 [RX_GO RXC_IRQEN RXE_IRQEN]
 20583 READ  07 [RX_IRQ_STATUS]  7A [SOPDET_IRQ RXB16_IRQ RXB8_IRQ RXB1_IRQ RXC_IRQ]  7A
 20583 READ  09 [RX_COUNT]  10 [RX_Count:10]
 20583 READ  21 [RX_BUFFER]  34  FE  0C  02  2C  50  13  FE  24  00  1B  FC  30  00  00  C0
 20583 WRITE 8F [XACT_CFG]  2C [FRC_END END_STATE:3]
 20584 READ  0F [XACT_CFG]  0C [END_STATE:3]
 20584 WRITE C1 [TX_LENGTH]  10 [TX_Length:10]  C3
 20584 WRITE A0 [TX_BUFFER]  7F  00  00  00  00  00  00  00  00  00  00  00  00  00  FF  FF
 20586 READ  04 [TX_IRQ_STATUS]  DA [OS_IRQ LV_IRQ TXB8_IRQ TXB0_IRQ TXC_IRQ]  DA
 20590 READ  0C [XTAL_CTRL]  00
 20590 WRITE A9 [RX_ABORT]  00
 20590 WRITE D5 [CRC_SEED_LSB]  10 [CRC_SEED_LSB:10]  1C
 20590 WRITE A2 [SOP_CODE]  03
 20590 WRITE A2 [SOP_CODE]  BC
 20590 WRITE A2 [SOP_CODE]  6E
 20590 WRITE A2 [SOP_CODE]  8A
 20590 WRITE A2 [SOP_CODE]  EF
 20590 WRITE A2 [SOP_CODE]  BD
 20590 WRITE A2 [SOP_CODE]  FE
 20590 WRITE A2 [SOP_CODE]  F8
 20590 WRITE A3 [DATA_CODE]  40
 20590 WRITE A3 [DATA_CODE]  BA
 20590 WRITE A3 [DATA_CODE]  97
 20590 WRITE A3 [DATA_CODE]  D5
 20590 WRITE A3 [DATA_CODE]  86
 20590 WRITE A3 [DATA_CODE]  4F
 20590 WRITE A3 [DATA_CODE]  CC
 20591 WRITE A3 [DATA_CODE]  D1
 20591 WRITE A3 [DATA_CODE]  D7
 20591 WRITE A3 [DATA_CODE]  A1
 20591 WRITE A3 [DATA_CODE]  54
 20591 WRITE A3 [DATA_CODE]  B1
 20591 WRITE A3 [DATA_CODE]  5E
 20591 WRITE A3 [DATA_CODE]  89
 20591 WRITE A3 [DATA_CODE]  AE
 20591 WRITE A3 [DATA_CODE]  86
 20591 WRITE 80 [CHANNEL]  20 [Channel:20]
 20601 WRITE 85 [RX_CTRL]  83 [RX_GO RXC_IRQEN RXE_IRQEN]
 20601 READ  07 [RX_IRQ_STATUS]  7A [SOPDET_IRQ RXB16_IRQ RXB8_IRQ RXB1_IRQ RXC_IRQ]  7A
 20601 READ  09 [RX_COUNT]  10 [RX_Count:10]
 20601 READ  21 [RX_BUFFER]  34  FE  0C  02  2C  50  13  FE  24  00  1B  FC  30  00  00  C0
 20601 WRITE 8F [XACT_CFG]  2C [FRC_END END_STATE:3]
 20602 READ  0F [XACT_CFG]  0C [END_STATE:3]
 20602 WRITE A9 [RX_ABORT]  00

Yes, do a "grep CHANNEL" show me this jumping sequence.
It is DSMX all right:

 20295 WRITE 80 [CHANNEL]  10 [Channel:10]
 20305 WRITE 80 [CHANNEL]  32 [Channel:32]
 20317 WRITE 80 [CHANNEL]  4A [Channel:4a]
 20327 WRITE 80 [CHANNEL]  24 [Channel:24]
 20339 WRITE 80 [CHANNEL]  20 [Channel:20]
 20349 WRITE 80 [CHANNEL]  0E [Channel:e]
 20361 WRITE 80 [CHANNEL]  1C [Channel:1c]
 20371 WRITE 80 [CHANNEL]  34 [Channel:34]
 20383 WRITE 80 [CHANNEL]  04 [Channel:4]
 20393 WRITE 80 [CHANNEL]  26 [Channel:26]
 20405 WRITE 80 [CHANNEL]  1A [Channel:1a]
 20415 WRITE 80 [CHANNEL]  1E [Channel:1e]
 20427 WRITE 80 [CHANNEL]  3E [Channel:3e]
 20437 WRITE 80 [CHANNEL]  0C [Channel:c]
 20449 WRITE 80 [CHANNEL]  14 [Channel:14]
 20459 WRITE 80 [CHANNEL]  40 [Channel:40]
 20471 WRITE 80 [CHANNEL]  44 [Channel:44]
 20481 WRITE 80 [CHANNEL]  48 [Channel:48]
 20493 WRITE 80 [CHANNEL]  06 [Channel:6]
 20503 WRITE 80 [CHANNEL]  42 [Channel:42]
 20515 WRITE 80 [CHANNEL]  08 [Channel:8]
 20525 WRITE 80 [CHANNEL]  3C [Channel:3c]
 20537 WRITE 80 [CHANNEL]  2E [Channel:2e]
 20547 WRITE 80 [CHANNEL]  10 [Channel:10]
 20559 WRITE 80 [CHANNEL]  32 [Channel:32]
 20569 WRITE 80 [CHANNEL]  4A [Channel:4a]
 20581 WRITE 80 [CHANNEL]  24 [Channel:24]
 20591 WRITE 80 [CHANNEL]  20 [Channel:20]
 20603 WRITE 80 [CHANNEL]  0E [Channel:e]
 20613 WRITE 80 [CHANNEL]  1C [Channel:1c]
 20625 WRITE 80 [CHANNEL]  34 [Channel:34]
 20635 WRITE 80 [CHANNEL]  04 [Channel:4]
 20647 WRITE 80 [CHANNEL]  26 [Channel:26]
 20657 WRITE 80 [CHANNEL]  1A [Channel:1a]
 20669 WRITE 80 [CHANNEL]  1E [Channel:1e]
 20679 WRITE 80 [CHANNEL]  3E [Channel:3e]
 20691 WRITE 80 [CHANNEL]  0C [Channel:c]
 20701 WRITE 80 [CHANNEL]  14 [Channel:14]
 20713 WRITE 80 [CHANNEL]  40 [Channel:40]
 20723 WRITE 80 [CHANNEL]  44 [Channel:44]
 20735 WRITE 80 [CHANNEL]  48 [Channel:48]
 20745 WRITE 80 [CHANNEL]  06 [Channel:6]

Very cool guys!

I wonder if every guid produces a unique sequence of channel hops?

Does the Tx send the set of channels over during the bind process or does the Rx guess the sequence based on the GUID alone? Seems like the Hitec protocol sends the sequence of channels over as part of the bind process, not sure about FAAST.

FYI, the CYRF69103 has the SPI bus is connected to the external pin as well.
That is where I am tapping to. The pin is not used an it has not trace on it.
It is just hard to solder on.

Originally Posted by pmackenzie

inside the module, between its processor and the RF chip.

Both TX and RX using a internal (not open) function to produce the channel jumping sequence.
That is the hard part. Unless we get the DSMX TX/RX firmware. It is very hard to figure out
how that mapping function was done.

Nice work! Subscribed.

Originally Posted by printk

Yes, do a "grep CHANNEL" show me this jumping sequence.
It is DSMX all right:

Good to see you have it working. I've been working with the CYRF6936 for so long now, that I know all the (important) addresses, so I never bothered labeling them. The DSMX protocol has 2 levels of encryption. One is inherited from DSM2 and uses a different SOP/DATA code for each channel/GUID. The algorithm for this is known, and is not complicated. DSMX adds this second layer of channel hopping which we don't know.
You can find all the details I know of DSM2 here:
https://bitbucket.org/PhracturedBlue...txt?at=default
There is a little bit about DSMX in there, but basically it is the same, but using a different channel-hopping scheme, and the selection of SOP codes is offset by 2.

The decoder does more than labelling the register address.
It can decode every single bit field in the document.
I found "SOPDET_IRQ RXB16_IRQ RXB8_IRQ RXB1_IRQ RXC_IRQ"
is easier to read than 0x7A for example.

In your RPi setup, do you know what change do I need to do
if I use the Walkera 8S module? I hope is the same from
the programming point of view. I have the RPi but never both
to set it up. Now I just set it up and I can compile your program
in the RPi fine. Need to connect the TX module and the
RX through the power switch. Does the Walkera TX module
operate at 3.3V?

I found some TX packet in the MCPX DSMX protocol.
So the MCPX actual transmit some data back.

 20669465 WRITE 80 [CHANNEL]  1E [Channel:1e]
 20671622 WRITE 85 [RX_CTRL]  83 [RX_GO RXC_IRQEN RXE_IRQEN]
 20671658 READ  07 [RX_IRQ_STATUS]  7A [SOPDET_IRQ RXB16_IRQ RXB8_IRQ RXB1_IRQ RXC_IRQ]  7A
 20671682 READ  09 [RX_COUNT]  10 [RX_Count:10]
 20671785 READ  21 [RX_BUFFER]  34  FE  0C  02  2C  50  13  FE  24  00  1B  FC  30  00  00  C0
 20671803 WRITE 8F [XACT_CFG]  2C [FRC_END END_STATE:3]
 20672562 READ  0F [XACT_CFG]  0C [END_STATE:3]
 20672585 WRITE C1 [TX_LENGTH]  10 [TX_Length:10]  C3
 20672909 WRITE A0 [TX_BUFFER]  7F  00  00  00  00  00  00  00  00  00  00  00  00  00  FF  FF
 20674249 READ  04 [TX_IRQ_STATUS]  DA [OS_IRQ LV_IRQ TXB8_IRQ TXB0_IRQ TXC_IRQ]  DA
 20678298 READ  0C [XTAL_CTRL]  00

Originally Posted by printk

The decoder does more than labelling the register address.
It can decode every single bit field in the document.
I found "SOPDET_IRQ RXB16_IRQ RXB8_IRQ RXB1_IRQ RXC_IRQ"
is easier to read than 0x7A for example.

Yeah I understand. Someone captured zigbee(?) traces for me in that format. It is cool, but didn't really help me too much to be honest.

In your RPi setup, do you know what change do I need to do
if I use the Walkera 8S module?

No change. The modules are interchangeable.

Does the Walkera TX modulecoperate at 3.3V?

Umm I'm pretty sure it operates on 5V in the Tx, but I 'm currently running it at 3.3V and it works fine.

I found some TX packet in the MCPX DSMX protocol.
So the MCPX actual transmit some data back.

Yes I've documented this in the link above. The Rx sends back its capabilities (this is how DSM2 vs DSMX is autodetected). It isn't actually necessary for the Tx to parse this packet if you already know whether you should send DSM2 or DSMX, but it can be used as an interlock to let the Tx know that the Rx has bound properly.

Originally Posted by PhracturedBlue

Yes I've documented this in the link above. The Rx sends back its capabilities (this is how DSM2 vs DSMX is autodetected). It isn't actually necessary for the Tx to parse this packet if you already know whether you should send DSM2 or DSMX, but it can be used as an interlock to let the Tx know that the Rx has bound properly.

I think in your document, How often is that ACK binding sending it back?
I recall it is only at bind time.

The packet trace I got is back every 22ms. My guess is that those
are telemetric data.

Originally Posted by printk

I think in your document, How often is that ACK binding sending it back?
I recall it is only at bind time.

The packet trace I got is back every 22ms. My guess is that those
are telemetric data.

Right the packets I've seen are transmitted only for a short time after binding. What you've got is something I haven't seen before then. I misunderstood. very cool.

You know what, all the sequences in post #2 start and end with the same channel number. Except for the last one:

a1d75ce4: -> 61 -> 25 -> 19 -> 29 -> 49 -> 9 -> 3 -> 41 -> 27 -> 15 -> 31 -> 5 -> 63 -> 21 -> 39 -> 33 -> 65 -> 57 -> 47 -> 67 -> 69 -> 55 -> 61 -> 19
Duplicate Channel: 61
Duplicate Channel: 19

I'm kind of amazed! I though duplicate channel values would make syncing up really difficult/unreliable. It's pretty trivial to arrange for there not to be duplicates in the sequence. Is this a GUID for a real radio?

I was investigating the possibility that the sequences were made using some kind of shuffle but that can't be the case (if the above sequence works). A shuffle would not produce duplicate values like the one in the sequence for 0xa1d75ce4.

racerxky,

The duplicate channel is the start of the sequence. I think the OP means after the
23 channel sequence, it will loop from the 1st channel again. It is the same 23
channel sequence repeating. He only list the first duplicate channel to save space.

I duplicate your setup of the RPi.



The power circuit I reuse the MCPX motor PFET. I remove the MCPX
MCU and connect the main motor signal to the RPi GPIO 17. Then
I let the main motor output to power the receiver circuit. I verify when
the GPIO 17 is high, the main motor FET is open, receiver is powered on.

The logic analyser show that the RPi can control the MCPX receiver chip
and the SPI bus of the receiver chip looks sane compare to the previous
receiver trace without the walkera TX.

On the TX side, I use the Walkera 8S upgraded module. I connect the
SS to SPI.E0, MISO to MISO, MOSI to MOSI, V+ to 3.3v then share the ground.
The trace show that, the SPI reading and writing looks sane. E.g. When it
read the interrupt status, the TX module actually send back some value
other than zero. Same to reading MFG_ID, it has value other than zero
and change on different byte. So I assume the RPi to Walkera TX SPI
bus is working.

It did generate some interesting trace on the RX side. But not the
same as the DX4e case. I grep for "RX_BUFFER|CHANNEL"
in the RX SPI trace, it show:

 02796514 READ  21 [RX_BUFFER]  72  01  07  A2  00  02  8F
 02796676 READ  21 [RX_BUFFER]  40  40  40  40  40  40  40
 02806567 READ  21 [RX_BUFFER]  00  00  00  01  00  00  00  01  01  72  01  07  A2  00  02  8F
 02816541 READ  21 [RX_BUFFER]  00  00  00  01  00  00  00  01  01  72  01  07  A2  00  02  8F
 02826579 READ  21 [RX_BUFFER]  00  00  00  01  00  00  00  01  01  72  01  07  A2  00  02  8F
 02836589 READ  21 [RX_BUFFER]  00  00  00  01  00  00  00  01  01  72  01  07  A2  00  02  8F
 02846588 READ  21 [RX_BUFFER]  00  00  00  01  00  00  00  01  01  72  01  07  A2  00  02  8F
 02856586 READ  21 [RX_BUFFER]  00  00  00  01  00  00  00  01  01  72  01  07  A2  00  02  8F
 05532617 WRITE 80 [CHANNEL]  34 [Channel:34]
 05542908 WRITE 80 [CHANNEL]  06 [Channel:6]
 05552848 WRITE 80 [CHANNEL]  04 [Channel:4]
 05563032 WRITE 80 [CHANNEL]  42 [Channel:42]
 05572965 WRITE 80 [CHANNEL]  26 [Channel:26]
 05583141 WRITE 80 [CHANNEL]  08 [Channel:8]
 05593081 WRITE 80 [CHANNEL]  1A [Channel:1a]
 05603264 WRITE 80 [CHANNEL]  3C [Channel:3c]
 05613196 WRITE 80 [CHANNEL]  1E [Channel:1e]
 05623376 WRITE 80 [CHANNEL]  2E [Channel:2e]
 05633322 WRITE 80 [CHANNEL]  3E [Channel:3e]
 05643506 WRITE 80 [CHANNEL]  10 [Channel:10]
 05653444 WRITE 80 [CHANNEL]  0C [Channel:c]
 05663627 WRITE 80 [CHANNEL]  32 [Channel:32]
 05673554 WRITE 80 [CHANNEL]  14 [Channel:14]
 05683736 WRITE 80 [CHANNEL]  4A [Channel:4a]
 05693663 WRITE 80 [CHANNEL]  40 [Channel:40]
 05703841 WRITE 80 [CHANNEL]  24 [Channel:24]
 05713770 WRITE 80 [CHANNEL]  44 [Channel:44]

I am doing GUID 0000001 as my first GUID. That means the receive did
receive the bind packet. However, it is not happy with the bind packet
some how. It is not doing the sequence jumping after the bind packet
stops. There is no channel jumping between 2 second to 5 second.

The write sequence begin at 5 second is already after the power
cycle. That sequence is the original DX4e binding before the timeout.
It does not change according to the GUID on the sender side.

I think most of the setup is working. It might need some tuning
to make the MCPX receiver happy about the binding.

Have you try this with a MCPX/130x/Nano CPX/MQX/MSRX receiver?

Originally Posted by PhracturedBlue

I've included the code. you need a RPi, and it needs to have the spi_bcm2708 module loaded to enable spi. the code uses GPIO17 (which for GP0 on my breakout board) to turn the Rx on/off (the pin will go high when the Rx should be on)
compile as:

gcc main.c dsm2.c -lrt

It takes 2 arguments startGUID and endGUID
It is designed to control a Walkera CYRF6936 module (it may work with others, but the PA control on the Walkera module is unique)
You must have some mechanism to capture the SPI output of the Rx
It takes 6 seconds per GUID to capture (it may be possible to shave a little time off this, but at some point you run into reliability issues, as it can take a while for for the Rx to see the Tx binding codes)