Is this a crazy idea or not?

[knc1]

Originally Posted by Cinisajoy

Please shrink your image.

It is 581x581 19 pixels less than the limit.

[Cinisajoy]

Originally Posted by knc1

It is 581x581 19 pixels less than the limit.

It looked huge. Glad I didn't bug the mods.
Thanks for the double check.

[xorlof]

Originally Posted by knc1

It is 581x581 19 pixels less than the limit.

Yeah, I learned my lesson to check. In the OP, I had an image in the spoiler that was 40 pixels over.

Cinisajoy--yep, I will be sure to let you all know the results. So far it is 3 hours in and the battery is reporting about an 8℅ drop.

[Cinisajoy]

Originally Posted by xorlof

Yeah, I learned my lesson to check. In the OP, I had an image in the spoiler that was 40 pixels over.

Cinisajoy--yep, I will be sure to let you all know the results. So far it is 3 hours in and the battery is reporting about an 8℅ drop.

That isn't bad at all.

[xorlof]

So I did the test, but there were problems. After 17 hours of continuous running, my WAF crashed with the familiar/generic, "The selected application could not be started. Please try again." error. There was still over 50% battery remaining at that point. I did not notice the problem for 10 hours (was out of the house). By the time I did notice, the battery had drained to just 12% remaining. That's a 50% drain in 10 hours, doing "nothing," just by displaying the error message (my app was closed)!

To try and make lemonade out of lemons, I though I would use the remaining battery life to test the theory that perhaps you use less battery when you're in a better wifi zone (remember, I was running this test at a spot where wifi was sketchy). I moved the Kindle closer to the access point and restarted the test. The hourly mAh usage did decrease. So while that hypothesis appears to be correct, I can't really report that as a definitive finding yet because something else weird happened battery-wise during the test with the remaining 12% battery. My WAF app drained the battery until the kindle was reporting 6.51% remaining...and then the app continued running as normal and for the next 4 hours the kindle kept reporting 6.51% battery remaining. (It should have been decreasing by 2-3% per hour.) After the 4 hours of being stuck at 6.51%, the reported battery life started decreasing again as normal until the app drained the battery and the kindle shut off. Weird.

For those curious, I'll put together some graphs to show what the battery drain looked like over time.

I have recharged the Kindle and am redoing the full test, this time restarting my WAF every 12 hours or so to help avoid a crash. No matter the exact result, I'm calling this a success because the data I got from the previous run indicates that the battery should more than 3 times my goal of 11 hours of runtime. I'm impressed!

[knc1]

Is there a possibility that your device updated over the air while connected?

That could cause the message (and result in the state where it has a high power drain while showing the message).

Check what firmware version and build number your device is now running.
Although the version number may not have changed, the build number probably did.

[xorlof]

That's a very good thought! I will check that when I get home, but I bet you're right!

I thought I had updates suppressed, but something could have snuck through. I haven't had this particular device for especially long (I had a kindle keyboard previously), so I'm not 100% certain yet that I've got the firmware locked to a particular version. (I used the "make a bogus specially-named directory entry method for the Kindle Touch (1st edition) to try and stop updates).

I do have a screenshot of it's firmware status from a week ago and will (quickly) compare it tonight, resuming the ongoing battery test.

[knc1]

The progress of your testing so far reads as if the battery run-time is going to meet your needs.

No way out of it now - you'll have to code your application.

[Cinisajoy]

I was thinking maybe it kept trying to restart that application.

[xorlof]

Originally Posted by knc1

Is there a possibility that your device updated over the air while connected?

You're a genius! Yep, that was it.

Originally Posted by knc1

The progress of your testing so far reads as if the battery run-time is going to meet your needs.

No way out of it now - you'll have to code your application.

Ha! Fair enough. I'll start...uh...tomorrow! (Just kidding, the battery benchmarking was immediately promising this past weekend so I've already started.)

[Localhorst86]

While I am not a developer, stories like these are really interesting to follow. I like the idea of using tech that you already own to solve a problem or task you are facing. Following this story reminds me of storries like "ITAPPMONROBOT", always a good read

[xorlof]

The second attempt at extended battery test is done and finished without incident. Here's the power consumption over time:



You'll see roughly 3 periods of time here where the power consumption varied. It started out at one level (until hour 11ish), sunk to a lower level for a while (to hour 22ish) and then was at a higher level, except at the very end. The start of these periods correlate with times that I restarted the app (just to be sure of no crashes even though knc1 identified the likely cause of crashing in the first round of testing).

The chart is anchored at 30mA because that's roughly the power draw of the Kindle awake, at idle, and with the wifi turned on at this location. That means the blue bars roughly show how much power MY app was using above the at-idle power use.

Key findings:
1) Test app was on average drawing about 8 to 13 mA (10.7 average). This is much lower than I expected given WAFs having a pretty big overhead (using the web browser rather than native code). Keep in mind, that's just an average. There was plenty of time the app was doing nothing but waiting for the next per-minute update.
2) Different launches of the app can result in different average power consumption.
3) Overall runtime was 35.5 hours.
4) The Kindle shuts down when 3% of reported battery life remains.

[NullNix]

Originally Posted by xorlof

My WAF app drained the battery until the kindle was reporting 6.51% remaining...and then the app continued running as normal and for the next 4 hours the kindle kept reporting 6.51% battery remaining. (It should have been decreasing by 2-3% per hour.) After the 4 hours of being stuck at 6.51%, the reported battery life started decreasing again as normal until the app drained the battery and the kindle shut off. Weird.

This just suggests that the battery circuit had not yet fully calibrated itself: its initial assumption was that the battery had less capacity (or rather, a higher minimum voltage / internal resistance) than it in fact did. It should be better calibrated now a full discharge has happened.

[knc1]

This is also a used K5 -
There is no telling what the battery history was like.

Now, install my CPU Report, KUAL extension -
it has menu entries to select the various cpu governors.
as I recall, the K5 has an additional governor setting for which there is no button - but run the report, that will tell for sure.

What is for certain not documented is the 'user space' governor.
Which is most likely the one you want to use in this application.

That would let your application set the lowest speed/power setting as it enters its wait period, and then set the highest speed/power setting the first thing after waking up.
That can be a last refinement after you have your application working as desired.

[xorlof]

Originally Posted by NullNix

This just suggests that the battery circuit had not yet fully calibrated itself: its initial assumption was that the battery had less capacity (or rather, a higher minimum voltage / internal resistance) than it in fact did. It should be better calibrated now a full discharge has happened.

The results of this second run seem to bear that out (no weird "pauses" in the reported discharge curve).

Originally Posted by knc1

Now, install my CPU Report, KUAL extension -
it has menu entries to select the various cpu governors.
as I recall, the K5 has an additional governor setting for which there is no button - but run the report, that will tell for sure.

What is for certain not documented is the 'user space' governor.
Which is most likely the one you want to use in this application.

That would let your application set the lowest speed/power setting as it enters its wait period, and then set the highest speed/power setting the first thing after waking up.
That can be a last refinement after you have your application working as desired.

That's a great idea. Thank you! I have experimented with some things in "/sys/devices/system/cpu/cpu0" and do have the extra governor setting. I did notice that depending on the governor selected I sometimes couldn't adjust frequencies, and sometimes had extra info available in that virtual filesystem area. Is any of that stuff documented somewhere is your KUAL extension code the best spot to look? (I confess that I haven't installed it yet to see if it adjusts files there or uses a LIPC call or what).