DEV Community

Cover image for Analyzing the communication protocol of the Decathlon Walk by domyos
endes0
endes0

Posted on

Analyzing the communication protocol of the Decathlon Walk by domyos

Some months ago I bought a treadmill from Decathlon, A "Walk by domyos", a pretty basic model. It has a console where you can set the speed and see a variety of metrics (total exercise time, total kms, etc.). Of course, some weeks later, I could not resist the urge to open it up and reverse engineering it.

Teardown

Of course the first thing I did was to open it up, the entire thing (or at least the console and motor control board) seems to be manufactured by ShangaHai Electronics Way Co. Ltd (It took me a while to find the manufacturer website, it doesn't pop up when you search it).

Image description

Image description

Image description

The motor control board is labeled as the model B408D. The microcontroller and other logic ics are on another pcb soldered perpendicular to the main one, and it seems to have a layer of some protective material on top of the board, so reading the ics markings is difficult. There is also a 4 pin header labeled "PROGRAM", 2 of these pins are ground and 5V, I'm pretty sure this is the programming port used to upload the firmware. The connector to the console board is well labeled on every pin and isolated by optocouplers.

Image description

Image description

The console board is labeled as "A1835B1", the labeling seems to also includes the firmware file on the mcu: "TC8_A1835_S115_60509.mot". The board has basically a main mcu and a display driver (the ht1621). Identifying the mcu is not easy, the package is a TSSOP20 and has the following markings "0C000 H3AG", which are not very helpful. After searching "0c000 mcu tssop20" on google this showed up on Aliexpress, so it seems to be a Renesas mcu, maybe a r8c o rl78 series. The main mcu is not directly connected to the RX and TX pins of the connector to the motor control board, but through a circuitry that does a voltage level shifting.

The cable that connects both the board is basically made of 5 lines: The power lines, 12v and GND; the communication lines, RX and TX; and the "SW", that the console connects to 12v when the key is inserted.

I didn't do any more analysis or found anything interesting on the boards, sure it will be interesting to analyze how the motor boards control the motor itself at an electronic level, but it is outside of my knowledge area and sincerely for me, it would be boring.

Tapping the communication between the console and motor board

Now comes the fun part, and of course the most important, as if we reverse the communication protocol we can potentially replace the console with one custom-made with more functionalities or do some fun things (like going more than 8km/h).

The first thing I did was to plug in my cheap logic analyzer into the RX and TX cables without even thinking about if the voltages level were compatible. Of course, it seems that these voltages were too high, and a fun thing happened: When I plugged the analyzer on both cables, the communication got interrupted and the error 5 showed up on the console, but if I only plugged it on the receiving part of each board it didn't interfere.

Fortunately, there were 3 jumpers(0 ohm resistors) nearby the mcu, these were for gnd, rx and tx lines. Luckily those RX and TX lines were before the level shifting and can be tapped without problems. After taking some captures I could decode the protocol as UART at a baud rate of 2400 bauds. For discovering this baud rate, which for me was a very unusual baud as I have never seen this value, but is understandable as maybe a higher rate would be problematic because the cable length or the interference (the motor generates a lot), I used the Sigrok guess baudrate function, which resulted to be very useful.

Unfortunately, while doing some experiments with the console, I accidentally inverted the polarity and broke something, possibly the input pin on the mcu that detects that the key is present. So the console now is useless, which means I could not continue to do all the tests I was doing, so the next parts may come short in some aspects.

Analyzing the messages

All the messages sent by both the console and motor control board follows the next structure.

Byte position 0 1 2..n n+1 n+2
Name Header length Data Checksum Footer
Description Seems to be the unit address. 0x68 for the console. 0x73 for the motor board. Byte size of the data + checksum + footer Content. Console normally sends 7** bytes** and the motor 10 bytes. Sum of the data and length mod 0xFF Always 0x43
Example 0x68 0x8 0x80, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 0x88 0x43

Console data

The console every second or so sends a message containing the following 7 bytes of data.

Byte position 0 1 2 3 4 5 6
Name Key status? Start/stop Speed ? ? ? ?
Description 0x80 if key is present, 0x81 if not. 0x80 when the treadmill is running, 0 when not. selected km/h * 10 Always 0 Always 0 Always 0 Always 0
Example 0x80 0x80 0x06 0x0 0x0 0x0 0x0

On startup, after an initial delay, the console sends this 31 bytes message multiple times.

0x87, 0x2, 0x24, 0x29, 0, 0, 0, 0, 0x1, 0xc, 0, 0, 0x8, 0x8, 0, 0, 0, 0, 0, 0, 0, 0x19, 0, 0, 0x50, 0, 0, 0, 0, 0, 0
Enter fullscreen mode Exit fullscreen mode

I really don't know what it is, maybe the configuration for the motor board?. It doesn't seem to change, I have tried to reset the console, change the units or increment the total kilometers.

Motor board data

In response to the message sent by the console, the motor board sends a message containing the following 10 bytes data.

Byte position 0 1 2 3 4 5 6 7 8 9
Name unknown Measured speed voltage? Another measured speed? motor amperage? unknown status unknown unknown unknown
Description always 0xa0 From the IR rotatory sensor. km/h * 10 Fluctuates between 230 – 250. km/h * 10 see below Always 0 0x21 when ready (you can hear a relay clicking) 0x22 or 0x23 when running Always 0 Always 0 Always 0
Example 0xa0 0x05 0xf6 0x06 0xa 0 0x22 0 0 0

The byte 4 (motor amperage?) seems something that is directly measured from the motor, it fluctuates but seems to increment with the speed (see the table below) and if the motor gets disconnected from the board it goes to a pretty high value (~100).

speed(km/h) value
5 71
2.5 38
1 11
0.5 11

Errors code

The console can give a variety of errors to the user, I thought it would be interesting documenting each one, as the official manual is not very helpful. But, as I said earlier I broke my console board halfway through, so this part is pretty incomplete. In fact I really don't know how most errors get triggered with the motor board messages.

Image description

  • Error 2: It popups when the motor is disconnected from the control board.
  • Error 5: Display board after startup is not receiving motor board messages or are malformed.

By the way, disconnecting the IR rotary speed sensor doesn't seems to trigger an error.

Making a very simple console

As I have broken mine and it is not easy to find, I had to do one for still using the treadmill and not having a giant paperweight at home. The first thing I did for making it run was creating and running a python script in my pc connected through a serial adapter and reusing the level shifting circuitry of the old board. It was not very comfortable to use the treadmill in that way. So with an Arduino UNO, a touch screen shield (MCUFRIEND 2.4” TFT Display) and a horrible written code (I swear I'm a professional software developer, during my shift) I made a simple console to set the speed and start and stop the treadmill.

Here is the gist of the code, keep in mind that is something that I did very fast and when I was tired.

What's left

There are still things left to do for the future, so I might do a follow up post.

  • I want to finish understanding and documenting both message data, especially the control board messages, which I can still capture and do tests.
  • As I broke the console I should try to dump the firmware, so I can reverse engineer the code and so I maybe understand more the messages and errors.
  • Implement a better console with more functionalities, with an esp32 so I could do cool things.

Top comments (0)