Sunra ROBO-S Reverse Engineering des BMS-↔-Steuergerät-Protokolls

[plastikino]

Ziel: MITM-Gerät zwischen BMS und Steuergerät, um den auf 0 % blockierten SOC-Wert einer der beiden Batterien zu korrigieren (dieser Fehler erzwingt den Reservemodus und begrenzt die Geschwindigkeit auf ca. 50 km/h).
Erweitertes Ziel: das Protokoll so tief verstehen, dass sich auch eine selbstgebaute Batterie (eigenes Pack + eigenes BMS) verwenden lässt, die korrekt mit dem Steuergerät kommuniziert, als wäre sie eine Originalbatterie — SOC, Spannung, Strom und Status-Flags im erwarteten Format nachgebildet.
Bestätigter Stand
Bus und Serielle Schnittstelle

RS485 Multi-Drop, 9600 Baud 8N1 (an tausenden Frames validiert, Prüfsumme 100 %)
Batterien werden über eine Adresse im Protokoll unterschieden
Frame-Timeout ≥100 ms (Inter-Byte-Gaps bis zu 70 ms); Pausen von ~400 ms werden per Software erkannt, nicht per Hardware-RMT

Frame-Struktur

Anfrage Steuergerät → BMS: 6 Byte (z. B. 04 01 00 00 00 05)
Antwort BMS → Steuergerät: 22 Byte, Präambel 03 01 00 00 00 02 03 A1
Polling-Zyklus ~193 ms (~5,17 Hz)

Prüfsumme

XOR aller Bytes von 0 bis 20; Byte 21 = Ergebnis. Null Fehler in den Logs.
Kurzformel für Einzelbyte-Änderung: new_CHK = old_CHK ^ old_byte ^ new_byte

Dekodierte Bytes (22-Byte-Antwort)
ByteBedeutung8Seitenselektor (0C/1C/2C/3C)10-11Pack-Spannung (Big-Endian ÷100)12-13Strom (vermutlich Int16 mit Vorzeichen)14SOC direkt in % (0x64 = 100 %) — bestätigt17Langsam wechselndes Status-Flag
Letzte Bestätigung
Neues Log mit 7111 Zeilen (3554 lange + 3556 kurze Frames): Baudrate, Prüfsumme und Seitenselektor allesamt erneut bestätigt, 100 % gültig.
Entwickelte Toolchain
checksum_test.py (Prüfung/Discovery), vcd_to_frames.py, browserbasierter RS485-Log-Colorizer, SD-Logger-Firmware v4.2, Firmware zur schnellen Datenerfassung.
MITM-Hardware
ESP32 DevKit v1 + zwei MAX485-Module, drei Firmware-Modi (Passthrough / Intercept / Replay), ILI9341-Display + SD, getrennte FreeRTOS-Tasks für latenzfreies UART-Bridging.
Nächste Schritte

Aufzeichnung mit beiden eingesteckten Batterien → Adresse der 2. Batterie isolieren und A/B-Vergleich gesunde vs. defekte Batterie (hohe Priorität)
SOC-Spoofing von Byte 14 in der MITM-Firmware umsetzen
Restliche Bytes vollständig dekodieren (Seiten aus Byte 8, Strom, Flags), um eine gültige BMS-Antwort komplett von Grund auf emulieren zu können → Basis für die selbstgebaute Batterie
Den 4-poligen Stecker unter der Sitzbank untersuchen

[enif]

Hallo Plastikino,

Super, was du da schon alles herausgefunden hast! Ich bin sicher, dass wird vielen Robo-S Fahrern noch sehr nützlich werden, wenn die Batterien mal ersetzt werden müssen. Herzlichen Dank für deinen Einsatz in dieser Sache!

Wäre es evtl möglich, ein Foto von deinem "Man-in-the-Middle" Setup (ESP32 - Max485 module - ILI9341) zu posten? Das würde mich sehr interessieren.

Warte nun gespannt auf die angekündigten nächsten Schritte - viel Erfolg!

Gruss, Heinz

[plastikino]

Ich arbeite noch an der MITM-Version; hier ist die Version, die als Logger fungiert.
https://drive.google.com/file/d/1ltyI-x ... sp=sharing
https://drive.google.com/file/d/1oZrl-9 ... sp=sharing
https://drive.google.com/file/d/1zoyk9s ... sp=sharing

[enif]

Vielen Dank Plastikino!
Hättest du auch noch ein Bild, wo man sieht, wie du die RS485 Module an die Batteriepins (und an welche) angeschlossen hast?

[plastikino]

Achten Sie unbedingt auf mögliche Kurzschlüsse.
Für die Protokollierung können Sie bedenkenlos einen RS485-USB-Konverter verwenden.

[enif]

Danke! D.h. die kleinen Pins Nr. 1 und 3 am Stecker sind für das RS485 Signal zuständig.

[plastikino]

Ja, Pins 1 und 3. Laut einem griechischen Freund, den ich im Forum kennengelernt habe, gibt es unter dem Sitz einen 4-poligen Stecker, der als ODB fungieren soll, aber ich habe ihn noch nicht getestet.