Active Topics
-
Sailfish OS for the Motorola Moto G7 Power (XT1955-5) - (ocean) (3)
to SailfishOS by edp17 - 6 hrs, 14 mins ago -
The N900 is now 15 years old! (6)
to Nokia N900 by Macros - 1 day, 10 hrs ago -
F(x)tec Pro1x (QWERTY) for sale (0)
to Buy & Sell by aln00000 - 1 day, 22 hrs ago -
n770 youtube video (0)
to General by nmdv - 5 days, 22 hrs ago - more...
 |
|
2014-02-02
, 07:09
|
|
Posts: 5,028 |
Thanked: 8,613 times |
Joined on Mar 2011
|
#2
|
Ironically, reflashing wouldn't help, at all. I think you just had >32 charging cycles since last calibration. For some reasons, device hadn't chance to calibrate itself automaticaly (maybe you were always charging it before it reached very low level/never let it shut itself down due to out of charge?).
To fix, you need to calibrate manually:
1. Charge battery to full, until VDQ flag turns to 1
2.
3. Use your device normally, but don't shut it down, charge, or reboot. Checking battery level manually, from time to time (battery applet *won't* give you correct readings, due to modules being not loaded). Always ensure that VDQ flag is 1, otherwise, you need to start back from scratch. Accidental reboot may or may not turn VDQ to 0, depending on circumstances.
4. When voltage drops to ~3300 mV, stop whatever you're doing on device and start monitoring it closely.
5. The goal now is to get under 3248 mV and stay there for at least 15 seconds, without voltage either going above, or too much under (less than ~2900 mV), causing device to "faint" due to low power. The most reliable - although, time consuming - way is to set screen to never dim, and/or enable flashlight - so device will consume steady ammount of current. Monitor voltage and VDQ.
6. When voltage dros below threeshold (3248 mV) and stays there for 15 seconds, VDQ will immediately turn to 0 and chip recalibrate.
7. Power device off via normal way, before it "faints" - if you miss that step, it *won't* spoil calibration, but you may get your /home filesystem corrupted. You better not miss this step, or you will give yourself quite a homework (see next steps). In case of failing it, for some reason, follow step 8. Otherwise, you're finished now - start using device normally.
8. (optional, in case of missing step 7)
This step require you to run latest cssu-thumb or cssu-testing. Precisely, it require updated e2fsprogs&friends, cause Maemo's vanilla ones were ancient and segfaulted mid-way, leaving filesystem in total mess.
Boot into any recovery console (backupmenu's one, Mentalist Traceur's one, Pali's one, etc), and:
a) If it says (amongst other things) "<filesystem name> clean" - with or without "recovering journal" before - and exits, you're good to go. Power off, and you're finished. Start using device normally.
b) If it informs about fixing some things, but exits cleanly, see point a.
c) If it ends with something like "Unexpected inconsistency, run FSCK manually", do:
Ensure, that path where you save log isn't any temporary directory (that will get nuked after boot), as you may really need that log later.
Where to save, depends on the recovery shell you're using. If you have rootfs mounted, /path/where/rootfs/is/mounted/var/log/fsck.log is a good place. Using backupmenu's root console (and *only* after mounting rootfs via 'mountroot' command), it is /tmp/mnt/rootfs/var/log/fsck.log, If I remember correctly (you can use auto-completion via TAB).
When it's finished, repeat this point (8) from the beginning, and follow approriate sub-point.
8.1. After you boot into Maemo, check fsck.log you've create in point 8 - it will contain (amongst other things), pathes to files that were repaired/salvaged (connected to lost+found) during manual fsck repair. Check every file's integrity individually. In case it "vanished", check /home/lost+found, it may be sitting there. In case of problems, determine which package missing file depend to, and reinstall whole package.
---
Appendix:
To check VDQ flag and voltage conveniently, either use bq27200.sh script, or package BNF (the latter is my favorite method, but no surprise here, as I've created it
).
Appendinx 2:
Don't get scared by ammount of text here - I tried to explain everything in details, and half of this (as it turned to be) tutorial is an emergency kit for worst-case scenario of filesystem corruption, due to device fainting of low power. By being at least basically aware of situation, you won't hit it, saving yourself half of this
Cheers,
/Estel
To fix, you need to calibrate manually:
1. Charge battery to full, until VDQ flag turns to 1
2.
Code:
modprobe -r bq27x00_battery modprobe -r rx51_battery
4. When voltage drops to ~3300 mV, stop whatever you're doing on device and start monitoring it closely.
5. The goal now is to get under 3248 mV and stay there for at least 15 seconds, without voltage either going above, or too much under (less than ~2900 mV), causing device to "faint" due to low power. The most reliable - although, time consuming - way is to set screen to never dim, and/or enable flashlight - so device will consume steady ammount of current. Monitor voltage and VDQ.
6. When voltage dros below threeshold (3248 mV) and stays there for 15 seconds, VDQ will immediately turn to 0 and chip recalibrate.
7. Power device off via normal way, before it "faints" - if you miss that step, it *won't* spoil calibration, but you may get your /home filesystem corrupted. You better not miss this step, or you will give yourself quite a homework (see next steps). In case of failing it, for some reason, follow step 8. Otherwise, you're finished now - start using device normally.
8. (optional, in case of missing step 7)
This step require you to run latest cssu-thumb or cssu-testing. Precisely, it require updated e2fsprogs&friends, cause Maemo's vanilla ones were ancient and segfaulted mid-way, leaving filesystem in total mess.
Boot into any recovery console (backupmenu's one, Mentalist Traceur's one, Pali's one, etc), and:
Code:
fsck /dev/mmcblk0p2 -f -p
b) If it informs about fixing some things, but exits cleanly, see point a.
c) If it ends with something like "Unexpected inconsistency, run FSCK manually", do:
Code:
fsck /dev/mmcblk0p2 -f -y -v >> /path/where/you/want/log/saved/fsck.log
Where to save, depends on the recovery shell you're using. If you have rootfs mounted, /path/where/rootfs/is/mounted/var/log/fsck.log is a good place. Using backupmenu's root console (and *only* after mounting rootfs via 'mountroot' command), it is /tmp/mnt/rootfs/var/log/fsck.log, If I remember correctly (you can use auto-completion via TAB).
When it's finished, repeat this point (8) from the beginning, and follow approriate sub-point.
8.1. After you boot into Maemo, check fsck.log you've create in point 8 - it will contain (amongst other things), pathes to files that were repaired/salvaged (connected to lost+found) during manual fsck repair. Check every file's integrity individually. In case it "vanished", check /home/lost+found, it may be sitting there. In case of problems, determine which package missing file depend to, and reinstall whole package.
---
Appendix:
To check VDQ flag and voltage conveniently, either use bq27200.sh script, or package BNF (the latter is my favorite method, but no surprise here, as I've created it
).Appendinx 2:
Don't get scared by ammount of text here - I tried to explain everything in details, and half of this (as it turned to be) tutorial is an emergency kit for worst-case scenario of filesystem corruption, due to device fainting of low power. By being at least basically aware of situation, you won't hit it, saving yourself half of this
Cheers,
/Estel
__________________
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
| The Following 5 Users Say Thank You to Estel For This Useful Post: | ||
|
|
2014-02-02
, 17:19
|
|
Posts: 48 |
Thanked: 39 times |
Joined on Aug 2010
@ Netherlands
|
#3
|
Thanks for the excellent reply. I will let you know how it works out.
[EDIT] Can I trust the N900 to actually stop charging once the battery is full? Might be a silly questions, but I'm slightly concerned about it.
Last edited by LavaCroft; 2014-02-02 at 18:31.
[EDIT] Can I trust the N900 to actually stop charging once the battery is full? Might be a silly questions, but I'm slightly concerned about it.
Last edited by LavaCroft; 2014-02-02 at 18:31.
| The Following User Says Thank You to LavaCroft For This Useful Post: | ||
 |
