Kobo Start Menu 08

[Ken Maltby]

The Github issues: first this one - then this one. There seems to be some progress, including new hope for the suspend issue on older devices, as well.

Luck;
Ken

[oldhasbeen]

I am currently fine tuning data on power consumption for Aura H2O (would most likely relate in principle to other models as well).
The battery current drain taken when idling in Nickel menu is about 2 mA. Running KSM 08 menu in idle needs approximately 10 mA.
Operating Koreader or any PB Chess application results in somewhat like 12 - 13 mA idle current. I cannot decide if KSM 08 uses power when another application is running. Is there a way to have KSM suspended while another app is active?

[tshering]

@oldhasbeen
I think there is nothing that should be needed to be suspended. KSM is rather a bundle of scripts and binary executables, than one executable. When you start an(other) application from KSM, no KSM binaries are kept running, but only scripts.

When you see the KSM main menu on the screen, the following KSM executables are running:
adds/kbmenu/onstart/ksmhome.sh
adds/kbmenu/onstart/kobomenu.sh
adds/kbmenu/kobomenu # This is the binary executable, the one that consumes power.

When KOReader is running, then from the KSM side, there are running:
adds/kbmenu/onstart/ksmhome.sh
adds/kbmenu/onstart/start_koreader.sh

When nickel is running, then from the KSM side, there are running:
adds/kbmenu/onstart/ksmhome.sh
adds/kbmenu/onstart/start_nickel.sh


Note: On default, there is one further KSM script running in the background, namely adds/kbmenu/onstart/preventfreeze.sh. You can disable it with the "configure" menu. (This needs rebooting to become effective, if I remember correctly).

As to your report on https://github.com/koreader/koreader/issues/2239, I guess you started nickel from KSM. If this is correct, then I would see the whole picture in this way: The binary kobomenu and KOReader have each about the same power consumption, when idle (10 or 12-13 mA average). Since both do basically the same job in this situation, I guess, namely waiting for user input, that seems reasonable. The outstanding thing is that nickel does the same job (waiting for user input) more efficiently.

[Alan_S]

So, it looks like that KSM don't add to battery drain, as almost same scripts run in background while koreader and nickel are used.

Maybe it is question how to optimize koreader to be more power efficient when running. But, it is not that big problem, as problem as koreader's suspend script (usually reader is longer suspended than running).

Maybe it is question of drivers, programming language, or something similar that makes koreader needing more power than nickel?

[oldhasbeen]

Originally Posted by tshering

@oldhasbeen
I think there is nothing that should be needed to be suspended. KSM is rather a bundle of scripts and binary executables, than one executable. When you start an(other) application from KSM, no KSM binaries are kept running, but only scripts.

When you see the KSM main menu on the screen, the following KSM executables are running:
adds/kbmenu/onstart/ksmhome.sh
adds/kbmenu/onstart/kobomenu.sh
adds/kbmenu/kobomenu # This is the binary executable, the one that consumes power.

When KOReader is running, then from the KSM side, there are running:
adds/kbmenu/onstart/ksmhome.sh
adds/kbmenu/onstart/start_koreader.sh

When nickel is running, then from the KSM side, there are running:
adds/kbmenu/onstart/ksmhome.sh
adds/kbmenu/onstart/start_nickel.sh


Note: On default, there is one further KSM script running in the background, namely adds/kbmenu/onstart/preventfreeze.sh. You can disable it with the "configure" menu. (This needs rebooting to become effective, if I remember correctly).

As to your report on https://github.com/koreader/koreader/issues/2239, I guess you started nickel from KSM. If this is correct, then I would see the whole picture in this way: The binary kobomenu and KOReader have each about the same power consumption, when idle (10 or 12-13 mA average). Since both do basically the same job in this situation, I guess, namely waiting for user input, that seems reasonable. The outstanding thing is that nickel does the same job (waiting for user input) more efficiently.

Thank You - that helps!

[Alan_S]

@tshering

I just tested something I noticed. I use koreader as main (acutally, only) reader and with it I use this small modification: https://www.mobileread.com/forums/sho...41&postcount=4

It adds option to quick toggle light and shut off device directly by using your power off script.

And here is the problem I noticed. When I shut off device and turn it on (even in next few seconds) there's a bit battery lost (well, this is a bit hard to tell), but also something more obvious: loss of about three minutes. Clock runs late by three minutes.

At first I thought it may be something caused by koreader, but jut now I tested, I exited koreader and powered off with KSM. There was about 3 minutes less.

I'm not sure what's going on and why clock is running late, but I hope you'll have some idea what's going on. You just need to first set time to be sure you have clock set correctly and then power off.

Please try and see if you also lose 3 minutes by powering off device. Or is it something H2O related?

[tshering]

Originally Posted by Alan_S

@tshering

I just tested something I noticed. I use koreader as main (acutally, only) reader and with it I use this small modification: https://www.mobileread.com/forums/sho...41&postcount=4

It adds option to quick toggle light and shut off device directly by using your power off script.

And here is the problem I noticed. When I shut off device and turn it on (even in next few seconds) there's a bit battery lost (well, this is a bit hard to tell), but also something more obvious: loss of about three minutes. Clock runs late by three minutes.

At first I thought it may be something caused by koreader, but jut now I tested, I exited koreader and powered off with KSM. There was about 3 minutes less.

