Anyway, I don't see how the users output will help you to estimate the charge time... It's not easier to just calculate the time elapsed for a percent of charge, and estimate the remaining time based on that info ?

e.g. : starts charging at 15%, when the battery is 16% charged, 2 minutes have passed. So the remaining time is (100 - 16) * 2 = 168 min
and each percent gained, you redo the thing, so when battery is 80% charged, you know that (80 - 15) = 65 percent takes 50min, so 20% left will take (20 * 50 / 65) = 15 minutes

that was the mistake... profile.sh was sitting on a VFAT partition. running it in home/user does work.
thanks.

Hello

Well yes, but first, the relation is not linear and second, I don't think there is a way to poll the battery level while charging. If there is, I'd be interested in it, though.

Thanks, Matt

when you do a lshal | grep battery, when charging, the percentage of battery is not refreshed ? seems odd if it's not refreshed.
I'll do a test

ok right the level of battery is not updated.

But you can rely on voltage.current and voltage.design to approximately determine the remaining time, with the same method as above.

And better, you can check at the first launch of your program the voltage.current when battery is considered as full, to know what's the max level the battery can achieve.

Because everyone can have a battery with a max voltage different, so once again I don't see how the results sent by users will help you.

Hello

Yes, this is what I am planning. However, charging a Li-battery is a little bit tricky. There are several stages; first, the voltage is constantly increased, and then, the current keeps decreasing at constant voltage. I agree with you that the technique you are proposing can be used, but it's probably going a little bit more complicated than just a linear fit.

I have two reasons for asking the community for more logs. First, I charge my device every night when I go to bed, using the outlet charger. That means that I don't have any data about charging curves using the usb cable, charging curves of devices which are being used while charged etc. If I write an application that is supposed to be used by a broader user base, it's reasonable to me to develop the extrapolation algorithm with data from several devices, to cover variations related to user behaviour and the device itself. If I would rely on my own data only, I could naively assume that the second stage starts when 4140 mV are reached. Comparing my data with other data from other devices and batteries may reveal that it's not always 4140 mV. Furthermore, I'm trying to find a good estimation for the second stage of the charging process which suits as many charging and using pattern as possible, not just my own.

Second, it's just an easy way for me to get a large sample size. As I said, I charge my device once a day, so I can collect 7 profiles a week. I have a background in biostatistics and to make some reasonable predictions, I'm looking for n>20, which would take me a long time to collect. I'm also profiling the charging curves on my own device by the way.

Best regards

Matt

I understand your approach, and the fact you need data to get the charging curve.

But there is a problem, how to be sure that the charging curve is constant in the time (and I'm pretty sure it won't, problem is N900 has been released since a month only), and how to be sure that there are not (or there won't be) different models of battery ?

In addition to the data you'll get, the best is not to collect data on the phone where the application is installed at each charging, so the estimation will remain the closest of the reality ?

Hi

Actually there are quite a bunch of problems. First I have to figure out if the current voltage data can be used at all. My first impression is that it's quite jumpy but may be used after some pre-processing. Now for the doubts you mentioned, this may very well be an issue. I can run some kind of "goodness of fit" estimations to check the quality of my prediction, but this should ideally be ran on a variated sample instead of repeated measurements on my own device, hence I need as much data as possible.

I'm not sure if I understand what you mean here. Can you rephrase?

Regards, Matt

in addition to the curve you'll extrapolate to estimate the remaining charging time (e.g. starts charging with 35% @ 4040mAh equals 40 minutes remaining according to the charging curve) maybe you can collect data on the phone each time it's being charged, so that you'll generate a curve specific to the phone.

So you'll know that for this specific phone, 4040mAh equals 32 minutes remaining for this phone, instead of 40, because the last 10 chargings, on average, there was 32m remaining @ 4040mAh, 25m @ 4100, 15 @ 4150, 5 @ 4170.

And because a battery degrade in time, and a new firmware can also improve - or not - battery duration, your program will always be accurate.

I'm maybe wrong, but it's how I see the thing

Yes, this is precisely what I am intending. The plan is first to look at the data and inspect how variable it can be. Then to come up with a suitable algorithm/model for the prediction. That could either be rather simple (use measurements gathered at the beginning and during the charging process) or a little bit more tricky, with a learning element (prediction based not only on current charging process, but also on earlier charging processes on the local device to a certain extent). It all depends on the accuracy and variability of the data, that's why I'm trying to get as much as possible.

Once I come up with that algorithm, I can simulate the prediction for each profile that was handed in and decide whether it's enough accurate for productive use.

I believe that using some pre-computed parameter estimates based on the data from various devices within the actual program would not be very smart. (I think we agree on that point). The data is only for some early inspection, not to derive any actual numbers to be used in the program.

Matt