Originally Posted by mcow

Regarding the icons, I think trying to cram too much information into one icon is counterproductive. I'm unconvinced even that there should be a drain-rate indicator in the icon; being able to get to the numeric readout in a single key ought to be enough.

Originally Posted by mcow

Also: the icon design I saw for drain-rate looks like an upward-pointing arrow. Doesn't it make more sense for the drain rate to be downward-pointing?

Originally Posted by auouymous

New test binaries for ASUI, settings and statusbar.

The statusbar drain indicator now reads power draw from BME and is updated every 15 seconds. Colors are: <100 mA (gray), <200 mA (yellow), <350 mA (orange), >=350 mA (red), look good? Playing a video with mplayer is about 450, playing video with media player is about 200, idle with wifi varies from 70-200 depending on brightness.

Originally Posted by maacruz

So, l propose: >10h gray, 10-6 h yellow, 6-4 h orange, <4 h red

Originally Posted by maacruz

But I see odd battery drops (see graph, do you see them in your device too?), so taking into account the real battery drop in the 2 hours testing period, it would mean a 1.22 (22%) correction factor.

Originally Posted by auouymous

Duh, I didn't think about mapping them to times. Orange should probably 7 instead of 6 as it one of the max usage times. But 4 and 10 look good for the other two, three hours between each color.

Originally Posted by auouymous

Battery drops are random events and shouldn't be accounted for.

Originally Posted by auouymous

Any idea what would cause BME socket reading to block indefinitely?

My C script worked fine but the applet blocks on the fifth request read, sixth read if it you include the BMentity reply. I even placed a select call before the reads but it always shows the socket to be ready. To get around this, the applet you have opens, reads and closes the socket every time it requests a value. The charging signal calls the BME update function to change the icon and was requesting a new value every time the charger was unplugged. It seems that requesting a new value too soon after the last can cause the read to block. I've now changed the code so only the 15 second timer requests new values but it might still be possible for some random event to cause read to block and lock up the statusbar. Finding a way to prevent this would not only prevent random lock ups but also use less cpu if it didn't have to open the socket for each request.

Originally Posted by maacruz

They aren't that random for me, always seem to happen after a long constant drain, for example listening to music for some hours with the screen off, then when I stop music and leave the device for a couple of minutes the drop happens.

Originally Posted by maacruz

I learned with the python script that BME socket behavior is quite random, sometimes it allows just one reading, other quite a few in a row, then blocks.
Just do like the python script, write the request to the socket, and try to read the result but using a 0.5 or 1 s timeout. If the reading timeouts, then close and open the socket and repeat.

Originally Posted by auouymous

You can turn off the drain and cpu indicators in settings. And the drain is the actual current draw and not the % per last hour value that ASUI shows.

Originally Posted by auouymous

Charging has an arrow pointing into the battery since power is being put into it. Drain arrows show power exiting the battery...

Originally Posted by mcow

OK. I was referring not only to battery drain but the WiFi+bluetooth indicators that were being discussed as integrated into the battery+CPU icon. But you guys can probably come up with a workable design.

Originally Posted by mcow

I see. I guess I don't find that intuitive. You could support both your case and mine by putting the drain indicator beneath, rather than above, the battery.

Originally Posted by mcow

Unrelated to the above: on my N800, I'm not getting the battery-charging sound (with ASUI 0.5.8). I haven't lately drained the battery enough to trigger the low-battery sound, so I don't know whether that's working.

Originally Posted by auouymous

Battery temperature and other environmental and usage patterns can cause the capacity to increase or decrease. For you it could be a 22% difference but not for someone else. The raw value is a good reference as to how much current your device is drawing at any given moment and if you want longer battery life you figure out way to keep it in the lower colors.

Socket reading doesn't support timeouts, python's read is probably just a wrapper for the select/read combo. I think the problem might be BME not returning a full reply, so select sees some data but then read blocks because there isn't enough data. DSME uses a header on each message to allow variable sized messages. You read the header first, extract the length and read the rest of the message. Every BME reply has 96 bits of unknown data at the beginning which might be used to report errors or the type of reply. Wish Nokia would publish docs.

Originally Posted by mcow

Regarding the icons, I think trying to cram too much information into one icon is counterproductive. I'm unconvinced even that there should be a drain-rate indicator in the icon; being able to get to the numeric readout in a single key ought to be enough.

Also: the icon design I saw for drain-rate looks like an upward-pointing arrow. Doesn't it make more sense for the drain rate to be downward-pointing?