Forum: Mikrocontroller und Digitale Elektronik Reverse Engineering: höhenverstellbarer Tisch


von Marco G. (stan)



Lesenswert?

Hallo,

für mein Homeoffice habe ich mir einen höhenverstellbaren Tisch gegönnt 
und versuche nun das Protokoll zwischen Bedienteil und Antrieb zu 
entschlüsseln.

Inspiriert wurde ich von diesem Video (gleicher Tisch btw), wobei mir 
die Vorgehensweise zu plump ist:
https://www.youtube.com/watch?v=vKwUHvPv-U8

Ich habe keinen Sprachassistenten und ob ich das irgendwo einbinden 
werde weiß ich auch noch nicht. Momentan geht es mir eher darum zu 
schauen wie weit man kommt.



Der Tisch bzw. das Gestell ist ein Flexispot E5, die Steuerung ist von 
Loctek.


Auf der Bedienteil-Platine sitzt ein TM1650 LED-Controller und ein 
STM8S003F3P6.
Auf der Controller-Platine ist ein STM8S007C8T6.


Zwischen Bedienteil und Controller ist ein 8-adriges Kabel mit 
RJ45-Stecker und folgender Pinbelegung:
1
1  brown   Reset vom µC
2
2  white   SWIN vom µC
3
3  purple  nicht benutzt
4
4  red     wird vom Bedienteil auf high gezogen solange das Display an ist
5
5  green   RX (aus Sicht des Bedienteils)
6
6  black   TX (aus Sicht des Bedienteils)
7
7  blue    GND
8
8  yellow  VDD (5 Volt)

Warum Reset und SWIN über das Kabel geführt werden? Vielleicht wird 
darüber die FW aufgespielt.


Der UART läuft mit 9600 Baud, 8N1.

Nach jedem Tastendruck bleibt das Display rund 3 Sekunden an und zeigt 
die aktuelle Höhe an. Während dieser Zeit ist Leitung 4 high und es 
findet RX/TX-Kommunikation statt.


Das Protokoll sieht in beiden Richtungen folgendermaßen aus:
1
Startbyte = 0x9B
2
Länge (ohne Start/Endbytes)
3
Payload
4
...
5
Endbyte = 0x9D

Folgende Kommunikation habe ich aufgezeichnet, vom Bedienteil zum 
Controller:
Start- und Endbytes sind nicht dargetellt, die erste Spalte ich die 
Länge, alles in Hex.
1
LEN 1  2  3  4  5    Taste
2
---------------------------------------- 
3
 06 02 00 00 6C A1   keine Taste gedrückt
4
 06 02 01 00 FC A0   UP
5
 06 02 02 00 0C A0   DOWN
6
 06 02 04 00 AC A3   [1]
7
 06 02 08 00 AC A6   [2]
8
 06 02 10 00 AC AC   [3]
9
 06 02 20 00 AC B8   [M]
Spalte 1: vielleicht das Kommando, 2 = Tastenstatus.
Spalte 2: gedrückte Taste(n), pro Taste ein Bit.
Spalte 3: immer Null
Spalte 4 und 5: vielleicht eine Art Checksumme? Die Werte sind immer so, 
ändern sich nicht über Zeit oder mit der Höhe des Tisches.



Vom Controller zum Bedienteil:

Eine Fahrt um 2 mm, von 72,0 bis 72,2 cm:
1
LEN 1  2  3  4  5  6    Höhe [cm]
2
--------------------------------- 
3
 07 12 07 DB 3F 99 3F   72,0
4
 07 12 07 DB 06 8B FF   72,1
5
 07 12 07 DB 5B 72 3E   72,2

Eine Fahrt von etwa 72 cm nach 80 cm Höhe:
1
LEN 1  2  3  4  5  6    
2
--------------------------------- 
3
 07 12 07 86 6F 35 07 
4
 07 12 07 DB 3F 99 3F 
