Release Pandora System Info

[Loonie]

I, too, get this error. Here's the PND-output:

=======================================================================================


PND : /media/PANDORA_SYS/pandora/menu/sysinfo0.5.pnd


PND_FSTYPE : Squashfs


APPDATADIR : /media/PANDORA_SYS/pandora/appdata/sysinfo


APPDD_FSTYPE : vfat


PND_CPUSPEED : <unset>


EXENAME : run


ARGUMENTS : <unset>


=======================================================================================


[ START ]--- Mount the PND ----------


Mounting : mount -t squashfs -o ro "/dev/loop0" "/mnt/utmp/sysinfo"


Mounting the Union FS : mount -t aufs -o exec,noplink,dirs="/media/PANDORA_SYS/pandora/appdata/sysinfo=rw+nolwh":"/mnt/pnd/sysinfo=rr" none "/mnt/utmp/sysinfo"


[sUCCESS]--- Mount the PND ----------


[ START ]--- Starting the application (run ) ----------


./sysinfo: error while loading shared libraries: libmySDL_gfx.so: cannot open shared object file: No such file or directory


real 0m0.016s


user 0m0.000s


sys 0m0.008s


[ FAILED]--- Starting the application (run ) ----------


[ START ]--- Restoring the frame buffer status ----------


[sUCCESS]--- Restoring the frame buffer status ----------


[ START ]--- uMount the PND ----------


[ START ]--- Waiting the Union to be available ----------


[sUCCESS]--- Waiting the Union to be available ----------


auplinklink.c:223: AUFS_CTL_PLINK_MAINT: Inappropriate ioctl for device


