Notices

Temperature: 43°C. Current: 75 mA. Combination of ambient temperature (read: heatwave), fan of nearby desktop computer, and on-principle-not-turned-on air-conditioner. No applications running on N900, except cellular GSM connection.

Sadly, there is no way to write battery data into bq27x00_battery chip - only possible way is calibration. there *is* a way to force learning capacity a little earlier than usual, but it's complicated, time sensitive, and completely not-worth-effort, compared to learning cycle.

So, saving and loading battery profiles won't be possible, due to hardware restrictions.

I haven't had idea about that. In early days, when first version of script was created (read: at least a year, or more, before I decided, that others may enjoy using it too, then moved my a** to package it and share through repos), I was switching between running it and bq27200.sh script. I needed a name that start the same way - so auto-completion via tab will show me both scripts - but is easily auto-completed to the end, with just 2nd letter provided. So, I've added "n" as "new" or "next", and "f" as a random letter. Despite unusual way of creating name, it got used to it, so I've kept it that way.

Unfortunately, I'm not GUI coder at all (or any real coder, if we stick to facts ). I'm all for other projects using BNF code/inspiration to achieve something, or just learn basic scripting by reading it - that's why BNF is very heavily commented in-code - but, it was meant to be ultra-lightweight way of having all major bq27x00 chip information at a glance, bindable to hardware button (allowing use in fullscreen programs too, without minimizing them). So, control panel applet is out of scope for this project.
---

It have been some time, since Pali fixed bq27x00_battery module, and released beta of his and freemangordon's BME FOSS Replacement kit. bq27x00_battery is loaded automatically, as a integral part of replacement solution. Hoever, one problem with bq27x00_battery - from bnf's perspective - is that it blocks access to i2c data. there *is* a way to access it simultaneously, via i2c_slave - but it's complicated, and no one is sure, if perfectly safe. Other than that, fixed bq27x00_battery is blessing, as it allows hassle-free access to most data provided by chip, as sysfs (and less hassle-free access to rest of them, via raw registers).

