Nutzung größerer Zellkapazität mit original Renault-BMS

FlipFlop schrieb: Da hier im Paralellthread gefragt wurde, hier eine Info wie es aktuell steht. Ich habe für meinen Akku mittels etwas trial-and-error die Parameter für die Kapa im BMS höher gesetzt. Nun habe ich noch ein BMS von Saarlodrie und zwei weitere aus meinen weiteren Akkus hier auf dem Tisch. In der Datenbank vom DDT sind auch schreibkommandos dokumentiert, die allerdingt mit ddt4all nicht angenommen werden.
Es gibt auf mindestens drei softwareversionen, dort werden die Parameter anders gespeichert als bei meinem ersten akku und werden im Betrieb auf die Werkseinstellungen zurückgesetzt. Gemeinsam haben sie aber ihre Schnittstelle zum parametrisieren. Nun bin ich seit Mai daran, die für die diagnosekommandos über Can verantwortliche SW zu reversen, die das Schreiben der Parameter über OBDII verwalten. Leider ist das für diese anwendung wirklich komplexe software, mehrere 10.000 zeilen Code, inklusive Real-time-betriebssystem. Falls jemand in assembler fit ist und gern auch einen rauchenden kopf möchte, möge die Person sich bei mir melden (einblick im anhang). Vielleicht lassen sich dabei auch weitere unklarheiten in den CAN-Messages im Twizy lösen.

Which software u use?

Es sind mindestens 3 Fälle bekannt, in denen es gelungen ist, defekte BMS dadurch wiederzubeleben, dass die Firmware aus einem funktionierenden BMS ausgelesen und dann auf das defekte geschrieben wurde.
Ob dabei die unterschiedliche Softwareversionen berücksichtigt wurden kann ich nicht sagen, vermutlich aber nicht.

Meine Idee wäre folgendes:
Wenn dir das Kunststück des Softwaretransfer ebenfalls gelingen würde, dann wäre vorstellbar nach einem Zellentausch einfach nur die Firmware im BMS zu tauschen.
Dann müsstest du "nur" noch bei einer Version herausfinden, an welcher Stelle in der Datei der SOH und die Zellkapazität gespeichert ist und diese dann entsprechend ändern.
Wenn es hilfreich wäre, dann könnte das Forum in einer Crowdfunding Aktion ein fabrikneues Original-BMS finanzieren und dann dessen Software als Basis für alle anderen dienen.

Natürlich wäre es eleganter, wenn man das BMS über den OBDII konfigurieren könnte.
Aber wenn dieser andere Weg einfacher zu realisieren wäre, dann wäre das auch okay.
Schließlich ist das nur einmalig nach dem Zellentausch nötig.

On two identical versions of bms with different soh with the same charge, read the firmware and compare

Ich hatte vor ein paar Wochen mit Kenneth geschnackt, der hat viele Original BMS rumliegen und würde einige zu dem Thema spenden.

Sag mit was du brauchst und ich hau ihn an.

Wenn 3/4/5 von uns jeweils 5 euro Porto in den Hut schmeißen hilft es auch die Dinger aus Norwegen zu verschicken da evtl auch steuern anfallen koennten.

- Bitte keine Diskussion über das Steuer Thema anfangen -

Danke, BMSse habe ich wohl aktuell genug, möchte auch gerade keine Annehmen, da ich die ja dann wieder wegschippern müsste und es gefühlt ja nicht mehr so schwer sein kann. Habe in den letzten zwei wochen viele dutzend stunden vor Ghidra verbracht, bin in größer werdenden schritten weitergekommen und teste jetzt schon ein paar vermutungen mit dem Debugger aus.

BMS-Software einfach überspielen halte ich für weniger schlau, es sitzen 3 Prozessoren auf dem BMS, die sich untereinander verstehen müssen, und bei den Zellomnitor-Controllern habe ich keine ahnung wie deren Firmware aussieht und habe sie noch nicht gelesen/geschrieben.

I don't eat assembly like pizza, but why not?

Which software u use?

I will send over the Ghidra project using PM. I dont think i can publish the renault binaries for copyright reasons. Nice way to get into reversing with ghidra btw.

Rozhkov schrieb: On two identical versions of bms with different soh with the same charge, read the firmware and compare

Unfortunately, many more parameters than SOH change over time. There is extensive logging and history stored in the flash memory.

Falls mein BMS mit sturem 100% SOH zum auslesen gebrauchen kannst, sag bescheid

(ich möchte es nur irgendwann wieder zurück, man weiß ja nie )

Delvecchio schrieb: Do you mean the DDT based software or whatelse?
I also tried to write those bytes, both with DDT and directly via canbus, but my attempts wasn't successful, despite I tryed in all possible type of session.
I'm still convinced that finding a way to reuse the original BMS would be the preferable way at all.
A question: some posts earlier you wrote that also an hw modification was needed. Am I right?

Let me give some answers:

Yes the DDT4all software. It is obvious the BMS used in the Twizy is derived from a full grown distributed multi-Module BMS like in the zoe, and they just removed all unneccessary funtionality. Thats why there is often calls into software libraries just returning nothing, this functionality was removed compile-time with #ifdef or similar. See the similarities in the commands with X10 zoe definitions from the ECU.zip and the "forgotten" write commands in the X09 definitions. The write command I look to find may be another Command number, or, I think it may be a magic number/password you´d have to attach to the can message to get the write executed. I have found several functions checking some input against magic numbers in the flash mem like "12345678abcdef". To make progress, i want to do a debug session with obdII connected and the jtag debugger connected inside the twizy this weekend.
HW modification is needed if I use my current method: writing 0xffff to adress 30a4c, which was the number decreasing when i artificially depleated the SOH of a BMS. This value seems to refer to a SOH of around 127%. But I think we will do better with setting the Base capacity higher.

FlipFlop schrieb: ... or, I think it may be a magic number/password you´d have to attach to the can message to get the write executed.

This is my thought too, due to the expected payload length you can read in the X09 definitions.

I liebe es solche Beiträge zu lesen

Ich verstehe ganz grob folgendes: Ja, und, schreiben, wollen.

Cool

Boys you are such famous cracks.