I've also been having awkward behavior since updating to the latest CSSU-T.

When I first upgraded, It reported ~1200 mah capacity. I currently have a Scud battery that I purchased apparently rated at 1440 mah. For the longest time my meter stayed at 5%, almost for half a day without a low battery alert or warning until it finally shut off on its own. When it restarted it then showed a capacity of ~1500 mah. This was about three days ago.

Right now as I read this thread, I peek at my capacity and it shows this


I'm not sure when this happened or what caused it. Before I took the screenshot I had just unplugged it from a full charge from my laptop (several minutes passed).

1500 mAh is you relative capacity - when it discharged "to the end", it calibrated itself. Now, 900-something mAh is your "design capacity", as reported by resistor, and of course, is total BS. It shouldn't be ever, even for a second, considered as any reliable source - either default, or, IMO, even optional. But, for that or this reasons, it is default for max capacity (you *should* be able to change it to bq27x00_battery data, but it doesn't seems to work right now, see my bug report).

Now, AIUI, the "fake" battery full report (green diode and all stuff) is because new applet reports full battery as soon as it reaches fake 100%, i.e. 900 mAh. You could check it using BNF (from repos, shameless advert ) to see if your battery is really full, when it says so. I bet that when you seen green diode, ti was still chargin @ ~200mA rate, and it would do so, until real full - ~1500 mAh - is hit.

Cheers,
/Estel

How does the resistor explain that the same battery reports 1181/1203 mAh one day and 1212/484 mAh the next? No shutdown, no reboot, just a simple recharge in between.

10 characters

No, this is "battery.reporting.last_full" property of "/org/freedesktop/Hal/devices/bme", in order to use the resistor values, one should set "use_design_capacity" to "2".

However, a workaround should be implemented here, though I am not sure what exactly, need to think for a while.

alarm automaticly close

Thanks Estel. I already know read that, but as you say it requires lot of effort and my habilities with electronics are not very good.

A friend re-soldered a new usb port, but after some days it went loose and broke again. So I decided to not bother him more, and survive with an external charger until I get a Jolla or Neo900...

alarm = clock app?

In that case: what is the output of running "/usr/bin/worldclock" in xterm?

when we are on alarm - I've noticed strange, reproducible bug with new alarm (I think it might be reported before, but I can't find it now, so I'm not sure):

When your battery dies between setting active alarm and triggering it, on next boot - even if it's hours and hours after alarm deadline - you get alarm window early after hildon starts, without sound. If you tell it to stop, then hildon finish loading, alarm sound start to play, and it is impossible to shut it up by any means, other than shutting whole device down.

I've encountered it using latest version of cssu-testing, thumb flavor.

/Estel

I am sorry for my poor English.I can't express myself clearly.

It happened when I edited some alarms.