Analyse eines zehn Jahre alten 68+ Akkus

[KB19]

Zu mir kam kürzlich ein 68+ Akku aus dem Forum, angeblich original (Sanyo) und mit Produktionsdatum 2015/12, Zustand unbekannt. Diese Story möchte ich gerne mit euch teilen, weil es viel zu schade wäre, wenn ich das nur für mich protokolliert und grafisch aufbereitet hätte.

Rein optisch deutet nichts auf eine Fälschung hin: Die Verarbeitung ist einwandfrei, das Gewicht passt laut Waage halbwegs, das Label stimmt und es gibt keine Unstimmigkeiten.

Also rein ins T450s (BIOS 1.37 / ECP 1.04) mit Linux! Das sah zuerst einmal überhaupt nicht gut aus: ~8V (!) und keinerlei Daten über Hersteller/Modellnummer/Akkutechnologie. Das sieht stark nach tiefentladen o.ä. aus



Lustigerweise fing er aber sofort zu laden an. Zwar nur im einstelligen Wattbereich, aber das kennt man ja. Nach wenigen Minuten habe ich ihn rausgezogen und nochmals neu eingeschoben. Nun wusste er plötzlich, wer er ist und auch alle übermittelten Details inkl. Hersteller und FRU passten zum Label!



(Warum bei diesem Screenshot beim Netzstrom "nicht angeschlossen" steht, dürft ihr mich nicht fragen. Wahrscheinlich ein veralteter Wert von kurz zuvor.)

Mit der Hilfe von ectool habe ich dann den Cycle Count ausgelesen, der bei dieser ThinkPad-Generation offiziell über ACPI gar nicht unterstützt wird. Und dort stand 0!

Da ich dem Braten nicht ganz getraut habe, wurde ab jetzt fein säuberlich (fast) alles protokolliert. Leider nur fast, denn ich habe in der Hektik die Spannungswerte vergessen. Glücklicherweise waren diese aber durch zahlreiche Screenshots noch halbwegs rekonstruierbar, wobei mir bei der Extraktion aus dutzenden PNGs eine KI geholfen hat. Die Volt aus der nachfolgenden Grafik sind also mit Vorsicht zu genießen, ich habe sie nur stichprobenartig kontrolliert.



Was sehen wir in dieser Grafik?

• Ich habe dem Akku zwischendurch zwei Mal eine längere Abkühlphase verpasst, indem ich das Charge-Behaviour manuell auf "Inhibit-Charge" gesetzt habe. Denn der EC gab nach nur wenigen Minuten die vollen >30W zum Laden frei, das war mir mit diesem mysteriösen Start nicht ganz geheuer.
• Der Wh-Zähler im BMS machte zu Beginn gar nichts, er verharrte stur auf 0Wh. Erst nachdem die minimale Designspannung (10,8V) erreicht wurde, begann er mitzuzählen. Das war erst nach grob einer halben Stunde, in der er bereits die ganze Zeit an ~30W nuckelte.
• In den Erholungsphasen ("Inhibit-Charge") reduzierte sich die Spannung und stieg wieder an, als geladen wurde. Das ist genau das, was man erwarten würde. Die gelieferten Spannungswerte scheinen also keine Fantasiewerte zu sein, egal woher sie kommen.
• Ungefähr ab der Hälfte der Designkapazität ging es schlagartig nur noch mit ca. 20W weiter. Dennoch folgt danach eine leicht ansteigende Kurve. Erst ab ungefähr 70% wurde die Ladeleistung kontinuierlich gedrosselt, wie man es von Ladevorgängen kennt.
• Ganz Ende gab es mehrmals ein Ping-Pong zwischen Laden und nicht Laden. Die Spannung bewegte sich dabei knapp unter der Ladeschlussspannung von 12,6V. Irgendwann sah der EC (oder das BMS) es wohl doch ein, dass das nicht mehr viel bringt.
• Als der Akku schlussendlich auf "Full" wechselte, sprang der Wh-Zähler plötzlich auf jenen Wert, der als maximale Kapazität hinterlegt war. Das war wohlgemerkt bereits deutlich über der Designkapazität. Ob das jetzt daher kommt, dass er durch die ersten 30 Minuten verwirrt war, weiß ich nicht. Ein vergleichbares Verhalten habe ich aber auch schon bei anderen Lenovo Akkus gesehen.

