Release SuperZaxxon Final released!


I found the latest firmware to be a hive of bugs concerning the battery charge... anyway I didn't had the time to analyze every situation, so I just found the "solution", hoping that .next will be better in that...
[…] when the chip decides battery is full by itself (based on current flowing through the charger) […]

Maybe my new wall-charger is "too strong" (5V, 2.5A) and this causes the power-chip to preliminary suspend charging?


What would logically fit to that assumption, is that under SuperZaxxon Final my USB-charger (supplying 5V, 1.0A, don't know how much the Pandora let's through) always charged until 100%.

When I have to charge I do a reboot, attach the cable even without closing the lid, then, after the red light is on, I can close the lid, BUT I don't put in low power mode while charging, or is a mess... doing this I always have a perfect 100% without red light in the morning.
Will try that hint if I get my Pandora back from repair.

Anyway I want to underscore something I wasn't aware of and I found in these hot days:


if the battery temperature is too high the charge wont start !!


If after inserting the charger cable the red light stays off, try to type "dmesg" in the terminal to see if there's some battery related message.
Will observe that as well!
 
Last edited by a moderator:
Notaz: I just sent in my Pandora for repair (purple tint of death, left shoulder button broken, microphone not working, USB large connector with loose contact), so now would be the chance to give additional instructions ED on doing power-chip related repairs, i.e. replacing the fore-mentioned wrong resistor. Are there already some official learnings on this, instructions to forward to ED's repair center?
It's just a hypothesis WizStan once brought up, I only mentioned it as an example of possible other reasons for the problem. And it's not about the wrong resistor, it's natural resistance between battery and pads on pandora that could be causing this. PowerGod mentioned above that it could be also caused by the chip thinking the battery is overheating for some reason. It's a complicated problem.
 
Ok. So I have to accept that the Pandora still has some flaws ("child diseases") concerning basic functionality, such as charging, and requires some overseeing/help ("parenting") and active involvement, such as informing yourself in the community, hacking around until things work, etc.


To some degree, I also love this aspect ;-). Would OP be a commercial project, I would not accept such flaws, but as an open source handheld, this is tolerable, considering all the good community vibes & free software which you get! Its main strength to me!


Still, I am looking forward to the day, where the OS is in a state, where basic functionality is not a work in progress but complete, and the development can focus on feature additions!
 
Last edited by a moderator:
Notaz: I just sent in my Pandora for repair (purple tint of death, left shoulder button broken, microphone not working, USB large connector with loose contact), so now would be the chance to give additional instructions ED on doing power-chip related repairs, i.e. replacing the fore-mentioned wrong resistor. Are there already some official learnings on this, instructions to forward to ED's repair center?
It's just a hypothesis WizStan once brought up, I only mentioned it as an example of possible other reasons for the problem. And it's not about the wrong resistor, it's natural resistance between battery and pads on pandora that could be causing this. PowerGod mentioned above that it could be also caused by the chip thinking the battery is overheating for some reason. It's a complicated problem.

Just to add something to chew on the battery heat thing, I think that the problem can be related to the USB port, I know that it is used to sink the CPU heat, but if something is inserted on that port, like a wifi dongle, the heat can't go out easely.


When the "overheat" message appear in dmesg, the battery itself doesn't seems hot (when it's charging it's hotter than this), but If I put a hand near the USB, well, THAT IS HOT !!
 
Last edited by a moderator:
It sucks that you have these charging problems - with my Pandora it works just fine (on any version of the firmware, well since SZ beta 4 or so, I never tried anything older), so it's probably not a software problem, although of course it is possible that depending on the software, the hardware problems are better or worse. Maybe software workarounds are possible for the hardware problem you're experiencing, but it's hard for people like notaz and WizardStan to find such solutions if the problem is rare like yours.


One thing I have noticed though is that in one of the SZ betas, charging became much faster than before. Maybe this causes problems (e.g. because the battery reaches higher temperatures). For me, the faster charging is very nice. But maybe it would be better for you to disable it somehow and use only slow charging...
 
Another MiniMenu bug also re-appeared in SuperZaxxon Final:


If you remove a SD card, MiniMenu scans forever (in an infinite loop), thus gets unresponsive.


As soon as you re-enter the SD-card MiniMenu recovers.


Removing and reinserting works fine in XFCE, no such troubles.


So I guess the bug is rooted not within libpnd but MiniMenu.