I'm not sure what's going on and why clock is running late, but I hope you'll have some idea what's going on. You just need to first set time to be sure you have clock set correctly and then power off.

Please try and see if you also lose 3 minutes by powering off device. Or is it something H2O related?

I do not have my Kobo with me. So I will test this only this night. I understand that the "small modification" has nothing to do with the time loss. Right. Did you try to power down from KSM without that koreader was running at all?

[tshering]

Originally Posted by Alan_S

Please try and see if you also lose 3 minutes by powering off device. Or is it something H2O related?

I do not lose 3 minutes. Maybe we are setting the time different. I am using two commands, the first is for setting the system time, and the next for synchronizing the hardware clock (otherwise the setting is lost when powering off), e.g.:

date 18:44:25
hwclock -w -u

[Alan_S]

Thanks, that was missing info. I didn't know that hardware clock isn't synchronized and it looks like it was 3 minutes off.

And yes, I mentioned, but it was a long text, I tested powering off from KSM, although "small modification" uses KSM's power off script (or can be made to use any power off script, but in my case it points to KSM's own).

Now I noticed there still is problem with "lost battery" from powering off. It may be something similar with clock problem.

I had (just tested powering off after I applied hwclock command) 100% before, after was 87% reported in koreader. Then I powered off again, than it showed 86%.

Is there a command to enable me to see real battery percentage, or something before I do power off and after? To be sure that it is just a question of battery percentage reading?

Or, is it possible that that much battery is lost? I do fast power off cycles, it looks strange how that much less battery I have after powering on.

[Alan_S]

How we can make script to automatically use both these commands?

For example, name of the script would be settime.sh, it would be run with same parameters as date (settime 23:12:11) and it would automatically set date to that time and afterward execute hwclock command.

#!/bin/sh

date $1
hwclock -w -u

How can I best run my newly created script settime.sh from KSM, or its terminal? Any suggestion how to set this up to easily set both system and hardware clock?

[tshering]

Originally Posted by Alan_S

How we can make script to automatically use both these commands?

For example, name of the script would be settime.sh, it would be run with same parameters as date (settime 23:12:11) and it would automatically set date to that time and afterward execute hwclock command.

#!/bin/sh

date $1
hwclock -w -u

How can I best run my newly created script settime.sh from KSM, or its terminal? Any suggestion how to set this up to easily set both system and hardware clock?

I guess this should work:

#!/bin/sh
date "$*" 2>/dev/null && hwclock -w -u

I am unable to test it now.

[tshering]

Originally Posted by Alan_S

I had (just tested powering off after I applied hwclock command) 100% before, after was 87% reported in koreader. Then I powered off again, than it showed 86%.

Is it the loss from 87% to 86%, or from 100% to 87% that bothers you? If it is from 87 to 86, I do not know how significant that difference is?

Originally Posted by Alan_S

Is there a command to enable me to see real battery percentage, or something before I do power off and after? To be sure that it is just a question of battery percentage reading?

If you use embryo's Measure battery duration for KSM, you can find the power status at the moment of powering off in /adds/kbmenu/t/log/uptime.txt. You can navigate to this file and read it with "tools > explore." You find the KSM 08 version in post #2. You can compare this to what KSM's check_battery.sh shows, after you reboot. The values are those provided by the system, how exactly they correspond to the real state of the battery I cannot say.

Originally Posted by Alan_S

Or, is it possible that that much battery is lost? I do fast power off cycles, it looks strange how that much less battery I have after powering on.

If you do fast power off cycles, does the power percentage continue to decrease each time? I mean after 10 times powering off do you go say from 86 to 78 or something like this?

[Ebri]

In nickel you also see some loss of the battery after reboot (Aura HD). As I know battery percentages are not too punctual, so indeed, i fit is 1-3% difference, then don't worry. If more... it is indeed strange.

[Alan_S]

Originally Posted by tshering

I guess this should work:

#!/bin/sh
date "$*" 2>/dev/null && hwclock -w -u

I am unable to test it now.

How should I run this script (let's call it settime)?

./settime 20:44:21

This from terminal? Where should I put script in that case (what directory)? Please, advise on best way to create and run this script.

Also, maybe to include something like this in KSM? I see date options in KSM, but for some reason they don't work for me.

And thanks for code, can't karma your posts at the moment (did it too much before...).

[Alan_S]

Originally Posted by tshering

Is it the loss from 87% to 86%, or from 100% to 87% that bothers you? If it is from 87 to 86, I do not know how significant that difference is?

If you do fast power off cycles, does the power percentage continue to decrease each time? I mean after 10 times powering off do you go say from 86 to 78 or something like this?

The problem was first drop, from 100% to 87% (this was last when I check, there was different numbers, but similarly significant drop).

Second cycle was more or less normal (87% to 86%), I guess this is something expected, reader uses a bit more power when powering, it also could "push" battery to a bit lower value from higher temporarily consumption.

I didn't do prolonged testings, just did two testing cycles, I guess that 10 cycles wouldn't go that low.

I also found your script for checking battery and when first used this, to check how KSM sees battery and then powering off and on, battery was at same level, so it is something with reading battery state from koreader (from which I call KSM's poweroff.sh).

I guess that everything is fine with KSM's power off script, just thing with time and sudden perceived battery percentage drop alarmed me.