rmdir: failed to remove `/mnt/utmp/sysinfo': Device or resource busy


[ START ]--- Waiting the PND mount dir to be free ----------


[sUCCESS]--- Waiting the PND mount dir to be free ----------


cleanup done


[sUCCESS]--- uMount the PND ----------


=======================================================================================


Return code is : 4

 

[_wb_]

I have no idea what causes this. Very strange. Does the upgrade on the repo help?

 

[_wb_]

Aha, managed to reproduce this on a fresh SZ install. Looks like it has something to do with ionice or nice (somehow the exported LD_LIBRARY_PATH gets reset or something). Should be fixed in the version now on the repo (I just removed the ionice stuff and reverted it to how it was before). Sorry - this problem didn't occur on my normal install, so I didn't catch it when doing the usual pre-release checks.

 

[Loonie]

All is well again. Thanks for the quick turn-around.

 

[porg]

Could launch sysinfo 0.5.1, all features below worked nicely:

Problem: If there is no "plots" directory in appdata, the sysinfo graphing tool fails (ristretto waits forever).

Logging-info shall be shown until timeout regardless of panel switching

Plot file chose dialog: Shall start in descending order

Layout of panel "Network": Text block "Download" and "Upload" not aligned

This feature may follow one day:

Comment functionality & Custom singular log/comment events

Discussion on this issue:

Graph which makes correlations clear.

I grouped "base power usage" and "display" (not backlight but the LCD itself) together because those two are unavoidable constant power drainers in most cases. I could split that up.

I'd prefer that segregation, for use cases like audio players, wifi-wardriving with the closed Pandora in your pocket, etc.

The heavy spikes at 25:50 indeed the cost of disabling wifi: I'm guessing that unloading the wifi driver modules takes quite a bit of CPU. You also get this spike when enabling wifi, but that isn't visible on the chart because CPU was already at max.

Thanks for confirming this.

Note that this breakdown is only an estimate: there is no way to actually tell which component is using what power, there is only 1 power gauge so only the total power usage is accurate. The breakdown estimates are based on checking the total power in several different usage patterns (like in the above graph), to find out approximately how much everything is using. E.g. for the backlight, it's quite simple: the higher the brightness setting (something that is logged now), the more it uses. For the CPU it depends mostly on clock speed and cpu usage. For wifi there's a small fixed cost to have it activated, and a large cost when transmitting data (but the transmission speed doesn't seem to be very important, except of course if it causes more cpu activity).


I'm now trying to make it to correct for charging, like you ask. This is not easy, because when charging, I have only two power statistics to work with: the power measured by the battery ( B ), and the power measured by the charger ( C ). There is the real power consumption of the cpu etc (P), and then there's quite some power that gets lost (H) because charging is never 100% efficient: some power gets lost as heat etc (which is why you'll see the battery temperature go up when charging starts). The total incoming power ( C ) is equal to the power measured by the battery plus the power actually used plus the wasted power: C = B + P + H. There is not enough information available to get the exact value of P from this equation given only C and B.


So what I can do is estimate the power by summing the estimated cpu, wifi, backlight etc consumption, and assume that the rest went to waste (heat). I'm going to make the plots that way.

So to get good estimations, you are in need for a perfectly healthy reference Pandora of each revision (Original, Rebirth, 1Ghz), need to produce quite the different tasks in a given order, then later read the values from the log, and retroactively assign the value amounts to each component (base power, lcd, backlight, wifi, board, cpu, etc) and also factor-in the "lost/heat" factor.


These values are then supplied with the PND for the graphing template logic. All users generate their graphs from the reference Pandoras, not necessarily matching their own Pandora's reality.


I propose, that OpenPandora should help you with this. They could run your component power test scenarios from your precise instructions on lets say 3-6 units per revision (and see wether and how much the units within one revision differ).


Remember: Sysinfo's main purpose (as we all came to an agreement) is to be an exact hardware monitoring tool.


This particular graph conceptually differs from that goal. Thus it has to be explicitly clear that it is an estimation, not pure fact. Nevertheless it very much aids in understanding your system, worthy to have, and if the reference values are good, it's even likely that the presentation is actually quite close to the factual truth.


To prevent sysinfo getting a possible root of the spreading of wrong information/understanding, I suggest to give this graph a slightly different overall look (i.e. light blue/grey background, a headline "Estimation of the power distribution" and a clear indication, what parts of it are fact, and what estimated: Estimated variables' labels shall have in indicator that they are estimated, such as "~" in front of the variable label or "ca." or "estd."

 

[lomaxx]

I didn't browse through this thread, but just wanted to report something I have witnessed. Might be known or not of interest.


I've been monitoring my battery-charging with PSI (Pandora System Info). At the point where it says it was charging at a value greater than 100% of full I became a little sceptic, but still continued to leave it charging and monitoring it now and then. In between I quit PSI, looked something up in a terminal and then returned and then noticed that the % dropped below 100% again. I again left it running and now am again over 100% (currently I am at 101,85....%).


Now I am also checking the output of "watch cat /sys/class/power_supply/bq27500-0/charge_*" and there the value for "charge now" does not increase anymore.


So maybe this is a not known flaw of PSI (that it doesn't noticed the charging is not going on anymore) or I am "cat"ing the wrong files? Nothing dramatic in any way.


Edit: Well I start to think that the above sys-files I mentioned are the wrong ones.

 

[Binky]

Quite often I get a peak reading below design capacity, but below 'full' - where does the number for 'full' come from? How can it be recalibrated?

 

[_wb_]

"Full" is some value reported by the hardware: it is what it _thinks_ your battery capacity is. Usually it is pretty wrong. I recently switched batteries and the hardware "full" value (which is from a chip on the pcb, not on the battery itself) didn't change, although I switched to a fresh new battery that can actually even be charged above design capacity at this point.


The behavior described above is known and there's not much I can do about it. Let me explain:


While System Info is running, it is checking the reported battery charge (let's call that C) two times per second. This reported value is in mAh, and it is only updated every 5 seconds or so. To get more accurate numbers, System Info is also checking the actual current flowing to or from the battery, so it keeps track of the estimated "real" charge (let's call it R). If you're looking at the battery screen progress bars, you can see the reported charge C in dark green and the real charge R in light green. The numbers that are shown are always the "real" numbers.


Usually the difference between R and C is small. There is one exception: at the end of charging, when you're charging higher than 100% of "full". At that point, the hardware keeps reporting the same value, even though the battery is still slowly "topping off" and getting charge. This seems to be a bug (in the hardware battery charge gauge firmware). Now R starts to be higher than C. When you're logging to a file, both values are saved so you can compare them.


If you keep System Info running, you won't even notice the bug, you'll just see the charge go higher than full, and then at some point it starts discharging again. It knows about the bug in the reported battery charge, so it'll ignore C until it becomes reliable again. However, if you quit System Info and restart it, you'll see a sudden jump, because it has no choice but to take the reported value C to start from (I could save R when you quit and read it back when you start again, but of course that doesn't work because there's no way to tell how much power has been consumed in the mean time).


See also:

 

[lomaxx]

Thanks for the explanation. I wondered why the charge-value suddenly dropped when I quit PSI and continues to rise when I leave it running. I started to think that PSI does more than just monitoring, in such a way that it makes the Pandora continue to charge. But then this was due to the workaround for the bug. Also I thought that PSI might use other files for monitoring the data than the files in "/sys/class/power_supply/bq27500-0/". But the way I understand you it still is using them, but as already mentioned ignoring some of the info when full.


Please correct me if I'm wrong.

 

[_wb_]

Yes, you're right. It is using those files (as well as some other files in /sys/class/power_supply/ to get the info from the charger as well), but it's doing its own interpolation in between updates to those files from the hardware / battery driver, and tries to avoid the bug in the reported charge.

 

[sswam]

you'll just see the charge go higher than full, and then at some point it starts discharging again

Does sysinfo keep its own records of the minimum and maximum attainable charge? that might be useful. I noticed my Pandora keeps going well below zero also! It would be nice to keep sysinfo running and logging (and saving its stats) until the thing dies, so I know what the lower limit actually is. I guess this is a "feature request" if you didn't already do it... Where do we donate to say "thanks" for this app?


Speaking of donation, maybe we should have a global "donate" option on the repo, for free apps, and if the dev doesn't want to receive the money, it goes to help clear the old pre-orders!

 

[_wb_]

Well you can already keep it running and logging until your battery runs out - just press L to start logging.


I'm interested in your below zero charge - could you plot some logs showing that? (in particular, I'm interested in the reported charge vs the interpolated charge)


It doesn't itself maintain min/max charge; maybe that could be a useful feature: maybe it could be used to somehow normalize the range. Of course the battery gauge chip is already trying to do that, but it doesn't always do a very good job at that. I have recently swapped my battery for a fresh one (I read somewhere that it's better not to let a spare battery gather dust for too long), and now I can charge it to about 4700mAh, which is quite a bit more than the design charge of 4200mAh. The gauge chip still thinks my old battery is in there, which had a max capacity (because of wear) of about 3900mAh. So I can now charge to about 120% of "full" - of course the gauge chip never reports any charge over 100%, so the reported charge stays at 100% for many hours now while discharging.

 

[urjaman]

It should actually be possible to reset the battery gauge chip to as-new configuration, since that is done during the initial firmware load & testing, but I'm failing to find the software / script that does that...


EDIT: And yeah what I was going to say was that it is a bit weird that the battery page estimates time to full as time to 100% of design capacity (Heading "Full" from hw and "time to full at current rate" 2h 35min ...)


And yeah to add to the statistics, my full is 3806 mAh (89.7641%) after 124 recharge cycles (although that number might be a bit misleading, it has been 124 for a few days... and I think I have done atleast one full cycle during that time...). My pandora is an old black nub-broken unit shipped (IIRC, not sure) summer 2010.

 

[porg]

Bug report: Pandora System Info 0.5.0.1 - Download counter stuck at 2048 MB

If you have accumulated 2048M downloaded bytes, neither "Downloading" nor "Downloaded" are updating anymore, although in the downloading program (wget, in my case) one can clearly still recognize download progress.

I don't know wether this bug originates from the device-files which sysinfo reads out, or from a limited variable size in sysinfo itself.

 

[_wb_]

That sounds like a bug of mine, probably using a signed 32 bit int somewhere, while I should be using a long int. I'll fix it at some point (but I don't consider this to be an urgent bug).

 

[urjaman]

You should be using long long (or int64_t). long and int are the same. Just FYI.

 

[Neelix]

Bug report: Pandora System Info 0.5.0.1 - Download counter stuck at 2048 MB

If you have accumulated 2048M downloaded bytes, neither "Downloading" nor "Downloaded" are updating anymore, although in the downloading program (wget, in my case) one can clearly still recognize download progress.

I don't know wether this bug originates from the device-files which sysinfo reads out, or from a limited variable size in sysinfo itself.

I can confirm that this also occurs with the Upload figures if total uploaded reaches 2048MB.

- Neelix

 

[HolySmoke]

Exerpt from the conky manual:


totaldown (net)
Total download, overflows at 4 GB on Linux with 32-bit arch and there doesn't seem to be a
way to know how many times it has already done that before conky has started.

totalup (net)
Total upload, this one too, may overflow
So this might also be limited by the kernel.

Though I don't have any actual evidence to support that

 

[porg]

That's the totals.

If a total is overflowing, then "Downloading" can still be correct (though it needs to realize that overflow, otherwise it may show a negative download value, if it's simply subsctracting downloaded-bytes-now - downloaded-bytes-previously).

And as long as Sysinfo is longing, also the overflows could be counted, and the total calculated as multiples, i.e. 4 overflows of 4GB + 200MB currently = 16,2 GB.

 

[Askarus]

As I'm a necromancer I may revive this thread .

I want to do some tests with overclocking GPU and RAM.

@ _wb_

If you have some time left could you please add GPU and RAM speed to sysinfo?

Maybe you could find some space to display those two numbers as well.

Maybe some small lines under the CPU speed or anywhere else.

You could make the orange CPU bar smaller and add the GPU as well (Maybe yellow or any other color you like)

Maybe for the idle starts as well: Smaller bars but GPU below CPU bars. (Dark blue for CPU and light blue for GPU)

For RAM clockspeed a simple number would be enough I think. No need to make an extra bar.

Or you could add a new Page for GPU speed which looks the same as the CPU site.

You could put the RAM speed there as well then.