What, really?


Do you mean ..


- when you take out SD while already in mmenu


- or, booting without it?


I will have to check.. I woudl be surprised that is a problem!


I hope to have a few small patches soon, so I'll check and fix if needed ASAP :)


jeff


edit: I just booted into minimenu with no SD cards, and no problem; which firmware version you're on.. SZFinal for sure? I'll have to reflash, maybe some setting causes it..


edit 2: FWIW, I'll be submitting a patch ASAP so that in the event of a recycling crash in mmenu, it'll switch to conservative settings.. ie: default skin, no selected app, that sort of thing.
 
Last edited by a moderator:
Do you mean ..


- when you take out SD while already in mmenu


- or, booting without it?
In both situations! In SuperZaxxon Final. (The version 2012-07-03, not the minor updated version v1.51, have not tested this one yet).


Currently my Pandora is in for repair, so I cannot test anything.


Slightly possible, it also has to do with the circumstance, that I once ran a "Cache all preview pictures to SD card". Don't really see the connection, but wanted to mention it, so that you don't need further re-inquiries from me.
 
Last edited by a moderator:
There are two chips in the Pandora for battery control, the TWL actually does the charging (and a lot of other things, too) and the BQ gives us a fuel gauge. The TWL charges the battery by monitoring voltage and dumping current into it; when the battery reaches 4.3 volts, it is "full" at which point the TWL slows the charge rate and starts monitoring resistance on the battery to top it off. As the battery fills, the resistance increases and the amount of power required by the system decreases. When this reaches a certain threshold (drop below 80ma), it triggers a full battery alert and stops charging. There was a theory that because of the new ultra efficiency that Notaz was able to get us, the power required to actually run the system would sometimes drop so low that it would make the TWL think the battery was full. There is some merit to this, you may be able to test it yourself: if you charge the battery until it reads 100% (but continues to charge beyond this point to top it off) and then start getting it to do something to waste a bit of power (turning the LCD brightness up to full should be enough) it should never stop charging, even hours later, because the TWL is still detecting a high power usage; close the lid, the LCD shuts off, power consumption drops below the threshold and it stops charging within seconds (sometimes). That's one of the places the software shut off comes in. In any case, this hardware cut off doesn't happen until it reaches 4.3V anyway.


Voltage measurement isn't a very good way of accurately detecting how much power is left in a battery though: if you increase the load substantially, it can have an effect of pulling the detected voltage down; release the load and the voltage jumps back up. Even in normal operation, you can get swings of up to 10% difference depending on what you were doing. It can be a good starting estimate, but I doubt people would be happy if the gauge in the bottom corner made jumps from 90 to 80% suddenly just because they started PCSX.


That's where the BQ chip comes in. It tracks current in and out of the battery directly. As the TWL is charging, the BQ is recording the amount of current going into the battery. The BQ is supposed to know how much current total the battery can hold, so as it records current going into the battery (and coming out of it) it can calculate the amount of power left in the battery and an accurate estimate of how much time it would take to complete the (dis)charge at the current rate. When I got my second Pandora, I noticed it would have problems reaching 100%: it would get to about 83% and then stop. On some occasions I would turn it on and it would be 100%, but then discharging it would reach about 18% and suddenly the battery was empty and it would die. My theory goes that there is a small bit of corrosion on the contacts of the recent CC Pandoras (from having been sitting around unpopulated for months), not enough to cause major problems, but enough to change the resistance between the battery and the BQ chip ever so slightly. This increased resistance means that the BQ is detecting less current going into and out of the battery than there actually is, so when the TWL has successfully reached 4.3V and has actually dumped 4000ma into the battery, the BQ has only detected, say, 3300ma. TWL stops charging, BQ only reads 83%, people complain. The reverse could also be true: if it someone does reach a point where it knows the battery is full, you can use up the full 4000ma but the BQ has only recorded 3300ma or so: the Pandora shuts down even though the gauge still reads 17% remaining. I "fixed" mine by sending it through several charging cycles until the BQ chip "learned" that there was only 3300ma in the battery (the battery was still 4000ma, just the BQ couldn't figure that out anymore).


If I'm right, this is strictly a hardware problem that has the potential to affect only CC boards released in the last 6 months (maybe as far back as 12 months? I'm terrible with time frames) or so. Older CC boards were soldered before corrosion could begin, and new GC boards are all brand new and being handled properly so no fear there. In any event, there is absolutely nothing in the software that would change any of this behavior, it is all done in hardware and the new kernel shouldn't make a difference.


