It'd be cool if your widget collected some of this data during charges, adjusting the profile on the fly, adapting to the user's battery. The battery will lose capacity and gain internal resistance over time, mostly related to the temperature it gets exposed to. This will make the charging reach 4200mV sooner, the constantt voltage stage, and this stage will take longer and longer time, relatively.

Alright, so I ran your script while charging. Curious about the result I couldn't resist peeking at the data. What I found was an imho weird behavior. Take a look at the graph. Is this normal?

I think there is a problem... I've done a charging test yesterday, and the voltage level was increased almost linearly... I don't know what's wrong, but if I were you I'll redo the test asap

When you unplug the charger and type lshal | grep battery, what's the current voltage ?

Trying to help...

a) Mine is near-linear, I can calculate percentage charge to within a few points (checked by removing charger). Fiddling with it is bad tho.

b) It doesn't have to be by-the-second. Batteries in N900 are quite similar and charge current is 500 mA until such is the time to throttle it. Can't we just use a conversion table? Say, every 10 % or so, and guesstimate that a 30% battery will charge in 55-65 minutes? We'll call it "about 60 minutes". 40% would be "about 50 minutes", etc. Community could help with figures.

c) Can't a software self-profile? When plugged in, it times the charge time from current level to full _assuming_no_interaction_ (if the user plays with it it's no longer fully charging). It should be able to do decent estimates after -say- 3 charges at 5, 30 and 60 percent?

I like where you guys are going with this.