Overriding battery.reporting.design
 

Hey everyone,

I searched around but haven't found an answer; does anyone how (in code) battery.reporting.design is calculated?

I'm trying to figure out a way to hardcode it to 2400mah for my Mugen battery. I presume HAL calls some binary which reads it from the kernel.

Re: Overriding battery.reporting.design
 

Sorry, I don't know how it works in Maemo, but not long ago I had a look at the code of LXDE's battery monitor. It relies indeed on virtual files provided by the kernel's acpi interface, and I guess that would be the most reasonable approach for any other battery monitor.
Unfortunately these pathes are hard-coded into LXDE's battery-monitor and I think it's the same for other monitors too. So you'd have to change the code and compile the monitor of your choice on your own instead of an easy way like just reassigning some environment variable.

btw: There is a way to export the battery status to the /sys filesystem if you use the power kernel, but I'd have to search for the link.

Re: Overriding battery.reporting.design
 

Why don't code a battery monitor based on millivolts? Sorry if it is noobish but it's the only way I can estimate the residual charge of my Mugen. Presently, it is constrained between 4180 and 3531 mV (as read by the Batterygraph app). The lesser the voltage, the lower the charge. Or not?

Re: Overriding battery.reporting.design
 

I'm not an expert here, so I might be wrong, but afaik the voltage change is not linear. It stays pretty constant for a long time (70% or 80% of the discharge process?) and then drops relatively fast during the rest of the discharge process. At least this is what I see in my netbook.
Maybe the Mugen battery behaves differently, or maybe this non-linear function can be modeled easily, but it's not as trivial as looking at the charge.

Re: Overriding battery.reporting.design
 

Well, non-linearity could be a problem if you were to estimate the time left to shutdown, but then that would depend on average use as well, so I think it would be too rough to be useful.
Also my battery graph charts don't have the shape you describe, and contrarily seem to decrease linearly from the very top. So a millivolt-based meter might be feasible to estimate charge level imho.

Re: Overriding battery.reporting.design
 

The voltage also changes depending on how heavily the device is being used, although I imagine the fluctuation would be less on the Mugen compared to the normal battery. dr_frost_dk made a queen beacon script to convert voltage to a percentage and display it, you can find it in his Battery Mod thread. I took that script modified it to include date and the battery percentage the N900 reports itself and I run it periodically, here is some sample output from yesterday, note at the time of the first reading I was connected via 3G and I wasn't for the second and also I was constantly playing music for almost all of the two hours between the readingsSo with his script based solely on the voltage my battery gain was 0.6% after two hours music playing, instead of the more realistic 17% decrease. You might still find it useful, but bear in mind that the voltage fluctuates a bit so it won't be terribly accurate.

Re: Overriding battery.reporting.design
 

i have made a script based on real discharge graphs

it is based on idle voltage but it works really well

http://talk.maemo.org/showpost.php?p=872446&postcount=3

Re: Overriding battery.reporting.design
 

Oh hey guys.. :) Sorry I should have mentioned that the battery meters all work perfectly. This was purely so HAL would report the right capacity in my lshal | grep battery script.

It has no other value whatsoever.. :)

Re: Overriding battery.reporting.design
 

That's the script I mentioned in my previous post.:) Do you call showing a marginal increase after two hours music playing "working well"? Although it is useful when the battery is running low, the inbuilt reading seems to under-report when the battery is low.