5
 07 12 07 DB 06 8B FF 
6
 07 12 07 DB 5B 72 3E 
7
 07 12 07 DB 4F 7D 3E 
8
 07 12 07 DB 66 A3 FF 
9
 07 12 07 DB 6D 64 BE 
10
 07 12 07 DB 7D A8 BF 
11
 07 12 07 DB 07 4B 3E 
12
 07 12 07 DB 7F 69 3E 
13
 07 12 07 DB 6F A5 3F 
14
 07 12 07 CF 3F 99 30 
15
 07 12 07 CF 06 8B F0 
16
 07 12 07 CF 4F 7D 31 
17
 07 12 07 CF 66 A3 F0 
18
 07 12 07 CF 6D 64 B1 
19
 07 12 07 CF 07 4B 31 
20
 07 12 07 CF 7F 69 31 
21
 07 12 07 CF 6F A5 30 
22
 07 12 07 E6 06 1B EF 
23
 07 12 07 E6 5B E2 2E 
24
 07 12 07 E6 66 33 EF 
25
 07 12 07 E6 7D 38 AF 
26
 07 12 07 E6 07 DB 2E 
27
 07 12 07 E6 6F 35 2F 
28
 07 12 07 ED 3F 39 28 
29
 07 12 07 ED 5B D2 29 
30
 07 12 07 ED 66 03 E8 
31
 07 12 07 ED 7D 08 A8 
32
 07 12 07 ED 7F C9 29 
33
 07 12 07 FD 3F F9 25 
34
 07 12 07 FD 5B 12 24 
35
 07 12 07 FD 66 C3 E5 
36
 07 12 07 FD 6D 04 A4 
37
 07 12 07 FD 07 2B 24 
38
 07 12 07 FD 6F C5 25 
39
 07 12 07 87 06 8B C6 
40
 07 12 07 87 4F 7D 07 
41
 07 12 07 87 6D 64 87 
42
 07 12 07 87 07 4B 07 
43
 07 12 07 87 6F A5 06 
44
 07 12 07 FF 06 8B E4 
45
 07 12 07 FF 4F 7D 25 
46
 07 12 07 FF 6D 64 A5 
47
 07 12 07 FF 07 4B 25 
48
 07 12 07 FF 6F A5 24 
49
 07 12 07 EF 06 4B E9 
50
 07 12 07 EF 4F BD 28 
51
 07 12 07 EF 6D A4 A8 
52
 07 12 07 EF 07 8B 28 
53
 07 12 7F BF 3F 40 95 
54
 07 12 7F BF 5B AB 94 
55
 07 12 7F BF 66 7A 55 
56
 07 12 7F BF 6D BD 14 
57
 07 12 7F BF 7D 71 15 
58
 07 12 7F BF 07 92 94 
59
 07 12 7F BF 7F B0 94
Selbst wenn ich Spalte 1 und 2 als eine Art Status betrachte, sind in 
den restlichen Spalten zu große Sprünge um da einen ansteigenden Verlauf 
zu erkennen.



Dazwischen schickt der Controller immer noch 2 weitere Telegramme, die 
sich nicht mit der Höhe ändern:
1
LEN 1  2  3  4  5  6    
2
--------------------------------- 
3
 ...
4
 07 12 07 DB 5B 72 3E 
5
 04 11 7C C3 
6
 04 15 BF C2 
7
 04 15 BF C2 
8
 04 11 7C C3 
9
 04 15 BF C2 
10
 07 12 07 DB 5B 72 3E 
11
 ...


Vielleicht hat irgendwer eine zündende Idee, oder kennt eine gute 
Vorgehensweise wie man so ein Protokoll entschlüsseln kann.

In der Zwischenzeit versuche ich mal die Höhenwerte über einen größeren 
Bereich aufzuzeichnen. Vielleicht erkennt man dann mehr.

: Bearbeitet durch User
von minifloat (Gast)


