My current tasks: a cheating device for the original BMS and an homemade BMS

I'm not used to make announcements without having something tested and ready.
This time I'll make an exception because I'm receiving many requests about my actual experiments.

I recently converted the batteries of my Twizy and my brother's.
Both now mount 14x 218Ah CALB cells.
So I had to reorganize my priorities, to make the new batteries working fine.

Cheating device:
Starting from a brilliant Bertold's idea and thanks to Snorre's intuition, I built a cheating device, to cheat the original BMS in order to use a bigger battery, without reserve canister effect (RKE) and SOH degradation influence.
The device has been around for about a year. It has been tested by two users, with uncertain results.
But after a great intuition by Snorre, I changed the firmware of the device, which I'm now testing in my Twizy.
The first results are very positive: I drove 109 kms (70 in highway with a speed of 50/67 km/h and the other in town), with a 78% SOH original BMS.
Now I have 4% SOC and 5 kms left shown on the dashboard.
So far, no reserve canister effect and no reduced power up to 5% SOC!
Of course, more tests are needed, but if they confirm that the device works, it will be a smart solution, because it will make it possible to use the original BMS with bigger battery (of course of the same chemistry as the original cell modules),
very simplifying any battery conversion project, which will no longer necessarily require an alternative BMS.
To be clear: nothing would have been possible without Bertold's idea (he isn't aware of this project) and Snorres's intuition and tests.
So all my thanks go to them.

Homemade BMS:
In my brother's Twizy, I'm testing an homemade BMS, based on dexter's vitual BMS API and Klaus's example.
I implemented some changes to the hardware, to support up to 16 cells, up to 8 temperature sensors and to use the original current sensor. A 16bit ADC was added to measure voltages and current flow more accurately, as well as a pre-assembled active balancer.
The BMS has been working since september 26th, and my brother's Twizy is running with it since october 6th.
I gradually fixed all the problems. Only a discrepancy in the SOC calculation remains, but I'll take a look at it soon.
All configuration parameters are now setted by code, but a BT comunications is already running for connecting to an android app.
The app is in early state of development at the moment: it only receives the value from the BMS, all the other is to be done.
The BMS is working fine!
Please note that none of this would have been possible without dexter's virtual BMS api, and Klaus's example.
So all my thanks go to them.

Now you know what is "boiling in my pot".
There is nothing more to know than what I've reported here, but if you have any questions please ask here, not privately.

Do not ask about the availability of the devices, because I have to complete all the tests first.
Everything will come in its own time!

Super
Ich habe einfach den mechanischen Weg gewählt: eine Busbar mit 80% des Querschnitts des "Hauptbusbars" geht am Stromsensor vorbei. Dadurch passt das auch. Super simpel und funktioniert. Leider nicht einstellbar auf das im BMS gespeicherte SOH.

Delvecchio schrieb: I'm not used to make announcements without having something tested and ready.

Doesn't matter at all, if this works, the whole community will worship you til hell freezes over!

@Jack-Lee
1000 Danke !!! Endlich hat jemand meinen Vorschlag realisiert.
Kam bis jetzt, wegen sehr vieler Baustellen mit höherer Priorität nicht dazu.

euver schrieb: @Jack-Lee
1000 Danke !!! Endlich hat jemand meinen Vorschlag realisiert.
Kam bis jetzt, wegen sehr vieler Baustellen mit höherer Priorität nicht dazu.

Meine Verständnisfrage... brutzeln dann 20% mehr Leistung durch den Sevcon weil das ganze System ja um 20% besch... mogelt wird?
Hält der das aus? Letztendlich verschweigen wir ja nicht nur dem BMS Verbrauch sondern ermöglichen ja auch um 20% höhere Ströme?

Oder lieg ich da völlig falsch?

Der Sevcon wird selber den Strom messen. Der Ist unverfälscht. Es wird nur das BMS beschummelt.

Im übrigen ….
Alle die den Twizy tunen, durch Änderung der Parameter im Sevcon, sind völlig schmerzfrei wenn durch den Sevcon 20% mehr Strom fließen.

Berthold schrieb: Der Sevcon wird selber den Strom messen. Der Ist unverfälscht. Es wird nur das BMS beschummelt.

Gefährliches Halbwissen?
Vermutung?
Wissen?

Die Ausführung wäre ja beschämend simpel aber ich möchte echt keinen Sevcon riskieren.

TwizyChrisy schrieb:

Berthold schrieb: Der Sevcon wird selber den Strom messen. Der Ist unverfälscht. Es wird nur das BMS beschummelt.

Gefährliches Halbwissen?
Vermutung?
Wissen?

Die Ausführung wäre ja beschämend simpel aber ich möchte echt keinen Sevcon riskieren.

Der Sevcon wird in zahreichen Aplikation one ein Twizy BMS betrieben. Die Entwickler wären dumm wenn sie Sevcon nicht intern überwachen würden. Da ich den Sevcon nicht selbst entwickelt habe ist es natürlich gefähliches Halbwissen.

Die Ausführung ist ja auch beschämend simpel. Wenn Jack-Lee jetzt schreibt das er das schon länger erfolgreich macht wäre es ja schön gewesen wenn er das mal öffentlich geschrieben hätte.

Aus dem sevcon manual. Kein stromsensor außerhalb vom sevcon nötig. Der stromsensor vom Akku müsste ja dauernd seine Werte per CAN an den sevcon senden, das käme für das schnelle regeln eh zu spät….

TwizyChrisy schrieb:

