[EN] FlySky i6 part 2: Inside the Tx

In part 1 we noticed that the receiver was giving 14 channels to the FC, not 6. It would be great to be able to use those 8 extra channel. First thing to do is to check if these channels are really transmitted from the Tx to the Rx and not created by the Rx to meet IBus specs. So today we’ll have our hands dirty, and take the screwdriver out of his box!

Well ok, 4 screw is’nt really a hardcore teardown… Anyway, the inside of the Tx is quite well looking, the pcb seems to be good quality. We see a Freescale Kinetis L16 in the middle (MKL16Z64VLH4). It is an ARM Cortex M0+ with 64KB of flash. Another noticeable component is the RF module, and the last important component is the tiny 8 pins chip in th rigth. It is a 24C128 I2C EEPROM, with 128Kb (16KB) of memory, probably used to store user settings.

There is a lot of testpoints and the silkscreen is full of informations! We directly see a populated 5 pin « Debug1 » port, wich is a SWD port, used to debug or to flash the firmware of the MCU. Maybe this could also be used to dump the stock firmware. Getting all these informations so easily makes me think that flysky want the open source community to hack this device. Maybe to compete with the Turnigy 9x? The MCU used in this i6 has the same amount of program flash that the AtMega64 in the 9x, maybe would it be possible to port a custom firmware made for the 9x?Anyway, let’s get to the point.

If we look around the RF module, we can see, on his left, 3 testpoints with their names:

• SCS      (Chip Select)
• SCLK    (Clock)
• SDIO    (Data In / Out)

This tells us that it’s a SPI interface between the MCU and the RF module. This SPI is a little bit special, becaus it only uses 3 wires. The data is transmitted using only one wire, no mather wich direction it goes. This is a digital communication, so let’s use our logic analyzer!

SPI transmission 

As there is only one communcation channel, we can’t directly know who is sending or receiving data. But this is a RF transmitter, so we expect data to go from the MCU to the RF module. There will be however data going the other way, because the i6 has telemetry capabilities.

To begin, we don’t power up the receiver, it will avoid us to see telemetry data.

The upper channel is SDIO and the other is SCLK.We see that 3 packets of data are sent every 3.8 ms. We use the software to decode them. (SPI, CPOL=0, CPHA=0, MSB first, 8bit).

The first packet is composed by 43 bytes, the second one is 1 byte (0xD0) and the last one is 4 bytes (0xF0 0x0F 0xXX 0xC0). Why did I wrote 0xXX? Because this byte equals 0x1C, but it changes for every frame. In fact it makes a loop of known values.

Let’s get back to the first packet of 43 bytes. It will most likely contains our channels. If it contains the whole 14 channels, then we’ll know that the TX really does send the 8 bonus channels and that the limitation is only in software!

xA0

xE0

x05x58
x5Ax89
x36x77
x41x88
xD0xB2
x5Cx05    chan 1
x17x06    chan 2
xF1x03    chan 3
xD1x04    chan 4
xD0x07    chan 5
xD0x07    chan 6
xDCx05    chan 7
xDCx05    chan 8
xDCx05    chan 9
xDCx05    chan 10
xDCx05    chan 11
xDCx05    chan 12
xDCx05    chan 13
xDCx85    chan 14
x00

x0F
xXX

Once again we have a few header bytes, then… hourra! Our 14 channels are there! The TX is therefore only limited to 6 channels in software. The last byte (0xXX) contains the value 0x1D, and also changes for every frame. It’s always the value of the other changing byte, plus 1. Here is the loop of values:

… x60 x51 x1D x33 x16 x0F x64 x24 x7A x84 x59 x92 x68 x45 x6E x29 x60 x51 x1D x33 …

Improvement leads

If we want to use these channels, I see 2 options:

1. Use another MCU, no need to be extra high tech. It could sniff the SPI frame and change it on the fly.
2. Make a patch to the software to use the channels.

The first option has the advantage to let the software clean and avoid risks of bricking the device. But it requires hardware modifications, and it could be difficult to do the changes on the fly with no noticeable latency.

The second option is more « sexy », no need of extra hardware, and it would be possible to port other open source firmwares made for the Turnigy 9X. We could try to mod the official updater to flash the MCU, or to use the « Debug1 » port.

In the next post I’ll start to reverse the updater, and see how he program the TX.

Thom

PS: Help me to buy a new oscilloscope: Donate on PayPal !
Any help is really appreciated 😉