Some time ago, I've promised to release bnf that will work with bq27x00_battery, if it get fixed/incorporated into BME replacement. Hoever, I'm sure, that not all of bnf users want to jump into replacement bandwagon just yet (it's quite devel'ish in full sense of word) or at all, preffering i2c method (reinob, I'm thinking about you, especially )

So, I've created a new version of bnf, that works for *both* bq27x00_battery, and "old" i2cget method. It determines if user have bq27x00_battery loaded and if yes, use it - otherwise, transparently switches to i2cget method. For ease of maintaining, I've divided it into 3 scripts now - "bnf" which only does module checks, and then, run either "bnf-bq27x00" or "bnf-i2c". Of course, I could still keep it as one file (more than 2x as big as before), but I feel it's more cleaner this way. Also, for those of you, that only use one method, and never plan to use another, you may just delete unneeded file (and/or rename *needed* one to "bnf", replacing controller script).

If When autobuilder and repos ever start really working again, I'll update version in extras-*. Until then, you may download drop-in replacement .tar from this (and opening) post attachment - just untar it to /usr/sbin/, replacing old file.



Changelog:

• Uses either bq27x00_battery module, or i2cget method, transparently deciding which one is applicable.
• New value - "Average Time Remaining", which shows remaining time, calculated from averaged power usage since last complete charging.
• Minor code cleanup + more things commented for easy code understanding, even for sh beginners.

Happy using!

/Estel

As repositories are up again, bnf 1.2 has been just queued for loading into fremantle extras-devel repository. Changelog:

• Fixed typo in sudoers file (bnf.sh was present, instead of bnf)
• Back in the repos, a they're working again

It's a minor release, which contain changes since last repo version, plus fix for sudoers file - users of 1.1 tar-only release, please update too. All people that experience problems with bnf running as root only (failing from user sudo), should be OK now - there was a typo in sudoers file. I have no idea, why it worked on some devices (including mine), despite that error.

/Estel

I have just returned to my N900 after flirting with some other devices. Installed a new polar 1500 mAh battery. It was charged three times before I found this post while updating the device with all the great stuff people have come up with since I last looked.

Installed bnf. No problem. Followed the excellent calibration post - everything happened exactly as you said.

Now on the second discharge cycle. Full Charge has gone from 2000 mAh (or something - i did not take a screen shot) down to 1782 mAh and I suspect, as you say, that another one or two calibration cycles will bring it down the the real capacity.

My question is: On the charge after the first calibration cycle I was monitoring the device using bq27200, bnf and grepping the battery stats. I unplugged the device when bq27200 and bnf said the battery was 100% full. I did this as I was not sure and could not find any info to the contrary. However the battery stats showed that the battery was only at 66% charge!! The battery was still charging and flashing the orange LED. BUT shortly after being unplugged when I checked again - showed 97%.

So should I leave the charger connected until i get the green LED or should I do what I did and remove the charger when bnf shows that battery to be full (with the expected mV values etc)?

I am not using and special charge scripts like charge21.sh. Just bme. I also could not find a post giving a real insight into the pros and cons of stopping bme and using charge21. (Apart from not having the automatic shutdown happen before you get EDV1 = 1 which i have not had a problem with)

What do you mean by "battery stats"? Anyway, when calibrating to *lower* capacity that your LMD/ILMD (like, in your case, single polarcell, from 2000+ mAh), unplugging at green led should be OK. If you would be, OTOH, calibrating from lower to higher capacity, you should monitor via bnf or bq27200.sh and count minutes*mA (like written in calibration post), to avoid getting hit by limit of calibration capacity change.
---

From "different barrel" - I've found some problems with BME + bq27x00_battery combination, when device is plugged in and charging ended already. Nothing serious - it just doesn't work then, due to Pali's bad design decisions about bq27x00_battery sysnodes (When charging ended, bq27x00_battery stops exporting some sysnodes, causing read_erro,r when trying to access them).

Sadly, same happens when battery is uncalibrated and bqx00_battery loaded - for same reasons. Pali seems confident into keeping it that way to maintain compatibility with upstream bq27x00_battery, which I see as plain wrong (sysfs nodes should *always*.report what hardware gives, not censor data, due to someone's idea that it may be good thing).

Workaround for that is to unload bq27x00_battery, when device is not calibrated. Due to it's being PITA, I plan to rewrite BNF again, to only use i2cget, even when bq27x00_battery is loaded - fortunately, I2C_FORCE_SLAVE allows for safe accessing i2c values of bq27x00 chip, even if bq27x00_battery.ko access them already (due to bq27x00_battery module reads being atomic).

This should fix both problems mentioned above.

/Estel

I am going from an old polar batttery (1400mAh) to a new one. The 2000- mAh value was already shown in bnf the first time i ran it and it seems to be going down towards 1500 which would of course be correct.

By Battery stats I mean the info obtained when the command lshal|grep battery

So what i did was correct - unplugging the charger when the bnf showed SOC 100%?

What difference would it make to leave the cahrger connected until the green LED is shown?

As I am technically going from a lower capacity to a higher capacity BUT the phone had this higher capacity (2487 or whatever) stored already and I am now working down from that to the genuine capacity!! Don't know how this situation arose but I think that is the nature of the beast!!

**Additional - found this on page 82 of the battery mod thread "The N900 actually has a chip that can do this capacity measurement and tracking, but it's unused, and the OS shuts down before 6% level at which the chip updates/"learns" battery capacity, so it's stuck at 2048mAh on most N900s. - shadowjk"

Perhaps this 2048 is the value that my phone started with as "default".

Yes, 2048 is the default value (aka ILMD), which chip have set, if lost calibration data for some reason.

As for that wiki info, it's outdated - we're using exactly this chip for bnf, and kernel-power module bq27x00_battery uses it, too. Whole BME replacement is also using this chip.

BTW, "shutting down before calibration" wasn't entirely true, either. old, vanilla BME used sophisticated algorithm to "guess" when low voltage spikes could affect GSM modem, and shutdown then - so, it wasn't shutting down at certain treesholds. For most intents and purposes, it indeed was shutting down before EDV1, although, with some patience (and masochists nature), it was possible to calibrate with BME running. The bigger capacity/more cells battery had, the more stable voltage was at near edv1, so it was easier with dual cell setup.

Anyway, now those problems are gone - upcoming bme replacement will ensure, that calibration was done, before shutting down.

/Estel

Thank you sir. That has completed the lesson!

And, for the benefit of other readers I found Estel's advice based on his being a "fanatic of accurate measurement" when charging - also useful when discharging to ensure the EDV1 value changes before shutdown. Turn GSM off, close all apps, run bq27200 5 in terminal and (this is the twist) if you need to use a bit more charge to get you down to 3248 mV up the screen brightness for a few seconds and then drop it back down to minimum, monitoring the battery charge with the bq27200 5. I found it extremely easy to get the desired 15 second result without bme getting in the way.

Hi. Installed bnf from repos 3 days ago. it worked at first but now its not working. When i launch it from menu via bnf icon. it shows nothing and when i launch it via terminal it gives me error.

any suggestions ? removing and re-installing doesn't work

It fails due to things I've just described - bq27x00_battery module is loaded in your system, and for some reasons, your chip started to report itself as requiring calibration - either device was without battery for a while, or you had more than 32 cycles since last calibration.

Due to - IMO, and in opinion of anyone even remotely related to BME replacement, that I've talked to - bad design decisions by Pali, bq27x00_battery stop exporting few sysf nodes *at all*, when battery isn't calibrated - causing "read errors", despite, that chip itself is still providing proper values. It means, that after 32 charging cycles, perfectly fine data will get dropped all-together.

I tried (and other people too - in fact, there is no one, except Pali, that think current approach is good), to convince Pali that in linux world, sysfnodes should *always* report what hardware reports, instead of censoring it for whatever reasons (not that here we have any good reasons, too). Sadly, he is very stubborn, and no luck here. You may try your luck at pestering him.
---

For now, only workaround is to modprobe -r bq27x00_battery (BNF will switch to i2cget access), or calibrate your battery.


As said, in next version, BNF will switch back to i2c-only access, that will work even with bq27x00_battery module loaded, though (due to I2C_FORCE_SLAVE and bq27x00_battery reads being atomic)

/Estel