Nach der Ladung kommt die Entladung als "Force-Discharge" (für eine Rekalibrierung): Diese habe ich aus Zeitgründen aber auf drei Sessions aufgeteilt…



Zur Erklärung bzw. Einordnung:

• In der ersten Session gab es quasi Vollauslastung für CPU und größtenteils auch für die GPU. Also Worst-Case für den armen 68+ Akku.
• In der zweiten Session wurde YouTube gestreamt, schön über WLAN und mit Bluetooth-Kopfhörern. Und es gab ein paar kurze Pausen.
• In der dritten Session wurde Big Buck Bunny (Offline MP4) in einer Endlosschleife abgespielt.

Das offenbarte keinerlei Probleme, der Akku performte absolut problemlos und hatte keinerlei Einbrüche oder sonstige Auffälligkeiten.

(Warum kurz vor der 3h Marke für ca. eine Minute lang eine Leistung von 0W sichtbar ist, weiß ich nicht. Laut Protokoll wurde das über ACPI genau so von der Firmware gemeldet, das ist kein Fehler in der Grafik!)

Es folgte, was zu einer Rekalibrierung nun einmal dazu gehört: Ein vollständiger Ladezyklus von 0% auf 100%!



Was sehen wir hier, besonders im Vergleich zum allerersten Ladevorgang?

• Der Wh-Zähler des BMS zählte diesmal von Beginn an sofort mit, obwohl wir uns erneut unter der minimalen Designspannung bewegt haben.
• Ungefähr ab der Hälfte wurde auch jetzt wieder der Ladestrom schlagartig drastisch reduziert. Scheinbar stoppt der EC die Ladung dabei für wenige Sekunden komplett, um sie wieder neu hochzufahren. Das hat meine 5-sekündige Protokollschleife wohl zufällig eingefangen.
• Ansonsten sehe ich da als Laie keine besonderen Auffälligkeiten. Die Ladekurve sieht genau so aus, wie man sie erwarten würde. Am Ende gab es wohl wieder ein längeres Ping-Pong mit Laden und nicht Laden, aber das kennen wir ja schon.

Zu meiner Überraschung wurde nach einem erneuten Cold Start die maximale Kapazität nicht nach unten korrigiert, ganz im Gegenteil.

Gut, weiter geht's mit zwei weiteren Entlade-Sessions…



Im Gegensatz zur allerersten Entladung, wurde jetzt auf den gleichmäßigen Idle-Verbrauch des T450s gesetzt. WLAN/BT/usw. waren aus, damit es möglichst zu keinen Spitzen z.B. durch die Suche nach Updates kommt. Die kleinen sichtbaren Peaks sind nur meine manuelle Bedienung z.B. durchs Bewegen der Maus oder einem kurzen Check im Terminal, ob eh noch alles läuft. Der Bildschirm blieb Dank dem Präsentationsmodus dauerhaft an!

Ich persönlich sehe da keinerlei Auffälligkeiten. Der Akku zeigte sich von seiner besten Seite und das ThinkPad kitzelte rein rechnerisch problemlos mehr als ~65Wh aus dem Akku heraus. Da es diesmal kein "Force-Discharge" war, stoppte die Entladung bei ungefähr 5% und das System wechselte auf den internen Akku. Wir sprechen hier von fast zehn Stunden Idle-Runtime, inkl. zwei vollständigen Bootvorgängen, rein durch den externen Akku.

Nach dem erneuten Laden (diesmal ohne Protokollierung) korrigierte das BMS die maximale Kapazität sogar nochmals geringfügig nach oben auf sagenhafte 77Wh, was 108% Kapazität entspricht!

Persönliches Zwischenfazit: Ich habe schon öfters sehr gute Ergebnisse gesehen, wenn ThinkPad-Akkus lange gelagert wurden. Besonders ein anderer Sanyo-Akku war diesbezüglich auch unglaublich gut. Ich glaube es zwar noch immer nicht ganz, dass das wirklich Zellen aus 2015 sind, aber sofern hier nicht wirklich qualitativ hochwertiges Recelling betrieben wurde, habe ich aktuell keinen Grund, an der Echtheit dieses Akkus zu zweifeln. Wenn diese Performance so bleibt, war das ein Glücksgriff, kurz bevor der Akku endgültig Schrott gewesen wäre. Ihr dürft meine Panik bezüglich einer Fälschung aber gerne weiter befeuern. Ich werde diesen Thread in einigen Monaten nach weiteren Ladezyklen nochmals aktualisieren. Der über den EC RAM abgerufene Cycle Count Wert wurde übrigens korrekt erhöht, der blieb nicht auf 0 stehen.