Berthold schrieb: Der Sevcon wird selber den Strom messen. Der Ist unverfälscht. Es wird nur das BMS beschummelt.

Die Ausführung wäre ja beschämend simpel aber ich möchte echt keinen Sevcon riskieren.

Ich vermute daß einige Leser nicht auf anhieb wissen um welche Idee es geht.

Hier ist die Zeichnung



Und hier ist die Diskusion von Juni 2023.

Klich mich

Berthold schrieb: Ich vermute daß einige Leser nicht aufhieb wissen um welche Idee es geht.

Right. I forgot to link it.
Anyway I suggest to be careful with this "bypass" approach.
I'm aware about Jack-Lee results, because never shared publicly, but bypassing also the reverse current flow (i.e. while charging or during recuperation), we experimented side effects to SOH value: gradual decreasing, without real reason.

Ich kann mir vorstellen das der Hack Auswirkungen auf den SOH hat , wenn er falsch dimensioniert ist. ( zu groß )
Denn….
Durch den Bypass fliest auch der Ladestrom. Wenn der Bypass zu groß ( zu niederohmig ist ) wird der gemesse Ladestom geringer.
Das BMS hat ja immer noch die 6kWH vom original Akku gespeichert. Wenn der gemessene Strom ( Ladung ) zu klein ist bildet das BMS aus den Verhältnis von gemessene Ladung und gespeicherten Wert (6kWH) den SOH.
Ist der gemessene Strom im Strang durch den Messring zu klein wird das als kleinerer Ladungshub gesehen der SoH folglich kleiner gerechnet. Tröstlich ist dabei, das der Akku nicht real schlechter wird sondern nur der angezeigte SoH Wert.
Ungünstig ist das die Programmierer nur einen sinkemden SoH vorgesehen haben. Daraus folgt die Konsequenz das wenn einmal der SoH wegen zu großem Bypass kleiner wurde es keinen Weg zurück gibt. Das wirkt sich nicht auf die Fahrleistung aus , nur auf die SoH Anzeige. Ist aber unschön.
Mann müsste den Bypass Strom also erst klein machen und dann größer bis der SoH minimal kleiner wird. Dann hat man den passenden Wert gefunden. Wer will aber den Akku zigmal ausbauen bis er den passenden Wert gefunden hat. Messen und rechnen geht auch aber wer hat schon die Möglichkeit im milli Ohm Bereich Fehlerfrei zu messen. Per Hardware die Änderung perfekt auszuführen kann daher sehr mühsam sein. Nimmt man es nicht so genau wird man den Bypass grob Dimensionieren und mit den Ergebnis einfach fahren.

Wenn Fabio nun einen weg findet den Stromwert den der Sensor misst zu manipulieren wird alles viel einfacher.
Man muss dann nur vorsichtig am Parameter drehen bis es passt. Doch auch hier gäbe kein zurück für den SOH wert.
Ganz entspannt wird es erst wenn wir wissen wie ein Reset am BMS ausgeführt werden kann. Dann macht man den Reset eben mehrmals bis die perfekte Größe für den Bypass sprich die Digitale Manipulation des Stromsensors gefunden ist.

Mal schauen wie sich das Projekt entwickelt. Es bleibt spannend.

Berthold schrieb: Wenn Fabio nun einen weg findet den Stromwert den der Sensor misst zu manipulieren wird alles viel einfachen.

Yes, you can enter the correct cheating factor in the device (there are 8x dip-switches for this task).
In this way you can set a precise value, calculated with a math formula which takes into account also the current stored SOH.

Anyway if the SOH value stored in the BMS decreases due to the bypass being not dimensioned with precision, I think there won't be only a problem of display: the BMS will think to have less efficient battery, and will react consequently decreasing the SOC prematurely, with a bigger reserve canister effect. This could generate a loop.
In our experiment, using an inaccurate cheating factor (too big), we reduced the SOH stored in the BMS from around 80% to 46% in a relatively short time. This is the reason I suggested to be careful.

Das BMS kann eigentlich nix. Das gibt nur Infos auf den CAN. Es steuert weder die Schütze, noch kann es irgendwas anderes als "Alarm!" schreien.
Das sorgt z.B. bei starkem Tuning dafür, das bei Vollstrom "STOP" aufleuchtet und der Twizy piept. Aber ändern tuts da nix. Der Sevcon arbeitet ansich vollkommen Autark. Die Ströme für Reku und Entladeströme gehen komplett über diesen. Hierdurch gibts auch ein kleines Problem...
Wenn man mit hoch gedrehter Reku fährt und der Akku sehr kalt ist, kann das diesen schaden. Ich habe zumindest keinen Eingriff des BMS auf den Sevcon gesehen, mit Ausnahme des "BMS Ok" Pin, welches den Antrieb deaktiviert.
Das Ladegerät schaut auch nur was das BMS erlaubt und richtet sich danach.

Also mit einem "Austricksen" des Stromsensors macht man ansich nix kaputt. Wenn man 10kWh verbaut hat und den gemessenen Strom um etwa 40% senkt, passt das ziemlich gut und auch der SOH bleibt an Ort und Stelle.
Habe noch nichts groß öffentlich gemacht, weil mehrere Akkus mit dem Kniff gerade in Erprobung sind.

Praktisch umgesetzt, bedeutet das :

3 x 16mm² Cu-Leiter gleicher Länge, an den Ende zusammen unter jeweils einen 50mm² Kabelschuhe gepresst.

oder

5 x 10mm² Cu-Leiter gleicher Länge, an den Ende zusammen unter jeweils einen
50mm ²Kabelschuhe gepresst.