SoH / Degration Berechnungstool

Zitat von GiMichael

Geht ihr davon aus, dass einer der beiden Werte gar nicht vom Steuergerät kommt, sondern künstlich im CarScanner erzeugt wird? Wenn das so ist, woran kann man denn erkennen, welcher der Werte wirklich aus einem der Steuergeräte kommt.

Exakt, aus den drei oben genannten Indizien ziehe ich genau den Schluss, dass auch der Carscanner den Wert SOC Display berechnet.

Warum der Entwickler das nicht dokumentiert hat, kann ich natürlich auch nicht sagen. Es wäre nett gewesen, einen entsprechenden Hinweis im Datenpunkt anzugeben.

Zitat von GiMichael

ichderarnd  Speicher Ich werte die Sensoren"[8C.BMS] Ladezustand Anzeige" und "[8C.BMS] Ladezustand Batteriemanagementsystem" aus. Ich dachte bisher beide kommen vom BMS Steuergerät (wobei ich keine Ahnung habe, ob dieses Steuergerät die Kennung 8C hat). Geht ihr davon aus, dass einer der beiden Werte gar nicht vom Steuergerät kommt, sondern künstlich im CarScanner erzeugt wird? Wenn das so ist, woran kann man denn erkennen, welcher der Werte wirklich aus einem der Steuergeräte kommt.

Es gibt aus meiner Sicht zumindest Indizien dafür, dass dieser Wert berechnet wird (wie es auch schon ichderarnd geschrieben hatte). Besonders merkwürdig für mich ist, dass der Wert 13 Nachkommastellen hat, SoC BMS aber mit nur einer Nachkommastelle auskommt (und dieser Wert, das wissen wir, hat eine PID und kommt vom Steuergerät).

Ich hatte mal den Entwickler vom carscanner wegen einiger Werte angeschrieben ob diese wirklich vom Auto kommen. Seine Antwort war...er lese alle Daten direkt vom OBD Adapter / Auto.

Die Frage aber ist, ob er nicht wie hier schon erwähnt Codefragmente von anderen Projekten übernommen hat, die bereits die Formel integriert haben.

Am Ende vom Tag sind die % SoC Werte beide nur berechnet auf Basis der Spannung der Batterie. Warum, um zurück zu meinem einleitenden Satz zu gehen, sollte VW/Skoda den SoC(HMI) auf 13 Stellen berechnen (der immer nur in vollen % gezeigt wird und bei dem es nicht auf maximale Präzision ankommt, da er nur informativ ist) aber den wesentlich wichtigeren SoC(BMS) auf nur eine Stelle nach dem Komma?

Für mich sieht das nach Re-Engineering aus der Community aus auf Basis von Messwerten aus oder evtl. ein Hinweis von jemanden, den jemanden kennt, der mal gesehen hat, wie jemand das implementiert hat beim Zulieferer oder wer auch immer das BMS geschrieben hat. Und ja, auch ich dachte immer der Wert kommt direkt vom Auto...jetzt bin ich skeptisch.

Wie gesagt, ich schaue am Dienstag mal ob ich mehr erfahre, da habe ich ohnehin einen längeren Call mit Skoda zu diversen Projekten

Ja, das BMS errechnet aus den Spannungen einen %-Wert SoC und kann dies eigentlich auch nur gut im unteren und oberen SoC-Bereich (oder bei min und max Spannung) abgleichen. Der Rest ist dann eine Interpolation. Das ist mir im Grunde schon klar.

Nur, wenn man jetzt gar nicht weiß, welche Daten sich der CarScanner zusammenreimt und was wirklich als echte Daten aus einem Steuergerät kommen, dann ist das natürlich sehr unbefriedigend. Dann kann man sich die ganze Excel-Berechnung im Grunde sparen. Womöglich berechnet man dann auf irgendwelchen CarScanner Umrechnungen sich etwas zusammen.

Zitat von GiMichael

und dann noch die Engergie in kWh

[19.Gate] maximaler Energiegehalt der Traktionsbatterie --> ichderarnd im Grunde der max(EnergiegehaltDerBatterie), den Du gesucht hast

Ich suche den maximalen Wert, denn der Datenpunkt "[19.Gate] Hochvoltbatterie Energiegehalt" haben kann. Ich habe das der Übersichtlichkeit halber max(EnergiegehaltDerBatterie) genannt.

Der Datenpunkt "[19.Gate] maximaler Energiegehalt der Traktionsbatterie" ist etwas anderes. Dieser Wert beinhaltet die Reserve unterhalb 0% SOC. Daher kann dieser nicht als Referenz für die 100% SOC Display herangezogen werden.

