Originally Posted by auouymous

Its the same one ASUI uses and I've seen it a lot. The transition to orange at 2.0 is a bit low because I rarely see yellow. Although the orange and yellow are hard to distinguish from each other, I'll either change the 2.0 to halfway between 0.8 and 14.0 or remove orange.

ASUI only tracks last hour and last X hours and it passes the last hour rate to the applet. Last minute tracking is not possible unless you are bleeding 0.1% or more per minute. The applet rate only updates when battery capacity changes.

I can probably add a 60 second timer in the applet that resets when it receives a drain update otherwise it will request a 'decaying' update from ASUI. That way the applet's rate will decrease with time when no BME updates are being sent, just like ASUI does when the battery widget is visible.

Originally Posted by tso

As if ASUI tries to blank the screen but then come right back. The pulse seems to be at maybe 5-10 second intervals.

Originally Posted by tso

/var/lib/alarmd/alarm_queue.xml.
seems to hold two events, one from the sequetary calendar, and one for the hildon update notifier.

Originally Posted by maacruz

Ok. May be red should be a bit further and orange middle point (see below why)

If you take [%battery remaining]/[Active hours left] instead, you'll have an instantaneous discharge rate more useful for the applet. Notice that when the device is in use the discharge rate is never lower than 10%/h and the maximum discharge rate I've observed is 50%/h. The transition points could be gray<15.4%, yellow 15.4%-<22%, orange 22%-28.5%, red >=28.5% (points relate to 6.5, 4.5, 3.5 active hours). That's simpler than any decaying timer.

Originally Posted by auouymous

That won't work, the active time only has hour precision (even though the one signal sends it as minutes and the other as seconds) and it doesn't update instantaneously.

Decay timer is simple and of course the code already exists in ASUI. When a BME capacity signal arrives it takes the difference between the capacity an ~hour ago and the new capacity, using the timestamps of both events. When the battery widget is visible it refreshes the drain rate every 60 seconds by taking the difference between the capacity/timestamp an ~hour ago and the last capacity event with current time instead of its timestamp. This causes the drain the rate to slightly decrease every minute and is accurate.

When adding the drain rate I experimented with rate for last minute and found it to be a useless value because their isn't enough data (and it was only good for eye candy and not for determining usage patterns). Maximum normal rate should be 14-25%/hr (4-7 hours active time) which means it can only decrease 0.1% every 14-25 seconds. Problem is that BME doesn't send out a signal for each 0.1% change but groups them into larger changes.

Originally Posted by maacruz

Let's argue a bit more

Originally Posted by maacruz

Yes, I know it has hour precision, and it is not really instantaneous. But it doesn't need to be decimal point accurate, because we are representing big intervals with 4 color values.
By choosing carefully the transition points, the applet will be accurate enough for it's purpose: helping the user to know when it is using too much battery (for example, some IAP's can drain the battery very quickly) and allowing the user to regulate its battery consumption.
About the time precision, for this matter a 1 minute accuracy can be considered enough, and it is much better than an 1 hour average (although bme time precision is in the order of seconds)

Originally Posted by tso

i lost the touch screen sound when the low battery warning played.

Originally Posted by tso

sorry, no idea. Seems i have lost all sound even tho ASUI shows no mute and output is speakers. Wonder if there is some kind of sub channel that goes wonky.