SuperZaxxon v1.52 released!


huh? never?


"never" as in "never with 3.2" or as in "for any Pandora-OS-version never"?


I compared it to an SD-card that i set up long ago and that i have been using until a few days ago (when i made myself a new one with the up-to-date OS). And on that old card the cursor-key-repetition works in the tty-console.


Alas I made too many changes too long ago to recall something that might be related. But I will keep investigating as these little things always hook me up to themselves.
 
Narf, thats strange. First Pnd Manager is unable to install the updater, then the updater fails on one part.


* opkg_install_pkg: Package angstrom-feed-configs md5sum mismatch. Either the opkg or the package index are corrupt. Try 'opkg update'.


* opkg_install_cmd: Cannot install package angstrom-feed-configs


opkg update


and


opkg install angstrom-feed-configs


got me the new version, but the error remains


Only fiddeling before: tried to install ruby (which fails)
 
Last edited by a moderator:
sounds to me, as if the downloaded PND file was broken.


Maybe try to download again (using another computer) and run the update once more?


Btw: Will it hurt to run the PND on an already updated system?
 
I had the same problem. I just took the .ipk with the new feed configs and manually extracted it - it's just an ar archive with two .tar.gz files in it, like a debian package.
 
Does recording in audacity work with the updated kernel yet? I still need top be able to boot into 2.6 to use record in Audacity. will the new kernel break this or fix it?
 
Does recording in audacity work with the updated kernel yet? I still need top be able to boot into 2.6 to use record in Audacity. will the new kernel break this or fix it?
Still broken. What I do is run `arecord -D hw:0,1 -c 2 -d <recording time> -f S16_LE -r 44100 -V mono <filename>` in terminal and then open the resulting wav file in audacity. Copying that line into a script makes it a lot easier. The audio has to be recorded in stereo as mono recording wont work for some reason.
 
Last edited by a moderator:
I discovered another really strange and rather big bug, which i haven't completely tracked down so far. Thus I can't really say if it's a bug in my personal system-config, in the latest PandoraOS or in the cdevtools-package, but I decided to post it here as I suppose it's related to the pnd-mount-system.


Issue: When I run the latest cdevtools-pnd with the latest SuperZaxxon, then first I can run stuff like "gcc" or "make" in the terminal, but after changing the directory after a short while this does not work anymore.


reason for this: When leaving the default-directory within the terminal of cdevtools (but still leaving the terminal open), after a few seconds the pnd get's unmounted. At least "/mnt/utemp/cdevtools1000" is gone and no "mount"-entry is shown for the pnd.


This really shouldn't happen. Can anyone confirm this on his system? I tried it in both - my NAND-installation and SDcard-installation.


Edit: I tried this again and now it works with my NAND-installation. So this is not always happening for me. Not sure what it is.


Edit2: Now I experienced the problem once again out of nowhere. Strange, strange.
 
Last edited by a moderator:
Hello,