Zitat von GiMichael

Mir ist aber ein Rätsel, wo ich aus dem CarScanner erkennen soll, welche PID diese Werte haben sollen.

Tja, da kenn ich auch keine Lösung. Nur der Entwickler könnte dies dokumentieren. So, wie es jetzt ist, ist das in der Tat unschön.

Im von mir weiter oben genannten Logfile, das die Bluetooth-Kommunikation zwischen Handy und Dongle aufzeichnet, könnte man es sehen.

Da das Log praktisch nur Binärdaten enthält, ist das aber nicht so einfach...

Im evDash zumindest wurde die Formel am 01.12.2022 aktualisiert:

SocBMS × 1.10625 − 6.1947

leider auch hier ohne Angabe der Quelle

Updated SOC HMI for MEB cars · nickn17/evDash@e56c215

github.com

edit: gibt dazu ein Issue im repo. Die Formel scheint wohl auch nur aus der Linearfunktion diverser Messungen abgeleitet zu sein

HMI SoC is inaccurate on 45/55kwh ID.3 · Issue #50 · nickn17/evDash

This calculation seems to be inaccurate on the pure models. evDash/src/CarVWID3.cpp Line 315 in ad4c152 liveData->params.socPerc = liveData->params.socPercBms…

github.com

matze-pe Danke, dann wissen wir dass der Anzeigewert nur berechnet wird. Dieser Wert hat ja wirklich13 Stellen nach dem Komma und stimmt exakt mit er Formel BMS * 52 / 46 - 6,4 überein. OBDeleven und VCDS habe ich nicht. Da ich nichts schreiben wollte, habe ich da nie etwas geholt.

Zitat von GiMichael

matze-pe Danke, dann wissen wir dass der Anzeigewert nur berechnet wird. Dieser Wert hat ja wirklich13 Stellen nach dem Komma und stimmt exakt mit er Formel BMS * 52 / 46 - 6,4 überein.

dann muss der Wert ja von Carscanner berechnet werden.

Ich kann mir irgendwie nicht vorstellen, dass der Entwickler von Carscanner, einem OBD-Tool für alle möglichen Fz, diesen einen Wert für eine bestimmte E-Fz-Gruppe berechnet.

Ich bin da noch dran, hatte gestern einen ersten sehr guten Austausch zum Thema mit Skoda.

Die Formel für den SoC(HMI), die wir haben ist jedenfalls nicht korrekt bzw. wirklich ein "re-engineering" der Community und er wird nicht via OBD zur Verfügung gestellt. Via OBD ist nur SOC(BMS) verfügbar als direkter Wert.

Sie haben mir die interne Formel gezeigt, die wirklich genutzt wird. Aber die ist nicht selbsterklärend, weil sie dort sehr viele Variablen einfliessen lassen.

Im Kern haben sie ein Set an Variablen, die sie "Distortions" nennen, also Verzerrungen die auftreten und den "idealen" SoC stören (wie beispielsweise Temperatur).

Zudem gibt es Unterschiede in der Berechnung zwischen den SW3 ENYAQ und den UNECE (SW4) ENYAQ. UNECE ENYAQ haben eine niedrigere untere Reserve als die SW3 ENYAQ und somit generell etwas mehr EC zur Nutzung freigegeben.

Hier lag ein Kommunikationsfehler vor, der durch "Stille Post" im vorherigen E-Mails entstanden ist und im Gespräch bereinigt werden konnte.

Somit stimmt das von mir geschriebene nicht ganz, also mit den harten Grenzen von -2.5 und +2.5 kWh und der zusätzlichen -1.1 kWh und wir haben zurecht erkannt, dass hier was nicht aufgeht.

Jedenfalls erklärt das alles meine Werte die ich hier geschrieben habe sehr gut und auch warum bei UNECE ENYAQ die EC und MEC Werte im Neuzustand leicht höher sind.

Aber es ist Zurückhaltung zu spüren, da Skoda "weiss" warum ich das alles wissen will und das wir ein "community-SOH" Tool bauen (was sie als OEM nicht unterstützen können/wollen).

Habe morgen nochmals einen Austausch zum Thema. Mal sehen wo wir enden.

Bin zuversichtlich, dass wir am Ende ein Ergebnis haben das allen hilft, die daran Interesse haben.

Speicher super danke. Das hört sich richtig gut an. Dann wird vieles verständlicher. Mir gefallen die Störungen. Die Welt ist eben doch komplexer. Natürlich auch bei dem was von VE freigegeben wird. Klar wollen sie nicht alles preisgeben. Sehr verständlich.

Ich freue mich drauf was du rausfindest und sagen darfst.