Berechnung SoH mit anderen Messwerten

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • Bei mir will ODIS nicht wirklich, leider. Hab mir einiges an Screenshots gemacht von paar Sachen, muss ich nachher noch auswerten... Bei Zählerüberlauf kam 3A15 raus. z.z. SoC 51.6% laut ODIS
      Demnach wäre ich bei 89.789% SoH, sofern ich mich nicht verrechnet hab.
      eGolf 300 07/2020 WP ACC LaneAssist LightAssist
      Skoda Kodiaq MJ2020 190TDi 4x4 ACC LaneAssist LightAssist 7Sitze und bisschen mehr...
    • NCM622 schrieb:

      Pogo schrieb:

      Das was ich hier geschrieben habe ist die Vorgehensweise von dem Prüfschritt Batteriekapazität 2.0 aus Odis Service. Ich habe quasi die Programmierung gelesen und gesehen welche Werte abgefragt werden. Warum und wieso das so gemacht wird, kann ich leider nicht beantworten. Ich kann nur soviel sagen, dass diese Vorgehensweise auch bei Garantieansprüchen durchgeführt wird.
      Das ist interessant zu wissen ich werde das, sobald ich die Zeit dazu habe, mal mit der im vorigen Beitrag beschriebenen Methode die ich in OBD Amigos verwende vergleichen um zu sehen ob da letztendlich trotzdem der gleiche SOH rauskommt.
      Übrigens, ich sehe auf deinem Screenshot auch die Werte "DC geladene Energie" und die drei Standzeit Werte, kannst du herausfinden wie die ermittelt werden?
      Vor allen "DC geladene Energie" habe ich lange erfolglos gesucht, den Wert würde ich gerne in OBD Amigos einbauen.
      Die DC geladenen Energie findest du in den Historiendaten 18 Parameter 7 in Wh.
    • Pogo schrieb:

      Man kann sich viel schönreden, wenn man nicht weiß, was wofür steht. Odis würde jedenfalls auf Basis deiner Werte kein Zertifikat erstellen.

      [*]War das Ergebnis gültig, dann errechnet sich der SoH wie folgt: SoH% = Messwert HVBHD1 /111
      [/list]
      Um 100% SoH zu bekommen muss x * 111 = 11.100 ergeben. Das setzt voraus, dass 111 eine Zahl im Dezimalsystem ist. Wenn die odb11 den Meßwert HVBHD1 als Hexadezimalzahl ausgibt, kann Deine Formel kein richtiges Ergebnis liefern. Wäre es eine Hexadezimale Zahl könnte Deine Formel nie einen größeren SoH als 40% ergeben. Entweder ist Deine Formel nicht korrekt, oder man muß die HVBHD1 in Dezimal konvertieren.
      Was ODIS an der Oberfläche zeigt, aber intern rechnet, weißt Du doch nicht, oder?

      Chris
    • Dia schrieb:

      Pogo schrieb:

      Man kann sich viel schönreden, wenn man nicht weiß, was wofür steht. Odis würde jedenfalls auf Basis deiner Werte kein Zertifikat erstellen.

      [*]War das Ergebnis gültig, dann errechnet sich der SoH wie folgt: SoH% = Messwert HVBHD1 /111

      Um 100% SoH zu bekommen muss x * 111 = 11.100 ergeben. Das setzt voraus, dass 111 eine Zahl im Dezimalsystem ist. Wenn die odb11 den Meßwert HVBHD1 als Hexadezimalzahl ausgibt, kann Deine Formel kein richtiges Ergebnis liefern. Wäre es eine Hexadezimale Zahl könnte Deine Formel nie einen größeren SoH als 40% ergeben. Entweder ist Deine Formel nicht korrekt, oder man muß die HVBHD1 in Dezimal konvertieren.Was ODIS an der Oberfläche zeigt, aber intern rechnet, weißt Du doch nicht, oder?

      Chris
      Ich sehe jeden Schritt den ODIS rechnet, aber Asche auf mein Haupt. Du hast natürlich recht.

      Das Missverständnis ist dadurch entstanden dass ODIS-Service die Werte gleich in Dezimal übergibt aber ODIS-Engineering in Hex.

      Meiner spuckt 2666 in Hex aus und hat damit ca 89% SoH.
    • cool :thumbup:

      Die Variante 2 scheint mir dann also ganz gute SoH Werte zu liefern. Falls es noch jemand schafft mit odb11 den Zähler auszulesen, würd ich das auch noch testen. Ich habe die 4 Sessions Modes durchprobiert. Steht aber nur "nicht verfügbar" in dem Datenfeld.

      Ich habe mit 76%, 100% und 92% SoC probiert. Hat der SoC eigentlich eine Auswirkung auf die Werte in den Historiendaten?

      Chris.
    • Ja, die zweite Variante stimmt auf jeden Fall, ich habe eine Menge Logs mit Rohdaten von den Historiendaten von verschiedenen Autos (e-Golf, e-up, Mii electric, Citigoe ist alles dabei) die mir von OBD Amigos Benutzern zur Verfügung gestellt wurden und alle Daten die ich bisher überprüft habe (bisher nur ein kleiner Teil denn das händische überprüfen ist zeitaufwendig) liefern einen plausiblen SOH und stimmen mit dem SOH überein den OBD Amigos berechnet (durch Auswahl des Zellenpaars mit der geringsten Kapazität).

      Allerdings muss man beachten das 111 nur für den eGolf 300 gilt, beim e-up 18,7 muß man stattdessen 50 verwenden, beim eGolf 190 muss man 75 verwenden und bei den Drillingen (e-up mit großem Akku, mii, citgoe) 120.
      Die Zahl repräsentiert die nominelle Ah Kapazität eines Zellpaares/triplet.

      Zur ersten Variante: die scheint auch zu funktionieren allerdings liefert sie bei den wenigen Fällen wo ich sie überprüfen konnte einen deutlich niedrigeren SOH als die zweite Variante.
      @Pogo kannst du uns sagen in welchen Zusammenhang die erste Variante von ODIS verwendet wird?
      Irgendwie verstehe ich denn Sinn dieser Variante nicht da die Werte zu niedrig erscheinen.
    • NCM622 schrieb:

      Ja, die zweite Variante stimmt auf jeden Fall, ich habe eine Menge Logs mit Rohdaten von den Historiendaten von verschiedenen Autos (e-Golf, e-up, Mii electric, Citigoe ist alles dabei) die mir von OBD Amigos Benutzern zur Verfügung gestellt wurden und alle Daten die ich bisher überprüft habe (bisher nur ein kleiner Teil denn das händische überprüfen ist zeitaufwendig) liefern einen plausiblen SOH und stimmen mit dem SOH überein den OBD Amigos berechnet (durch Auswahl des Zellenpaars mit der geringsten Kapazität).

      Allerdings muss man beachten das 111 nur für den eGolf 300 gilt, beim e-up 18,7 muß man stattdessen 50 verwenden, beim eGolf 190 muss man 75 verwenden und bei den Drillingen (e-up mit großem Akku, mii, citgoe) 120.
      Die Zahl repräsentiert die nominelle Ah Kapazität eines Zellpaares/triplet.

      Zur ersten Variante: die scheint auch zu funktionieren allerdings liefert sie bei den wenigen Fällen wo ich sie überprüfen konnte einen deutlich niedrigeren SOH als die zweite Variante.
      @Pogo kannst du uns sagen in welchen Zusammenhang die erste Variante von ODIS verwendet wird?
      Irgendwie verstehe ich denn Sinn dieser Variante nicht da die Werte zu niedrig erscheinen.
      Die erste Variante läuft im gleichen Prüfprogramm wie die zweite Variante. Ich guck mal nach, ob das Programm bei plausiblen Werten der ersten Variante beendet wird, sodass bei unplausiblen Werten erst die 2te Variante zur Anwendung kommt.
    • merlin99 schrieb:

      @NCM622 sag mal, wenn ich die Daten über VCDS rausexportieren würde (CSV o.Ä), wäre es möglich in OBD Amigos ein "import" zu machen und dann darstellen? bzw. ist Dir bekannt das man an die nötigen Daten nicht über VCDS rankommt?
      Nein das ist leider nicht möglich, OBD Amigos kann zwar seit kurzem auch Daten als CSV exportieren aber importieren ist nicht vorgesehen und wäre auch nicht so einfach zu implementieren, sorry.

      Ich habe VCDS und OBDeleven nie selbst benutzt aber soweit ich gehört habe werden die Historiendaten weder von VCDS noch von OBDeleven irgendwie aufgearbeitet dargestellt so wie ich das in OBD Amigos implementiert habe.
      Ich denke das nicht einmal ODIS die Kapazitäten der einzelnen Zellpaare/triples anzeigt die in Historiendaten14 enthalten sind, oder doch @Pogo (eventuell ODIS engineering)?

      Ganz nebenbei, Historiendaten15 ist auch interessant, da es die durchschnittlichen Ah Kapazitäten der einzelnen Zellblöcke fortlaufend alle 3 Monate ab Herstellungsdatum abspeichert. Allerdings hat dieser PID nur Speicherplatz für ca. 11 Jahre, ich weiß nicht was danach passiert, so einen alten e-up oder e-Golf gibt es bis jetzt noch nicht (obwohl die ersten e-ups bald so alt sein werden).

      Hier ist ein Beispiel Screenshot von OBD Amigos der Historiendaten15 von einem e-up aus 2014 der anfänglich längere Zeit stillstand (und auch wieder im Frühjahr 2020, den Grund dafür kann wohl jeder erraten ;) ) :

    • Über ODIS kann man so manches wie ich heut gesehen hab rauslesen, und ich hab n altes Exemplar... In VCDS würde ich meinen kriegt man die selben Daten raus, muss man nur richtig addressieren in der Anfrage in de Tool.

      Kein Problem NCM, sowieso werde ich lieber nicht mehr nachrechnen da ich sonst Bauchschmerzen krieg:)
      Nach dieser Formel
      "(("Gemessene Kapazität in Wh" / "Ladezustand in %") * 100) / (31500 Wh / 100) = SoH in %"
      , hatte ich im September 97%, jetzt bin ich nach der Formel bei 83% was noch schlimmer ist als über die Formel#1 in diesem Thread (89%)... Ja ich wurde gewarnt das es mit Temperatur zu Unterschieden kommen wird :)
      eGolf 300 07/2020 WP ACC LaneAssist LightAssist
      Skoda Kodiaq MJ2020 190TDi 4x4 ACC LaneAssist LightAssist 7Sitze und bisschen mehr...
    • Pogo schrieb:

      Die erste Variante läuft im gleichen Prüfprogramm wie die zweite Variante. Ich guck mal nach, ob das Programm bei plausiblen Werten der ersten Variante beendet wird, sodass bei unplausiblen Werten erst die 2te Variante zur Anwendung kommt.
      Da ich den PID der den SOH der ersten Variante liefert schon seit knapp 2 Jahren logge (obwohl ich nicht wußte was der Wert bedeutete), hab ich mir die Logs jetzt mal genau angeschaut und herausgefunden das der PID zumindest bei meinem CItigoe nur zwischen Mai und Anfang September gültige Werte enthält. Das war sowohl 2022 als auch dieses Jahr so, im Rest des Jahres enthält der PID immer den Wert 65534 (FF FE hex).

      Über das warum können wir nur spekulieren, möglicherweise enthält der Wert nur einen SOH wenn die Akku- oder Umgebungstemperatur über einen bestimmten Durchschnittswert liegt (ein SOH sollte ja idealerweise bei mindestens 20-25 Grad ermittelt werden), oder es liegt daran das ich die letzten zwei Jahre jedes Jahr zwischen Mai und ende August mehrfach den Akku bis auf 2 oder 3% entleert habe und dann wieder bis 100% aufgeladen habe, d.h möglicherweise bildet das BMS diesen SOH nur nach einem (fast) vollständigen Ladevorgang.
      Sonst fällt mir nichts weiter ein was ich in den Monaten Mai bis September anders mache als im Rest des Jahres.

      Ich denke ODIS gibt darüber keine Auskunft unter welchen Umständen dieser SOH der ersten Variante gebildet wird, oder?
    • Nun kann ich auch über Amigos mitmessen;-) Danke an NCM, da er von heut auf morgen einen Weg gefunden hat mein OBD Wifi ELM327 anzubinden über Linux & dann Amigos. Kann er in die Liste seiner Dongles die gehen hinzufügen:)

      Werte muss ich mir noch nachher anschauen, da z.z. aber Messung bei 13 Grad und SoC42% war SoH 89%, hoffe wird im Sommer mit 20-25Grad dann auch wieder vernünftiger...
      eGolf 300 07/2020 WP ACC LaneAssist LightAssist
      Skoda Kodiaq MJ2020 190TDi 4x4 ACC LaneAssist LightAssist 7Sitze und bisschen mehr...
    • Pogo schrieb:


      • den Wert multipliziert ihr mit 0,01. Ist das Ergebnis <= 88,8 dann habt ihr keinen gültigen Messwert
      • War das Ergebnis gültig, dann errechnet sich der SoH wie folgt: SoH% = Messwert HVBHD1 /111

      Mir ist aufgefallen das dieser Gültigkeitstest der zweiten Variante sämtliche Werte verwirft die einen SOH unter 80% ergeben würden, was meiner Meinung nach keinen Sinn ergibt denn ein SOH von unter 80% ist ja nun nicht so unwahrscheinlich sobald das Auto älter ist und eventuell schon ein paar hunderttausend km gefahren ist. Auch die Akkugarantie garantiert ja nur mindestens 70% also sollte der Wert doch mindestens bis 70% erlauben.
      Ist dieser Gültigkeitstest wirklich so wie beschrieben?

      Ganz nebenbei, für die Programmierer unter uns:
      Spoiler anzeigen
      hier ein Beispiel warum ich Perl liebe und warum OBD Amigos in Perl geschrieben ist, so einfach geht der Gültigkeitstest und die Berechnung der ersten Variante des SOH in Perl:

      Quellcode

      1. $SOH=U16(V1,V2)~~[14162..14949]?sprintf("%.1f", (U16(V1,V2)-14162)*0.127):"N/A";

      Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von NCM622 ()

    • NCM622 schrieb:

      Pogo schrieb:


      • den Wert multipliziert ihr mit 0,01. Ist das Ergebnis <= 88,8 dann habt ihr keinen gültigen Messwert
      • War das Ergebnis gültig, dann errechnet sich der SoH wie folgt: SoH% = Messwert HVBHD1 /111

      Mir ist aufgefallen das dieser Gültigkeitstest der zweiten Variante sämtliche Werte verwirft die einen SOH unter 80% ergeben würden, was meiner Meinung nach keinen Sinn ergibt denn ein SOH von unter 80% ist ja nun nicht so unwahrscheinlich sobald das Auto älter ist und eventuell schon ein paar hunderttausend km gefahren ist. Auch die Akkugarantie garantiert ja nur mindestens 70% also sollte der Wert doch mindestens bis 70% erlauben.Ist dieser Gültigkeitstest wirklich so wie beschrieben?

      Ganz nebenbei, für die Programmierer unter uns:
      Spoiler anzeigen
      hier ein Beispiel warum ich Perl liebe und warum OBD Amigos in Perl geschrieben ist, so einfach geht der Gültigkeitstest und die Berechnung der ersten Variante des SOH in Perl:

      Quellcode

      1. $SOH=U16(V1,V2)~~[14162..14949]?sprintf("%.1f", (U16(V1,V2)-14162)*0.127):"N/A";

      Das ist korrekt so. Unter 80% wird bei diesem Test nichts ausgegeben. Für die Bewertung des SoHs für den Garantiefall ist der Ablauf etwas anders. Dazu muss der SoC kleiner 10% sein. Danach soll auf 100% geladen werden. Dann 30 min warten und nochmal auslesen. Gewisse Temperaturen müssen auch noch eingehalten werden. Habe das jetzt aus meiner Erinnerung geschrieben. Kann sein, dass ich noch was vergessen habe.
      Ich glaube bald, dass die Amigos die Werte Beschreibung auch vom Entwickler haben.
    • Mit OBD Amigos war ich bei 89%SoH bei 100%SoC, durch die gängige Rechnung hier im Forum ((26900/92,8)*100/315=92,02% SoH und SoC92.8%
      Sind zwar nur 3% aber wie kommt es zu der Abweichung?

      Was ich noch interessant finde ist: bei mir ist in den Historiedaten über Amigos ein Ah-Wert von 110 als Maximum. Bei NCM ging es sogar bis 115Ah nach oben. kann es sein, das mein HV-Akku von Anfang n bisschen schwächer war, den Daten nach? z.z. dann auf 106
      eGolf 300 07/2020 WP ACC LaneAssist LightAssist
      Skoda Kodiaq MJ2020 190TDi 4x4 ACC LaneAssist LightAssist 7Sitze und bisschen mehr...
    • Die Daten (vorhandene kWh und SOH) stimmen laut meinen Beobachtungen selten genau überein, warum das so ist weiß wohl nur VW (die Daten kommen ja von den Steuergeräten, OBD Amigos liest sie nur aus), ich vermute das sind einfach voneinander unabhängige Schätzungen der Steuergeräte, letztlich sind die Werte ja alles Schätzungen der Steuergeräte, das einzige was wirklich gemessen werden kann sind die kWh die in den Akku fließen und die die aus dem Akku wieder rausfließen, der Inhalt des Akkus kann aber nur geschätzt werden.

      Im Screenshot von ODIS hier auf der ersten Seite in diesem Thread schreibt VW selbst das der angegebene SOH von der tatsächlichen Restkapazität sogar bis zu 10% abweichen kann.


      merlin99 schrieb:

      Was ich noch interessant finde ist: bei mir ist in den Historiedaten über Amigos ein Ah-Wert von 110 als Maximum. Bei NCM ging es sogar bis 115Ah nach oben. kann es sein, das mein HV-Akku von Anfang n bisschen schwächer war, den Daten nach? z.z. dann auf 106

      Nein das liegt daran das ich einen Skoda Citigoe (baugleich mit VW e-up) habe und du einen e-Golf, die Zellkapazitäten zwischen den beiden unterscheiden sich, mein CItigoe hat nominell 120Ah, dein eGolf 111 Ah.