I've just flashed the latest SuperZaxxon (1.52 from here) on my Pandora, and... it does not boot anymore. At least, in kernel 3.2. Pressing Right shoulder button at power-up, I get the boot menu where I can choose default boot, boot kernel 2.6.x normal ram, boot kernel 3.2 cli, boot kernel 2.6.x with cut ram for dsp. When I boot in kernel 2.6.x, everything works. When I choose kernel 3.2 in cli or default boot, I see uboot saying "starting kernel" and then the screen gets black, and the Pandora reboots after about 30 seconds. I'd love to get kernel 3.2 working :( it's so much better than 2.6.x :mellow:


Thanks for any help,


TheProphet.


Edit : Uh. Strange : I removed the battery, reinserted it, plugged the charger in, and now it boots up normally :blink: .
 
Last edited by a moderator:
I discovered another really strange and rather big bug, which i haven't completely tracked down so far. Thus I can't really say if it's a bug in my personal system-config, in the latest PandoraOS or in the cdevtools-package, but I decided to post it here as I suppose it's related to the pnd-mount-system.


Issue: When I run the latest cdevtools-pnd with the latest SuperZaxxon, then first I can run stuff like "gcc" or "make" in the terminal, but after changing the directory after a short while this does not work anymore.


reason for this: When leaving the default-directory within the terminal of cdevtools (but still leaving the terminal open), after a few seconds the pnd get's unmounted. At least "/mnt/utemp/cdevtools1000" is gone and no "mount"-entry is shown for the pnd.


This really shouldn't happen. Can anyone confirm this on his system? I tried it in both - my NAND-installation and SDcard-installation.


Edit: I tried this again and now it works with my NAND-installation. So this is not always happening for me. Not sure what it is.


Edit2: Now I experienced the problem once again out of nowhere. Strange, strange.

This happened even for me, but I never used cdevtools before, so I was thinking to have made something wrong
 
@PowerGod: Thanks for the feedback. Btw if you still want to work with cdevtools and want to be sure that the pnd will not be unmounted in between then there is a simple workaround: Open another terminal, cd into /mnt/utmp/cdevtools1000 and leave that terminal running in the background. Then you can switch to a different directory in the cdevtools-terminal.
 
I ran op_standby from the cli and when it came back the CPU was set to 125mhz and the screen was at brightness=0.


This worked fine from 1.5 and running a script for this worked just like holding the power-button. Now the button works but the script has the above bug.


Still treading lightly as this is the 4th install (the other 3 I kept loosing my permissions and could only toggle wifi and usb from root).
 
I discovered another really strange and rather big bug, which i haven't completely tracked down so far. Thus I can't really say if it's a bug in my personal system-config, in the latest PandoraOS or in the cdevtools-package, but I decided to post it here as I suppose it's related to the pnd-mount-system.


Issue: When I run the latest cdevtools-pnd with the latest SuperZaxxon, then first I can run stuff like "gcc" or "make" in the terminal, but after changing the directory after a short while this does not work anymore.


reason for this: When leaving the default-directory within the terminal of cdevtools (but still leaving the terminal open), after a few seconds the pnd get's unmounted. At least "/mnt/utemp/cdevtools1000" is gone and no "mount"-entry is shown for the pnd.


This really shouldn't happen. Can anyone confirm this on his system? I tried it in both - my NAND-installation and SDcard-installation.


Edit: I tried this again and now it works with my NAND-installation. So this is not always happening for me. Not sure what it is.


Edit2: Now I experienced the problem once again out of nowhere. Strange, strange.

This happened even for me, but I never used cdevtools before, so I was thinking to have made something wrong
Can confirm this too, the pnd got somehow unmounted. But not brutal or by error, the log under /tmp/ says all app shutdown is fine and normal.
 
This is a repost from the SuperZaxon Final 1.5 thread,


as Linux-SWAT advised me that it may get more attention here,


in the latest firmware release thread:


I have taken the charging + battery runtime issues 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

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.
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!
@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.
 

Attachments

  • pandora-charging.zip
    346 KB · Views: 249
Last edited by a moderator:
I noticed something strange on at least two units:


When i charge those units, i put them in low power mode with the power switch.


Then some time after (like 20mn), i touch the left nub, then the unit wakes up. I check dmesg and it says i'm back to OPP5.
 
AFAIR the low power mode is interrupted by ANY input event (key press, nub move, screen touch).


Only the standby mode takes just the power-switch as an wake-up event.
 
On AC, when i push the power switch, the unit doesn't wake up when touch any button. ~20mn later, it wakes up.
 
My tested observation under SuperZaxxon 1.52:


If you put your Pandora into standby

  • running from battery
    any-key-press: wakes (except keys: START, SELECT, A/B/X/Y)
  • nub-move: remains sleeping
  • screen-touch: remains sleeping
[*]running on AC

  • any-key-press: remains sleeping *
  • nub-move: remains sleeping *
  • screen-touch: remains sleeping *





Running your Pandora on AC, going to standby, unplugging charging cable, then:

  • any-key-press: remains sleeping *
  • nub-move: remains sleeping *
  • screen-touch: remains sleeping *



* Remark: in the short run, did not wait for 20min.
 
Feature request: "Custom" choice for lid-settings.


This custom choice runs:


/usr/bin/op_lidclose.sh (or /usr/pandora/scripts/op_lidclose.sh) when the lid is closed.


/usr/bin/op_lidopen.sh (or /usr/pandora/scripts/op_lidopen.sh) when the lid is opened.


To be on the safe side, by default, both of these scripts contains only:


#/bin/sh


echo


I planned to write them for Slack. I want to enable L and R as song changers, starting xbindkeys when the lid is closed.


I can use xmms2 daemon or whatever i'll find that has shortcuts.


It's not my priority to do it now, and also, i'd prefer to catch well-written official scripts ;^).
 
Back
Top