Disclaimer: Dieser Beitrag wurde ohne KI geschrieben. Bei der Generierung der gnuplot-Grafiken sowie beim Extrahieren der Spannungswerte des 1. Ladevorgangs hat aber eine KI mitgeholfen. Ich habe trotzdem alles mehrfach manuell kontrolliert, an die verwendeten Rohdaten der Protokolle habe ich die KI sowieso nicht rangelassen.

PS: Diese Grafiken dürfen gerne beliebig weiterverwendet werden. Ein kurzer Backlink zu diesem Thread wäre allerdings wünschenswert.

 

[linrunner]

Wie hast Du protokolliert?

 

[KB19]

Wie hast Du protokolliert?

Beim allerersten Ladevorgang leider "nur" die TLP-Stat-Ausgabe in einer Schleife, deshalb fehlte auch die Spannung.

Danach ungefähr so, aus dem Kopf heraus: while true; do date; grep -H . /sys/class/power_supply/*/* 2>/dev/null; sleep 5; echo; done | tee -a log.txt

Wenn ich es nochmals machen müsste, würde ich z.B. gleich ein besseres Datumsformat oder UNIX-Timestamps verwenden. Ursprünglich sollte das nur ein schnelles Protokoll für mich werden, ich hatte nicht vor das zu visualisieren oder zu veröffentlichen. Dieser Plan bzw. Wunsch kam erst deutlich später…

Diese Datei habe ich dann mit ein wenig bash/awk Voodoo (und der Hilfe der KI) so zerlegt, dass ich sie an gnuplot verfüttern konnte. Die exakten Timestamps wurden dabei beibehalten, es wurde nicht stur auf das 5 Sekunden Interval vertraut. Dieses blinde Vertrauen sorgte durch das Delay der Befehlsausführung ursprünglich nämlich für ein paar Fehler in der Grafik. Aber genau deswegen sollte man der KI nicht blind vertrauen und selber das Hirn einschalten.

Beitrag automatisch zusammengeführt: 14 Juni 2026

Ich merke übrigens erst jetzt, dass mir bei der ersten Entladung ("Force-Discharge") ein Fehler unterlaufen ist: Das waren drei Sessions und die dritte fehlt in der Grafik!

Wird später oder morgen behoben, in den Rohdaten ist zum Glück alles vorhanden. Das kommt davon, wenn man dis1/dis2 kurz vor dem Posting nochmals optisch angleicht.

EDIT: Korrigiert, es sind nun alle drei Sessions vom ersten Entladevorgang sichtbar. Also komplett bis 0Wh runter…

 

[Schwartz]

Danke, sehr interessant. Meine Vermutung wäre schlicht, dass durch eine längere Lagerung die Elektronik ihre Werte nicht mehr richtig gespeichert hatte. Ging der Cycle Count jetzt in den einstelligen Bereich oder hat er sich wieder "erinnert"?

 

[KB19]

Meine Vermutung wäre schlicht, dass durch eine längere Lagerung die Elektronik ihre Werte nicht mehr richtig gespeichert hatte.

Vielleicht ging das BMS bzw. der dazugehörende Kommunikations-Chip aufgrund der niedrigen Spannung auch in einen speziellen Tiefschlaf, um einer drohenden Tiefentladung entgegen zu wirken? Als der EC beim Anstecken dann die Werte ausgelesen hat, war das BMS noch halb im Tiefschlaf und antwortete nicht (korrekt) oder nicht schnell genug. Der EC wird die statischen Werte ja bestimmt nur einmal abfragen und danach zwischenspeichern. Entweder antwortete der Akku später erst durch die geringfügig höhere Spannung korrekt oder wir sehen hier eine seltene Race Condition. Ich habe von Akkus aber zu wenig Ahnung, um das technisch zu beurteilen. Das sind somit reine Vermutungen von mir!

Ging der Cycle Count jetzt in den einstelligen Bereich oder hat er sich wieder "erinnert"?

Definitiv einstellig, er ist jetzt korrekterweise auf 3. Oder halt 2, weil die dritte Ladung durch die Ladeschwellen nur bis ~80% ging.

(Ich bin mir gerade nicht ganz sicher ob 2 oder 3 und tippe nur am Handy. Ich kann in den nächsten Tagen aber nochmals nachsehen.)

[EDIT] Nach den ersten zwei Full-Charges war er jedenfalls auf 2. (16bit Register 0xa4 auf Page 0x11: Vorher/Nachher)

 

[karlK]

Also rein ins T450s (BIOS 1.37 / ECP 1.04) mit Linux!

Also mein T450s meldet sich mit
BIOS Revision: 1.37 Firmware Revision: 1.4
Vertippt?

Karl

 

[Ambrosius]

@KB19 Vielen Dank für die sehr ausführliche Verschriftlichung deiner Ergebnisse. Bestätigt wieder mehr meine Beobachtung, dass Sanyo echt gute Zellen und allgemeine gute Akkueigenschaften hat.

Konträr dazu hatte ich jüngst wieder ein paar Akkus fürn T480 erworben, die sich alle die Bank durchweg als unbrauchbar erwiesen haben. Vielleicht mache ich mal dazu auch einen Thread auf.

 

[karlK]

Die grafische Darstellung des Lade- und Entladevorgangs unter Linux ist schon ne tolle Sache. Hut ab, ich kriege das nicht hin.

Zu Ambrosius

Konträr dazu hatte ich jüngst wieder ein paar Akkus fürn T480 erworben, die sich alle die Bank durchweg als unbrauchbar erwiesen haben. Vielleicht mache ich mal dazu auch einen Thread auf.

Das würde mich auch interessieren. Waren das China Akkus oder gebrauchte Exemplare?

 

[KB19]

Also mein T450s meldet sich mit
BIOS Revision: 1.37 Firmware Revision: 1.4
Vertippt?

Nein, kein Tippfehler. Diese Versionsnummer steht genau so in den offiziellen Downloads von Lenovo und auch im BIOS auf der Main Seite. Extra nachgeschaut auf einem Foto von vor ein paar Monaten, als das T450s zu mir wanderte und komplett aktualisiert wurde.

• BIOS Version: JBET73WW (1.37)
• BIOS Date: 2019-08-14
• Embedded Controller Version: JBHT17WW (1.04)

Als was sich das Ding im laufenden System meldet (z.B. über DMI), habe ich nicht kontrolliert. Das ist rein die Angabe aus dem BIOS auf der ersten Seite.

 

[karlK]

@KB19

Hast recht, im BIOS seh ich hier auch die 1.04
Dazu aber mal bei meinemT450s diesen angehängter Terminalausdruck '~$ sudo dmidecode -t bios'

Sitzt da das 'Problem' mal wieder vor dem Rechner?

Gruß Karl

 

[KB19]

@karlK Vielleicht hat Lenovo an einer Stelle einfach geschlampt und die beiden Zahlen als einzelne Integer behandelt statt als String? Oder auf die korrekte zweistellige Formatierung mit führender Null vergessen? Keine Ahnung, aber spannender Fund! Das T450s dürfte auch das einzige meiner Geräte sein, bei dem die EC-Version hinter dem Punkt <10 ist.

 

[Crisser67]

Ich habe durch Zufall auf Reddit was gefunden, was zum Thema hier passen könnte.
Ich bin kein Linux-Experte und habe das Tool noch nicht selbst getestet und kann es daher nicht in der Funktion beurteilen, aber es hört sich interresant an.

Es nennt sich ”batcap“ und soll angeblich die echte Kapazität des Akkus messen können.
Hier der Thread auf Reddit:
A little story about my X1 Carbon Gen 7 upgrade, a suspicious battery, and a utility I wrote to test it.

Das Tool auf Github

Wie ist eure Meinung dazu ?

 

[karlK]

Crisser67

Dank dir für den Tipp.

Karl

PS. Was ich in dem Zusammenhang recht interessant finde, ist dort der Hinweis 'for accurate results, it is highly recommended to start from 100% capacity'

Hab da hier im Forum an anderer Stelle schon mal nach gefragt. Und dann auch hier mal die Frage zu den mir 'ominösen' 0%. Was soll das sein? Normalerweise sollte da eine Abschaltspannung genannt werden, die diese 0% darstellt. Google spuckt da Einiges aus, nur wie sieht da hier aus?Man wird die 0% sicherlich nicht bei 2.xV sehen.

 

[Crisser67]

@karlK
Schön, dass du das Tool gleich mal angetestet hast, es scheint ja auch was zu tun.
Ich würde mal den Akku komplett vollladen, bis er keine Ladung mehr annimmt und dann im normalen Betrieb komplett bis 0% entladen, also bis er auch nur im BIOS laufend abschaltet, wenn das praktitabel ist.
Auf das Ergebnis der Kapazität wäre ich gespannt im Vergleich zur normalen Systemangabe.

 

[KB19]

Wie ist eure Meinung dazu ?

Ohne mir den Quellcode im Detail angesehen zu haben: Das Tool muss sich halt auch auf das verlassen, was die Firmware z.B. an Leistung (Watt) meldet. Je nachdem was man laufen lässt, dauert es ja immer einige Sekunden/Minuten, bis sich "power_now" auf den wirklichen Verbrauch einpendelt.

Aber zur groben Orientierung, ob man es jetzt mit 25% oder 75% Akkukapazität zu tun hat, wird es wohl reichen. Ich persönlich würde dafür aber trotzdem nicht einfach so irgendein Binary von irgendwem installieren, das es erst seit ein paar Tagen gibt. Da logge ich die Werte lieber mit Bash und rechne nachher selber rum.

 

[Mornsgrans]

Die 0% liegt bei der Abschaltspannung, je nach Modell zwischen ca. 10-11V. Sind etwa 3,3V +x pro Akkuzelle.
Die genauen Werte lassen sich z.B. unter TLP-Protokoll auslesen.

 

[karlK]

Die 0% liegt bei der Abschaltspannung, je nach Modell zwischen ca. 10-11V. Sind etwa 3,3V +x pro Akkuzelle.

Hallo. Nur, das sind, wenn es den LiLo Akkus betreffen sollte, recht hohe Werte oder anders herum eine sehr frühe Abschaltung.
Ich hab dazu mal den header aus dem ICharger manual zum Thema, dass ich hier auf dem Tisch hab, kopiert.

Die genauen Werte lassen sich z.B. unter TLP-Protokoll auslesen.

Könntest du mir vielleicht kurz sagen, wie man mittels TLP an den Wert kommt?
Danke - Karl

 

[linrunner]

tlp-stat -b -v

Aktuelle Spannung in voltage_now. Und lass dich von dem Wert in voltage_min_design nicht täuschen, das ist nicht die Entladeendspannung; sondern die Nominalspannung des Akkus.

 

[karlK]

Aber zur groben Orientierung, ob man es jetzt mit 25% oder 75% Akkukapazität zu tun hat, wird es wohl reichen. Ich persönlich würde dafür aber trotzdem nicht einfach so irgendein Binary von irgendwem installieren, das es erst seit ein paar Tagen gibt. Da logge ich die Werte lieber mit Bash und rechne nachher selber rum.

Es wird wohl reichen, wird aber auch ungenauer. Hab etwas Messtechnik in der Industrie gemacht und wenn das Signale (Temp, Druck, Kraft usw.) analog als 4 - 20mA oder 0 - 5V zu übertragen war hab ich mich bei einer Signalsimulation immer besser gefühlt, wenn das entsprechende Signal (Temp, Druck, Kraft usw.) so mit ~ 50% vorgebbar war, um beim eigentlichen Anlagenbetrieb nicht auf den A.... zu fallen. Aber das am Rande.


Zum Programm da in github. Der Entwickler hat den Code offen gelegt und schon div. releases veröffentlicht. Go sagte mir absolut nix und ich hab das Programm nur mal kurz gestartet. Benötigt kein root bzw. sudo, seh ich von der Seite als nicht kritisch und was den TP betrifft, ich hab hier die China Akkus.

Nebenbei, hab gerade mal eine TLP recalibration am T450s BAT0 mit meinem 'Gebastel' gestartet. Man schauen, was da raus kommt ...

Karl