Lesenswert?

Marco G. schrieb:
> Spalte 4 und 5: vielleicht eine Art Checksumme?

Laut dem Online-CRC-Rechner hier...
https://www.lammertbies.nl/comm/info/crc-calculation
... sind Spalte 4 und 5 die Modbus-CRC16 über die Spalten LEN bis auf 
die letzten beiden. Das ist in beiden Kommunikationsrichtungen so. Bei 
einzelnen Knöpfen sieht das dann jeweils wie eine Konstante aus.

mfg mf

von Marco G. (stan)


Lesenswert?

Spitze, vielen Dank!

Dann kann ich mich bei der Analyse der Höhenwerte auf die vorderen Bytes 
fokussieren und die letzten 2 unberücksichtigt lassen.

von minifloat (Gast)



Lesenswert?

Ich hab die Dekodierung der Zahlen rausbekommen.

Und...
Marco G. schrieb:
> Eine Fahrt von etwa 72 cm nach 80 cm Höhe
... mus ich leider als Lüge bezeichnen.

Es ging bei 71.9 los und endete bei 80.8 !
Siehe Screenshots und Exceltool angehängt.

Viel Spaß damit!
mfg mf

von Marco G. (stan)


Lesenswert?

Oh wow, meinen tiefsten Respekt!

Sogar ein schickes Excelsheet hast du noch hingebastelt.

Dass über die serielle Schnittstelle gar nicht die Zahl übertragen wird, 
sondern nur welche Segmente der LED-Anzeige leuchten sollen, darauf wäre 
ich sicherlich nicht so bald gekommen.
Allerdings ist es extrem sinnvoll, denn dadurch wird der µC nicht mit 
irgendwelchen Umrechnungen "belastet", sondern gibt das einfach ohne 
besonderen Algorithmus an der TM1650 LED-Treiber weiter.


Und ich wollte gerade anfangen einen Dekoder für sigrok zu schreiben um 
die relevanten Bytes besser darzustellen.

: Bearbeitet durch User
von minifloat (Gast)


Lesenswert?

Wie ich drauf gekommen bin:

1. Man sieht bei Datenbyte2...
- sehr lange eine 07 (3 Bits gesetzt)
- später dann mal 7F (7 Bits gesetzt)
...was irgendwie gut zu Siebensegment passt.

2. Im Kopf probiert, ja, Bit# 0-7 zu Siebensegment a-g, passt.

3. 3 Stellen Siebensegment <=> 3 Bytes im Protokoll, passt.

4. Daten in Excel importiert und Bitmuster angesehen,
   ob die Bit# 0-7 zu Siebensegment a-g, dp auch bei Millimeterstelle
   hinhaut, passt immer noch.

5. Siebensegment in Excel nachgebastelt, alle mal durchgegangen, passt.

von minifloat (Gast)


Lesenswert?

Marco G. schrieb:
> Und ich wollte gerade anfangen einen Dekoder für sigrok zu schreiben

Jetzt kannst du einen für dein ENdgerät schreiben :)

von minifloat (Gast)


Lesenswert?

Marco G. schrieb:
> dadurch wird der µC nicht mit irgendwelchen Umrechnungen "belastet"

Zum Glück ist kein imperialer Fuß-und-Daumen-Modus vorgesehen xD

Danke für das schöne Karfreitagsrätsel
mfg mf

von UtH (Gast)


Lesenswert?

Hilft nicht weiter, aber das mit der Checksum kann ich bestätigen: 16Bit 
CRC MODBUS

https://crccalc.com/ Die Seite ist evtl noch interessant für jemanden, 
sie erklärt nicht nicht so viel wie die hier vorher genannte Seite, aber 
hat mehr Auswahl zum Prüfen.

von heinz (Gast)


Lesenswert?

@Marco G.
konntest du eine Höhe an das Motorsteuergerät senden und er fährt diese 
dann an?

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.