Verwirrung bei tp_smapi - Schwellenladen

foobar

New member
Registriert
3 März 2006
Beiträge
65
Hallo Leute,

ich nutze tpsmapi um das Laden des Akkus entsprechend mit Schwellen zu steuern.
Momentan hab ich das ganze nochmal mit meinem 4-Zeller am X200s getestet, sieht
bei dem 9-Zeller allerdings genau so aus.

Beispiel:

stop_charge_tresh liegt bei 75

Er sollte also bis 75% laden, geht allerdings schon bei 64% schon auf idle.

design_capacity liegt bei 28800
last_full_capacity bei 30220

remaining_capacity liegt bei 19230 wenn er zum idle übergeht.
Dies entspricht dann 67% von der design_capacity bzw. 64% von der last_full_capacity.

Das Gnome Symbol zeigt auch die 64% an. Aber auf welcher Grundlage hin
gibt tpsmapi das Laden schon bei 19230 auf?. Korrekterweise sollte er doch
bis 22665 (30220 * 0,75) geladen werden.

Kennt hier jemand die Ursache für dieses Problem..?
 
Zuletzt bearbeitet:
Wie sieht denn Deine "stop_charge_thresh" aus?

Die "start_charge_thresh" definiert die Grenze, unterhalb derer mit dem Laden begonnen wird.
Die "stop_charge_thresh" bestimmt den Grenzwert, bis zu dem maximal geladen werden soll.
 
Zuletzt bearbeitet:
Erm, sorry.. werde ich schnell editieren.

start_charge_thresh ist 40
stop_charge_thesh ist 75

In meinem Posting oben beziehe ich mich vorerst nur den stop_charge_thresh, also die obere Schwelle.
Ich weiß allerdings aus einem Test den ich vor einiger Zeit mit dem 9 Zeller gemacht habe, das auch
bei dem start_charge_thresh eine Diffenz vorhanden ist.
 
start_charge_tresh liegt bei 75

Er sollte also bis 75% laden, geht allerdings schon bei 64% schon auf idle.

das bedeutet doch das es bei 75% anfängt an zu laden, wie sieht aus wenn sie start_charge_thresh auf 10% senken

Edit: zu spät :facepalm:
 
ich würde versuchen das Akku zu rekalibren, sprich 3 mal vollständig auf- und entladen
 
Ich würde an Deiner Stelle erstmal den Akku kalibrieren, und dann weiterschauen. Wurde er überhaupt schonmal kalibriert?
 
Das selbe Problem tritt wiegesagt auch bei dem 9-Zeller auf. Den 4-Zeller hab ich nun neu und 2 mal komplett entladen
und wieder aufgeladen. Im Anschluß habe ich die Anpassungen an tp_smapi vorgenommen.

Aber unabhängig von einer Kalibrierung muss tp_smapi doch irgendwie auf diesen Wert von 19230 kommen.
Dieser erklärt sich ja weder aus der design_capacity noch der tatsächlichen last_full_capacity.
tp_smapi kann doch nur mit den vom Akku gelieferten Werten arbeiten und misst nicht selber
irgendwas am Akku oder?

Umgekehrt gerechnet müsste die volle tatsächliche Kapazität ja bei 25640 liegen (19230/75*100)

Läuft das denn bei euch überall korrekt wie man es sich eigentlich vorstellt?
Habe gehofft ein paar Leidensgenossen zu finden :-D

--
Ein weiteres Problem welches mir noch bekannt ist aber etwas offtopic ist:
Ursprünglich hatte ich auf dem X200s ein Debian stable (squeeze) laufen.
Dort berichtet das Batteriesymbol das der Akku an der oberen Schwelle auf idle geht.
Nachdem ich Debian testing (wheezy) installiert habe meldete gnome nach
erreichen der oberen Schwelle das weitergeladen wird, tatsächlich idled der
Akku aber (cat status). Nun habe ich Gnome3 installiert. Der meldet dies nicht
mehr aber ich weiß das dieses Problem generell noch vorhanden ist.
Soll aber angeblich an dem 3.0.1er Kernel liegen und ich habe es nicht mit der
2.6er alternative getestet. Der Bug scheint jedenfalls nicht durch tp_smapi
oder den gnome-power-manager generiert zu werden. Aber das nur mal zur Info
nebenher. Dies hat nichts mit dem oben beschriebenen Problem zu tun :)
 
Zuletzt bearbeitet:
Tippfehler kannst du ausschließen?
Denn in deinem ersten Post hast du von: "stop_charge_tresh" geschrieben. Es heißt aber "stop_charge_thresh".
Zeig doch mal deine ganze /etc/default/tlp, am besten damit:
http://paste.ubuntu.com/

Bei mir kommt es nur vor, dass die Ladeschwelle um ca. 1% danebenliegt. Wenn ich 95% eingestellt habe, wird meistens nur bis 94% geladen. Aber so krass sollte das nicht abweichen.

Grüße
bassplayer

EDIT: benutzt du überhaupt TLP? :confused: Oder nur per smapi?
 
Zuletzt bearbeitet:
Jaja, das kann ich schon ausschließen. Ich schicke die Werte per echo in der rc.local.
Das funktioniert schon so. Abgesehen davon passe ich die Werte auch gelegentlich direkt
aus der Shell an und lese /sys/devices/platform/smapi/BAT0/{start_charge_thresh,stop_charge_thresh}
sicherheitshalber nochmal aus. Da liegt der Fehler definitiv nicht :)
 
Zuletzt bearbeitet:
Ajo, grad auch nochmal mit dmesg geschaut. Meldet auch korrekterweise:

smapi smapi: set_real_thresh: set stop to 75 for bat=0

Bei der Fehlersuche bin ich auf einige Beträge gestoßen wo dort andere Werte
zurück gemeldet worden sind. Das scheint hier aber richtig zu laufen.
 
Ich schicke die Werte per echo in der rc.local.
Ich nutze zwar auch kein TLP, stelle diese Werte allerdings durch Einträge in /etc/sysfs.conf ein:
Code:
# grep smapi /etc/sysfs.conf 
devices/platform/smapi/BAT1/start_charge_thresh=65
devices/platform/smapi/BAT1/stop_charge_thresh=90
devices/platform/smapi/BAT0/start_charge_thresh=65
devices/platform/smapi/BAT0/stop_charge_thresh=90
Und ja, das läuft bei mir "korrekt wie man es sich eigentlich vorstellt".
 
Ich kann mir eher weniger vorstellen das es damit irgendwie zusammen hängen kann.
Soweit ich das "draußen" gesehen habe wird oft sogar rc.local bevorzugt genutzt.

Aber vielleicht sollte ich das trotzdessen einfach mal testen um auch diese Möglichkeit
ganz auszuschließen. Aber vermutlich ist das eher Zeitverschwendung :-D

Da muss noch irgendwas anderes vorliegen.. aber mit fällt gerade nichts mehr ein
wo ich noch weiter ansetzen könnte.. hmpf :-/
 
Achso, um die Sache hier mal aufzulösen.. es lag offensichlich doch nur daran das der Akku noch nicht
genug Zyklen hatte und damit noch nicht richtig kalibriert war. Nachdem das Ding nun so 6-7 Cycles hat
funktioniert alles wie gewohnt. Liegt mal nen 1% daneben.. aber damit nun genau genug :)
 
  • ok1.de
  • ok2.de
  • thinkstore24.de
  • Preiswerte-IT - Gebrauchte Lenovo Notebooks kaufen

Werbung

Zurück
Oben