Clara HD Battery life seems unusually short

[Mort1997]

I had an issue with my Clara and battery draining overnight when I first bought it (I got it from John Lewis for £35 as a open box item).

I reset it and that cured it (just as well as the John Lewis staff were very unhelpful).

Not my favorite reader but it survives living in the bottom of my rucksack with minimal charging (so far anyway).

[compurandom]

Originally Posted by the.Mtn.Man

It makes no difference whether you drain the battery to 50% and recharge it more frequently, or drain it to 5% and recharge it less frequently.

This is largely true for lead acid batteries, which is not what kobo uses.

This article directly contradicts you:

Battery University: How to prolong lithium based batteries

Case in point, I have a 15-year old iPod Classic

You can't compare a 15 year old battery with a current battery. They don't have the same chemistry, and battery technology has changed drastically in 15 years.

Also, Apple did and does a lot of special things with the electronics around their batteries to try to keep them healthy.

[JSWolf]

Originally Posted by davidfor

The usual thought here is that something in the book leaves a process running and that drains the battery. That's where the suggestion for removing the bad books comes from. Remove and fix them and the problem goes away. And restarting the device will solve it until you open one of these bad books again.

The problem that I don't think anyone knows what in the book causes this.

Do you think converting from ePub > KePub and visa-versa might solve the problem with a bad book?

[compurandom]

Originally Posted by JSWolf

Do you think converting from ePub > KePub and visa-versa might solve the problem with a bad book?

Converting epub->epub is more likely to fix it, as that rewrites a lot of the epub structures from scratch. However since we don't know what's causing it, there's no way to know if either conversion path would fix it.

If it turns out it's embedded javascript doing it, I don' t think either of these conversions removes it.

Do you have a book that you are sure is causing a drain?

It occurs to me that since we can do things like run shell scripts on the device, it should be possible to look and see if there is something chewing cpu and directly test this.

[jgoguen]

Converting ePub->KePub is actually ePub->ePub followed by adding the Kobo features

And no, if the problem is in the JavaScript a conversion won’t fix it. But if it’s the structure or CSS a conversion might fix it.

[compurandom]

Originally Posted by jgoguen

Converting ePub->KePub is actually ePub->ePub followed by adding the Kobo features

Good to know! Thanks for the correction.

So I've cobbled together some scripts that work with NickelMenu to record high cpu use processes and even display a list on the device live.

Now all I need is a set of triggers that cause high cpu use. Would others be interested in that? Should I post them here or start a new thread or??

[jgoguen]

I suspect the high CPU process will be the Adobe ePub renderer or the ACCESS KePub renderer. If that's the case (assuming the info is accessible to NickelMenu scripts) it might be better to note which book is in use and the book position at the time and only note the process if it's not one of those.

Also, how are you defining "high CPU"? False positives are better than false negatives here, but too many false positives and it could quickly get too hard to use that log to track down which books or segments of books are causing problems.

[the.Mtn.Man]

Originally Posted by compurandom

This is largely true for lead acid batteries, which is not what kobo uses.

It's also true for nickel cadmium and lithium ion batteries, the latter of which Kobo does use (as do most modern electronics).

The bottom line here is, use your Kobo, love your Kobo, recharge it when it needs it, and don't worry about the battery being damaged through normal use.

[geek1011]

What does the output of "grep -Er . /sys/class/power_supply/*/uevent" look like after unplugging at 100%, 10 min into reading a book, and while idle at 50%?

Note that you'll want to run this while WiFi is off. This can be done by piping it into a file and/or syslog from a NickelMenu cmd_spawn/cmd_output. Something like "menu_item:main:Save power stats:cmd_output:grep -Er . /sys/class/power_supply/*/uevent | logger -st power 2>&1 | tee /mnt/onboard/power_`date +%s`.log" (and the same for menu_item:reader) would work.

It would probably also be a good idea to record the CPU usage too.

[geek1011]

Originally Posted by jgoguen

I suspect the high CPU process will be the Adobe ePub renderer or the ACCESS KePub renderer. If that's the case (assuming the info is accessible to NickelMenu scripts) it might be better to note which book is in use and the book position at the time and only note the process if it's not one of those.

That would be more something for NickelDBus (think NickelMenu, but for usage by scripts rather than the user). It's not currently supported, but since NDB keeps track of the current ReadingView for currentView, it wouldn't be hard to also make it return the book's URI.

[davidfor]

Originally Posted by the.Mtn.Man

It's also true for nickel cadmium and lithium ion batteries, the latter of which Kobo does use (as do most modern electronics).

I think you are both wrong. @compurandom's claim that keeping the charge level above 50% is the best is wrong. The best is to keep it between about 30% and 70%. That will give the longest lifespan of the battery. You will probably get more total recharge cycles if you stay within this range. But, it means you are only using 40% of the available battery life.

The bottom line here is, use your Kobo, love your Kobo, recharge it when it needs it, and don't worry about the battery being damaged through normal use.

Exactly. Anything you can do to extend the overall life of a Li-Ion battery is difficult and doesn't have enough effect to make it worthwhile. Or means you aren't actually using the battery

[compurandom]

Originally Posted by jgoguen

I suspect the high CPU process will be the Adobe ePub renderer or the ACCESS KePub renderer.

My initial tests confirm this, but the point is less to find out what is causing it as when it is triggered. At least, presuming it's not a run-away auxiliary process.

Also, how are you defining "high CPU"?

... a very important question. For the purposes of this issue, it would be anything consuming cpu continuously (i.e., >50%) when the device should be idle. But unfortunately busybox ps doesn't seem to give a cpu%, so I'll settle for anything that has used >10 seconds or is changing continuously.

Eliminating things with cpu used of 0:00 gives a pretty short list, but I've experimentally been using this as a filter:

ps | awk '$3!~/^0:0/'

Originally Posted by geek1011

grep -Er . /sys/class/power_supply/*/uevent

Added that to my script.

It would probably also be a good idea to record the CPU usage too.

You mean from ps like I did above? or did you have something else in /proc in mind?

(...record book and position...)

Originally Posted by geek1011

That would be more something for NickelDBus

...

it wouldn't be hard to also make it return the book's URI.

That would be a welcome addition to the script.
I just looked at NickelDBus yesterday, lots of interesting stuff there.
I'm sure extracting current book and position might be useful for other things too.

[compurandom]

Originally Posted by davidfor

I think you are both wrong. @compurandom's claim that keeping the charge level above 50% is the best is wrong. The best is to keep it between about 30% and 70%. That will give the longest lifespan of the battery.

I think you are totally right there. I pulled 50% out of the air.

Think of it more like, when you hit 50% you start thinking about plugging in, but by the time you actually get around to it, it might be closer to 30%.

As to only using 40% of the battery's charge capacity -- the idea here is not to religiously follow the 30-70% rule so much as do it when it's convenient rather than intentionally draining the battery flat when you could have plugged in easily. And also you have the full capacity when it isn't convenient.

And if you accidentally drain it flat once or twice a year, you've fulfilled the retrain schedule too. But to do it on purpose seems wasteful.

[NiLuJe]

FWIW, `POWER_SUPPLY_TIME_TO_EMPTY_NOW` is *extremely* variable on my end (Forma): it very much appears to be computed on-the-fly *right now*, with zero smoothing.

(As in, it can fluctuate by a factor of ~4, depending on the immediate power draw, and the thing is *very* finicky).

For people playing at home, it also requires a recent device anyway (Mk. 7 for sure, possibly Mk. 6).

Quick'n dirty script: bat_ttl.sh