Oh, new theory! What if, in the old kernel, the power consumption is high enough that the TWL never stops the charge? The TWL keeps dumping power into the battery long after it is full, the BQ keeps tracking this inbound current and raises the meter, the battery is overcharging and releasing most of the excess as heat, until it finally reaches 100% and the software control kicks in and shuts it down. This is the very reason the software daemon was required, on some Pandora's the battery would be full but because of system load the TWL couldn't detect it, so the BQ stepped up and forces it to stop before damage can occur. Maybe under the new kernel the power consumption is low enough that the TWL properly detects the end of charge when it happens, even if that is the point where the BQ chip only reads 83%.


To do a complete learning cycle, you need to charge the battery to full (ie, until the TWL stops charging, even if the BQ doesn't say 100%) and then immediately shut down the Pandora completely. Leave it off for at least 5 hours. Turn it back on and begin a discharge cycle. I turned my brightness up to full, wifi on no power saving, running a tight while loop and a background wget downloading a huge file into /dev/null and it only took 6 hours. Once it reaches 3V, the system will shut itself down to save itself. Let this happen, leave it off for at least 1 hour before plugging it in to charge back to full. You may need to repeat this 2 or 3 times before it learns.


Again, I think the problem isn't with software or the battery, I think the problem is that the BQ chip isn't accurately detecting the current going in or out of the battery due to changes in resistance. It's really sensitive to that. Even though it claims 83% when it stops charging, it should still give you the same 10+ hours of use that the rest of us are getting, it just doesn't know it. Since correcting my BQ meter (properly, there's a bit of story in my adventure in trying to fix this ;) ) I haven't had any problems, I get full 10-14 hours of use out of my Pandora right alongside my first one doing the exact same work so at the very least this is going to be some people's problem, though maybe not everyone's.


TL;DR; if you're in a situation where the battery doesn't seem to be charging past 85% (or so, it will vary) fully "charge" your Pandora until it stops, immediately shut down and leave it off for at least 5 hours. Turn it back on and discharge until it shuts down, leave it off for at least an hour before plugging it in to charge back to "full". You may need to do this 2 or 3 times but it will eventually figure out where 100% is.
 
Last edited by a moderator:
@EvilDragon: My Pandora is on the way to you for repair. You can use the opportunity to study a device, which is affected from the fore-mentioned charging issues. WizardStan provided a detailed description, hope that helps.


@WizardStan: Thanks for this massive assessment!


I hope that this and the follow-up will bring the solution!


In order to verify/falsify/complete your theory, I'll give you my facts. Hope that helps:

  • My Pandora: CC, 256MB RAM, delivered 2011-05, SN: 090001002037, battery SN: 1609.
  • Delivered 2011-05, somehow contradicts your corrosion idea.
  • I am indeed very economical with my power usage (default: no USB, BT and WiFi; LCD brightness quite dim, guess 60%). This and kernel 3.2 being much more power efficient than 2.x. Backs up your theory that the drain may be so low, that the chip makes false conclusions regarding charging. Never had charging issues under kernel 2.x!
  • In all occurrences where charging unexpectedly stopped preliminary, in most cases around 60-70%, the lid was closed! So the device must have reached low power mode. I did definetely NOT set it into sleep mode, as charging while in sleep mode caused even more troubles AFAIR, at least in earlier versions.
  • I once experienced an emergency shutdown although the gauge read ~ 10%. This backs up your theory, that the BQ chip had a wrong assessment.
  • When taking out the battery and re-inserting it, the gauge value sometimes dropped/increased by 5-15%. Also after some restarts this revised gauge values occurred.


Hint for chip calibration:

  • As I reported, taking out the battery did some good. But not permanent.
  • With your chip calibration hint, which is more systematical (coming from knowledge) rather than my guesswork (just trial'n'error) I may eventually succeed. Maybe ED experiments with my device at his repair center. Or I will try as soon as I get my device back.
 
Last edited by a moderator:
Delivered 2011-05, somehow contradicts your corrosion idea.
I've been told my sense of the passage of time borders on insane. My sister is apparently 6 months pregnant (she told me yesterday), and I've been saying she's 3 months pregnant for 3 months now, so yeah, take that specific timeline with an ounce of salt. I can't remember how long it's been that CC was trying to clean up those corroded boards, but it could very well be over a year and a half now.
 
There are 2 charge stop / overcharge protection mechanisms in effect now - hardware controlled, when the chip decides battery is full by itself (based on current flowing through the charger) and software controlled, a daemon watching the charge meter to reach 100 and charge current to drop sufficiently. We used to have the hardware one only, but it turned to be unreliable and not ever stop charging for some people, puffing (damaging) their batteries, so that additional software daemon was added (which is not cause of the problem in this case).


It is possible to disable the hardware one (and it would seem to make sense to do since it's unreliable) but that's dangerous, in case someone's pandora crashes while unattended, making daemon dead, it would never stop charging and damage the battery. There are also people running various custom OS that don't have our deamon, so hardware charge stop mechanism is the only effective one there.
I don't have the charging problem, but I've got an idea: is it possible to make the software detect that the charging stopped at a value far below 100%, and force the chip to continue charging? Not disable it, because that could cause overcharging if the system hangs, as you said, but just tell the chip to restart (maybe also increase some register value a bit, so it won't stop again after a millisecond). Or, if Pandoora is in the low-power mode, increase the processor speed to get the current higher?

My theory goes that there is a small bit of corrosion on the contacts of the recent CC Pandoras (from having been sitting around unpopulated for months), not enough to cause major problems, but enough to change the resistance between the battery and the BQ chip ever so slightly. This increased resistance means that the BQ is detecting less current going into and out of the battery than there actually is (...)
So those who experience the issue could just try cleaning the battery contacts. I also experienced a premature shutdown (at about 10%) that may be related. But on the other hand, my Pandy almost always charges to 100% (maybe there was one time when it didn't, but I can't say for sure).
 
is it possible to make the software detect that the charging stopped at a value far below 100%, and force the chip to continue charging?
Yes, but you don't want that. What if I'm right, and despite it reading 85% the battery is actually fully charged? You're cramming 15% more into the battery resulting in heat and damage, very very bad.
 
From your long post I understood that the resistance things was doing the opposite: stopped charging at *real* 85% because it thought the battery was 100%. But if that is also possible, then that's a bad idea indeed.
 
I have taken this issue very seriously!


I co-operated with _wb_ and together we developed Pandora System Info (repo | feedback),


a sophisticated hardware monitoring and logging utility, so that users can gather empirical data for their studies and reports.


I cared for the interaction design & usability, _wb_ did the coding & conceptual work too.


I had gotten my Pandora back from repair in September 2012 with the PCB exchanged with ... another faulty CC board, sadly!


My purple screen and broken left shoulder button were gone.


But it drains way too much power ("Idle in XFCE with USB+BT+WIFI off" previously ~19h, now only about 7h with 75% charge (cannot reach more))


and has slow WiFi (now ~ 80 Kb/sec, previously 800 Kb/sec)


Probably those 2 issues are related, likely a short circuit, ED said.


ED/Askarus were notified. I am soon gonna send it in for repair AGAIN.


I am considering taking a GC-board (upgrade price) to spare myself further trouble and uncertainty, wether this time another CC board will work...


My old board was very fine concerning power consumption and wifi speed (~800 Kb/sec). I wish they just correct its broken shoulder button and possible also the slightly broken left nub. Voila.


Now, the charging issue under SuperZaxxon was SIMILAR (or SAME?) on both boards:

  • It does not charge nearly full. My battery's design max is 4240 mAh and the real full is stated as 3857, but it hardly reaches ~3000!
  • The charging flattens out quite soon, at a certain point (3000mAh) practically stalls (poor ~10-50mA, instead of almost ~900mA at the beginning).
  • And although the charging-cable is constantly connected and delivering current, the Pandora nevertheless pauses charging, continues again some 30min later, pauses, continues, etc.


Only this time (with the newer board) and the availability of sysinfo I can deliver empirical data:


In all examples the charging cable was constantly connected to the Pandora:


View attachment 4495 See: Unintended charging pauses at ~03:10 and ~06:30


View attachment 4497 See: Unintended charging pauses at ~22:40 and ~01:30


View attachment 4496 Remark: Charging cable only connected at ~18:40, ignore graph before this.


Complete data (CSV and other plots as well):


pandora-charging.zip
 
Last edited by a moderator:
Back
Top