|
2014-02-02
, 18:54
|
|
Posts: 6,447 |
Thanked: 20,981 times |
Joined on Sep 2012
@ UK
|
#4
|
Originally Posted by LavaCroft
Yes. (10 chars)
Can I trust the N900 to actually stop charging once the battery is full?
__________________
Русский военный корабль, иди нахуй!
Русский военный корабль, иди нахуй!
|
|
2014-02-02
, 23:23
|
|
Posts: 48 |
Thanked: 39 times |
Joined on Aug 2010
@ Netherlands
|
#5
|
The process seems to have worked. Thanks a lot.
About your hunches as to why it happened, both the >32 recharge cycles and the 'always charging' ideas were correct. I will have to keep this in mind for the future.
About your hunches as to why it happened, both the >32 recharge cycles and the 'always charging' ideas were correct. I will have to keep this in mind for the future.
| The Following User Says Thank You to LavaCroft For This Useful Post: | ||
|
|
2014-02-03
, 05:37
|
|
Posts: 5,028 |
Thanked: 8,613 times |
Joined on Mar 2011
|
#6
|
I' glad it have worked for you 
As for >32 cycles, yea - it is good idea to let it, from time to time (like, once or twice in month) - discharge 'till shutdown, so it will update it's calibration data, and won't hit threeshold anytime soon.
Of course, it only makes sense if VDQ is 1 during that discharge (when battery is low and you think "heck, I could let it discharge now", just check if VDQ is still 1), otherwise it won't recalibrate. Just be sure to not have any unnecessary applications running, when expecting to let it shutdown itself. Standard Maemo stuff is OK, doesn't need to deliberately kill things from terminal.
Obviously, by "discharge and shutdown", I mean doing so with bq27x00_battery and rx51_battery modules *loaded*, so it will shutdown safe way, just after recalibrating - *not* letting it fade out due to low power at ~2900 mV, with modules unloaded (otherwise, points 8+ from previous post, aka "filesystem corruption", apply ).
/Estel
Last edited by Estel; 2014-02-03 at 05:41.
As for >32 cycles, yea - it is good idea to let it, from time to time (like, once or twice in month) - discharge 'till shutdown, so it will update it's calibration data, and won't hit threeshold anytime soon.Of course, it only makes sense if VDQ is 1 during that discharge (when battery is low and you think "heck, I could let it discharge now", just check if VDQ is still 1), otherwise it won't recalibrate. Just be sure to not have any unnecessary applications running, when expecting to let it shutdown itself. Standard Maemo stuff is OK, doesn't need to deliberately kill things from terminal.
Obviously, by "discharge and shutdown", I mean doing so with bq27x00_battery and rx51_battery modules *loaded*, so it will shutdown safe way, just after recalibrating - *not* letting it fade out due to low power at ~2900 mV, with modules unloaded (otherwise, points 8+ from previous post, aka "filesystem corruption", apply
)./Estel
__________________
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
Last edited by Estel; 2014-02-03 at 05:41.
| The Following 3 Users Say Thank You to Estel For This Useful Post: | ||
|
|
2017-09-01
, 10:01
|
|
Posts: 10 |
Thanked: 8 times |
Joined on Aug 2017
|
#7
|
Originally Posted by Estel
I've tried this method, but before 3248mV my phone will auto-shutdown. Did it means that modprobe -r doesn't work ? Or something else in the system did auto shutdown to prevent corruption?
Ironically, reflashing wouldn't help, at all. I think you just had >32 charging cycles since last calibration. For some reasons, device hadn't chance to calibrate itself automaticaly (maybe you were always charging it before it reached very low level/never let it shut itself down due to out of charge?).
To fix, you need to calibrate manually:
1. Charge battery to full, until VDQ flag turns to 1
2.
3. Use your device normally, but don't shut it down, charge, or reboot. Checking battery level manually, from time to time (battery applet *won't* give you correct readings, due to modules being not loaded). Always ensure that VDQ flag is 1, otherwise, you need to start back from scratch. Accidental reboot may or may not turn VDQ to 0, depending on circumstances.Code:modprobe -r bq27x00_battery modprobe -r rx51_battery
4. When voltage drops to ~3300 mV, stop whatever you're doing on device and start monitoring it closely.
5. The goal now is to get under 3248 mV and stay there for at least 15 seconds, without voltage either going above, or too much under (less than ~2900 mV), causing device to "faint" due to low power. The most reliable - although, time consuming - way is to set screen to never dim, and/or enable flashlight - so device will consume steady ammount of current. Monitor voltage and VDQ.
6. When voltage dros below threeshold (3248 mV) and stays there for 15 seconds, VDQ will immediately turn to 0 and chip recalibrate.
7. Power device off via normal way, before it "faints" - if you miss that step, it *won't* spoil calibration, but you may get your /home filesystem corrupted. You better not miss this step, or you will give yourself quite a homework (see next steps). In case of failing it, for some reason, follow step 8. Otherwise, you're finished now - start using device normally.
8. (optional, in case of missing step 7)
This step require you to run latest cssu-thumb or cssu-testing. Precisely, it require updated e2fsprogs&friends, cause Maemo's vanilla ones were ancient and segfaulted mid-way, leaving filesystem in total mess.
Boot into any recovery console (backupmenu's one, Mentalist Traceur's one, Pali's one, etc), and:
a) If it says (amongst other things) "<filesystem name> clean" - with or without "recovering journal" before - and exits, you're good to go. Power off, and you're finished. Start using device normally.Code:fsck /dev/mmcblk0p2 -f -p
b) If it informs about fixing some things, but exits cleanly, see point a.
c) If it ends with something like "Unexpected inconsistency, run FSCK manually", do:
Ensure, that path where you save log isn't any temporary directory (that will get nuked after boot), as you may really need that log later.Code:fsck /dev/mmcblk0p2 -f -y -v >> /path/where/you/want/log/saved/fsck.log
Where to save, depends on the recovery shell you're using. If you have rootfs mounted, /path/where/rootfs/is/mounted/var/log/fsck.log is a good place. Using backupmenu's root console (and *only* after mounting rootfs via 'mountroot' command), it is /tmp/mnt/rootfs/var/log/fsck.log, If I remember correctly (you can use auto-completion via TAB).
When it's finished, repeat this point (8) from the beginning, and follow approriate sub-point.
8.1. After you boot into Maemo, check fsck.log you've create in point 8 - it will contain (amongst other things), pathes to files that were repaired/salvaged (connected to lost+found) during manual fsck repair. Check every file's integrity individually. In case it "vanished", check /home/lost+found, it may be sitting there. In case of problems, determine which package missing file depend to, and reinstall whole package.
---
Appendix:
To check VDQ flag and voltage conveniently, either use bq27200.sh script, or package BNF (the latter is my favorite method, but no surprise here, as I've created it
Appendinx 2:
Don't get scared by ammount of text here - I tried to explain everything in details, and half of this (as it turned to be) tutorial is an emergency kit for worst-case scenario of filesystem corruption, due to device fainting of low power. By being at least basically aware of situation, you won't hit it, saving yourself half of this
Cheers,
/Estel
My battery only detected as 13xxmAH but actually it 2000mAh.
Please help
|
|
2018-11-11
, 19:11
|
|
Posts: 188 |
Thanked: 223 times |
Joined on Apr 2013
@ Poland
|
#8
|
I will revive a thread a little bit as I got new batteries for two units and have been struggling to get them calibrated. Disabling both the bq27x00 and rx51 battery modules does't seen to prevent the device to shut down automaticly I think the bnf is doing this.
Although I've calibrated one battery after voltage dropes somewhere below the 3248 and device shut down (Not fainted) I recharged it with both mentioned modules In -r mode and now it is working fine with bq27x00 module.
The second one (Same new battery, same manufaturer) show that it's got 868mAh, charge to 660 (Each and every time) and got discharged in very slow way. Battery seems to have good, original capacity but I've found no way to calibrate it.
I will try it later with some scripts I need to work on first without the bnf. We will see.
Although I've calibrated one battery after voltage dropes somewhere below the 3248 and device shut down (Not fainted) I recharged it with both mentioned modules In -r mode and now it is working fine with bq27x00 module.
The second one (Same new battery, same manufaturer) show that it's got 868mAh, charge to 660 (Each and every time) and got discharged in very slow way. Battery seems to have good, original capacity but I've found no way to calibrate it.
I will try it later with some scripts I need to work on first without the bnf. We will see.
|
|
2018-11-11
, 19:14
|
|
Posts: 188 |
Thanked: 223 times |
Joined on Apr 2013
@ Poland
|
#9
|
Originally Posted by felangga
If it is not the double battery (Like the mungen one) I can assure you it doesn't have 2000 mAh, Those are only the numbers to get you to buy this particular one
(...) My battery only detected as 13xxmAH but actually it 2000mAh.
Please help
| The Following User Says Thank You to Ridd92 For This Useful Post: | ||
|
|
2018-11-12
, 20:11
|
|
Posts: 188 |
Thanked: 223 times |
Joined on Apr 2013
@ Poland
|
#10
|
How does this battery calibration works from dvice point of view? Is it just some software/hardware adaptation? Because it looks like it is some fixed information in battery that I can't get around. I know it sound silly, but each of my units now shows that battery is 660/660 mAh trough out at least half of battery's charge. Some else expirienced this?
 |
| Tags |
| battery, bme replacement, cssu thumb2 |
«
Previous Thread
|
Next Thread
»
|
All times are GMT. The time now is 19:15.
Running CSSU-thumb2, BME replacement and using the pali-recommended "modprobe -r rx51_battery".
Charging to green LED and/or rebooting does not fix it. Modprobe rx51_battery gives some numbers, but they are the wrong numbers.
Trying to recalibrate the battery with the bq27x00_battery module gives a "resource or device busy", without it the calibration script gives a read error on one of the cat commands.
Is there any way, short of reflashing, to just get this to work again?
Thanks in advance!
Last edited by LavaCroft; 2014-02-02 at 23:25.