Release Pandora System Info

[kirkanoss]

thanks alot for this program and have 91.0849% after 19 cycles. also was wondering is the temp gauge acurite and at what temp should we worrie, guessing around 70c is max for the cpu but what about everything else in this little box. just sitting charging hit 34c

 

[_wb_]

The temperature is the battery temperature - I don't think there's a way to get the cpu temperature. Charging will make it warmer, but not hugely so. I don't think you ever have to worry about the temperature, at least not as long as you're using the device in a room/environment in which humans can survive for more than 1 minute without protective clothing.

 

[kirkanoss]

my mistake i don't know why i thought it was the cpu temp

 

[fusion_power]

Cool little tool. Should be included into the OS.


My Battery shows 91% max charge after 44 full loadings. I never was sure if this is an Battery issue or just a safety setting from the Pandora, so the battery lasts longer when not always charged to 100%. Was AFAIK part of the newer charging algorithms or so.


My Battery reaches 90-95%, not sure if this OK or some indication of beginning ageing, actualy should not after only 44 (if this is correct) cycles.

 

[_wb_]

I think anything above 85% is quite good. It's normal for a battery to have a capacity that is below 100% of design charge after only a few cycles - e.g. my more or less brand new laptop (a few months old) reports a battery capacity of 92%. I think they usually consider 80%capacity to be the threshold when they specify the number of recharge cycles a battery is expected to last. I think the Pandora batteries are supposed to last "only" ~500-1000 cycles, which would mean something between 1 and 3 years of continuous use (2 cycles per day).

 

[freamon]

Does this have any special requirements? Running on SuperZaxxon 1.51 with 2.6.27 kernel on a "classic" pandora I get a seg fault when I run it (gdb says "Program received signal SIGSEGV, Segmentation fault. 0x402fdec0 in fgets () from /lib/libc.so.6" which probably isn't that helpful.)


I'm a bit behind the loop with everything, so there might be something that everyone has on their Pandora that I don't.

 

[_wb_]

You have to use a newer kernel. You want to do that anyway, to get the nice power saving. Just boot with the default kernel instead of selecting the old one.


This will be fixed in the next update. The problem is that it tries to read some info which the older kernel doesn't provide, and it just crashes.

 

[freamon]

Ah, okay thanks.

 

[A2000]

When I charged the Pandora overnight while running the cpu stress test for three nights I discovered some strange effects when looking at the battery gauge in System Info.


The value that shows the actual capacity left (3882 atm) was changing from time to time. But not only downwards! Also I could read for at least two times that my battery was more than 100% full. While this might be connected to the first observation the value was 105% once . Which means that "possible capacity" has a fluctuation of more than 5%.


So is this just the system's output or is it my battery slowly dying which I suspect?

 

[_wb_]

In the system info tool, "full" is what the battery thinks is full, while "design" is the actual real maximum. When I'm charging as high as possible, I typically get to something like 94% of design charge, but my battery thinks "full" is 91% of design charge, so I also see >100% full.


Maybe the cpu stress test caused the power consumption to be close to the charging speed (when it's close to full, it will charge slowly), which would explain why the actual capacity fluctuated. By the way, I don't think it's a good idea to run the stress test for 72h in a row (or did you let it rest in between?).


The tool reports the values from the battery, but it does some minor interpolation. Every 5 seconds or so, it'll adjust to the values reported by the battery, and in between, the updates are computed based on the current reported power consumption (current * voltage * time). So you can observe some fluctuation.


All batteries slowly die, but if yours still has >3882 mAh, it's probably still in good shape.

 

[A2000]

In the system info tool, "full" is what the battery thinks is full, while "design" is the actual real maximum. When I'm charging as high as possible, I typically get to something like 94% of design charge, but my battery thinks "full" is 91% of design charge, so I also see >100% full.

Okay, I just thought that the battery thinking it is full is the trigger to stop charging.

Maybe the cpu stress test caused the power consumption to be close to the charging speed (when it's close to full, it will charge slowly), which would explain why the actual capacity fluctuated. By the way, I don't think it's a good idea to run the stress test for 72h in a row (or did you let it rest in between?).

No, no, I haven't let it charge for that long. But because it wasn't finished in the morning I had to restart every evening to run it overnight. Only the latest update offered the feature to begin the test with the last testet value.

The tool reports the values from the battery, but it does some minor interpolation. Every 5 seconds or so, it'll adjust to the values reported by the battery, and in between, the updates are computed based on the current reported power consumption (current * voltage * time). So you can observe some fluctuation.


All batteries slowly die, but if yours still has >3882 mAh, it's probably still in good shape.

Today's value is 3865. But I had some more indications that my battery isn't trustable any longer. While I ran the stress test unattended without charging the Pandora switched itself off (which is expectable). But when I startet charging it jumped from 0% to 57% within minutes and then stopped charging.

 

[Bosbeetle]

didn't know i already had 290 recharge cycles

 

[porg]

Foreword: Thanks for this utility, which to me, will be helpful for empirically monitoring all kind of power related issues.


Since SuperZaxxon I had issues with charging, which always stalled between 60-80%, never reaching 100%, and I performed intense testings and reporting. Very recently my Pandora was in RMA, the board was replaced, the case and battery remained. Purple tint of death and a broken left shoulder button (my fault, thanks for the good will ED!) were repaired, but sadly the issue of incomplete charging remains & a second power related issue arose: My runtime seems significantly lower, "idle in XFCE with USB+BT+WIFI off" now 11 hours instead of previously 19h! Possibly a premature alarm/moaning, needs further testing (re-flash changed little, maybe screen backlight makes the difference, need to test that long time).


@_wb_: From this my personal Pandora story and the analytic aid which "System Info" already provides and could further provide, I now respond to your inquiries:

Also I would be interested in the battery health vs number of recharge cycles graph for the Pandora battery.

Actually 3831 mAh of 4240 mAh by design. Battery 16 months old.


But I am not sure wether this data can be trusted, see the bug report below.


Bug reports:


Battery health related data is missing in my view of System Info!


This is what I see in the lower right screen area:


(full = 90.35% of design,


after 0 recharge cycles)


Full battery lasts ??? at this rate.


Fresh battery lasts ??? at this rate.

If there are feature requests (or of course bug reports), I'm of course open to suggestions.

Feature requests:


Logging features, for singular or all kind of monitored data (cpu, power, storage, …) so that long time monitoring and experiences sharing are easily possible. This would enormously aid hardware troubleshooting in the community.


Implementation suggestions:

• Data format: Timestamped tab separated clear text values or binary data into: appdata/sysinfo/logs/<logtype>/YYYYMMDD-hhmmss.csv
  
• Setting logging interval: Pressing "I" opens this dialogue:
  Set the logging interval for your currently active panel "<panel>":
  
  hh/mm/ss/millisec | cancel
  
  If you are currently in the overview, the dialogue changes to
  Set the logging interval for all panels:
  
• Setting logging format: Pressing "F" opens this dialogue:
  Set the logging format for your currently active panel "<panel>"
  
  text | binary | cancel.
  
  If you are currently in the overview, the dialogue changes to
  Set the logging format for all panels:
  
• Logging control:
  Pressing "L" starts logging the data of your currently opened panel.
  
• Should you be in the overview, then all log-able data is logged.
  in the lowest common interval,
  
• in the format: timestamp <separator> panel1data1 <sep> p1d2 <sep> p2d1 <sep> p2d2 <sep> p2d3 … )
  

[*]If you press "P", logging is paused,


[*]another press of "P" continues logging.


[*]Another press of "L" stops logging.


[*]A further press of "L" starts a new log into a new file.





Network monitoring: Would love to have a further panel "Network". Should be n°4. "About" should get n°0 (=zero) (rightmost key on the keyboard, creates stability, should more screens be added to 5,6,…) or H ("help") or A ("about"). Network stats to be shown:

• State (WLAN on/off, USB net adapter)
  
• SSID
  
• speed up/down, data up/down, since boot / last 10 secs / etc.
  

Suggestions:


Interaction design:


If you are in overview mode (O) and press a detail panel key (1/2/3/4), it should jump right into that detail panel. The concept of an overview panel toggle is irritating. One wonders "I pressed 1. Why is it not opening that panel?" No-one thinks "I first must toggle the overlaying overview", but the mental model is rather to switch between screens (Overview/1/2/3/4).


Interface design:


As System info uses a non-monospace font, and the amount of characters sometimes varies (concrete data versus "???"), the layout jumps back and forth.


For better readability the labels and data shall be aligned at certain positions (think of it as an invisible table layout).

 

[_wb_]

Bug reports:


Battery health related data is missing in my view of System Info!


This is what I see in the lower right screen area:


(full = 90.35% of design,


after 0 recharge cycles)


Full battery lasts ??? at this rate.


Fresh battery lasts ??? at this rate.

The 0 recharge cycles is strange - but this is most likely not a bug on my side, but a problem with the driver or your battery - I'm just reporting the number from /sys/.


The ??? are normal IF you're charging your battery. There will only be meaningful numbers here when you're discharging.


I will implement a network monitoring tab, and maybe also some logging, in the next release. It may take a while for this to happen - my current priority is to get Microbes 1.0 out.


I completely agree with the suggestion to go immediately from overview to detail panel on keypress - changed it already in my working version.


The "invisible table layout" - I see what you mean, but I'm not sure if this is easy to combine with the auto-scaling I'm trying to do (the font size and positions are changed if you go in windowed mode and resize the window). If windowed mode is not used by anyone, I could remove it and it would make it easy to implement the invisible table layout thing - I could then also use notaz' SDL which is a bit more efficient than the default one. But imo windowed mode is kind of useful.

 

[porg]

The 0 recharge cycles is strange - but this is most likely not a bug on my side, but a problem with the driver or your battery - I'm just reporting the number from /sys/.


The ??? are normal IF you're charging your battery. There will only be meaningful numbers here when you're discharging.

Thanks for this info. I will state this troubling indication in my RMA correspondence with OpenPandora GmbH.

The "invisible table layout" - I see what you mean, but I'm not sure if this is easy to combine with the auto-scaling I'm trying to do (the font size and positions are changed if you go in windowed mode and resize the window). If windowed mode is not used by anyone, I could remove it and it would make it easy to implement the invisible table layout thing - I could then also use notaz' SDL which is a bit more efficient than the default one. But imo windowed mode is kind of useful.

The windowed mode (overview mode is a more feature descriptive term, thus better) is definitely great, should be kept. Possible approaches:

• Make the invisible-table-alignment and scale the font size in the same ratio as the panels are scaled. (problem: quite small fonts)
  
• Make 2 invisible table layouts per each view (panelview and overview). More work, but you get out the optimal screen space use.
  

I will implement a network monitoring tab, and maybe also some logging, in the next release. It may take a while for this to happen - my current priority is to get Microbes 1.0 out.

Looking forward to these new features.

 

[_wb_]

Windowed mode and overview is not the same, you toggle windowed mode with F and overview with O.

 

[porg]

Now I understand the semantic confusion.


Ok windowed mode is important too in multitasking mode (XFCE).


Then scaling/layout must be well thought. But should be possible.


Websites with good CSS also achieve that. Just have a look at them, the solution will get clear to you then. Good luck!

 

[_wb_]

Preview of the new "Network" panel:

As for logging: I could add logging to (human readable CSV) file, this should not be a lot of work. However, displaying logged information in a nice way is a lot of work - I'm not planning to implement that. It should be easy enough to import a CSV into any spreadsheet and use the information in any way you want.


Any suggestions on which data fields to log? (not all of the displayed data makes sense to log imo, and many things can be derived from other things)


I was thinking: cpu % used, battery charge left, current, voltage, temperature, wifi status, uploaded/downloaded bytes. Everything always together (simplifies things for me and it's easy enough to hide/remove some columns in a spreadsheet) at a time resolution of 1 second (you can pick a higher time resolution of K seconds, which just means that only one row in K is actually outputted - I'm not gonna bother to actually aggregate the K rows and output the mean or sum or whatever). Does that sound OK?

 

[porg]

Wow! Did not expect your reaction that soon, as you said, it will surely take some time.

Preview of the new "Network" panel:

Looks fine. Good idea to have that guiding lines at certain sizes (64, 128, 256 KB/s), and the top line at the maximum value (618.16KB/s).


To the layout and naming scheme:


Why Downloading and Uploading next to each other (left and right), but Downloaded and Uploaded on top of each other (top and bottom)?


Why not ALL Download related on side (left in your example), and Upload related on the opposite side?


↓ ↑


342.73 KB/s 5.12 KB/s Speed now


31.71 MB 799.57 KB Data in this session


31.71 MB 804.00 KB Data since boot


Typographically the units look better if separated from the numbers, although technically (according to SI) they should be directly appended.


Your color coding for both graph and all labels is a fine idea.

As for logging: I could add logging to (human readable CSV) file, this should not be a lot of work. However, displaying logged information in a nice way is a lot of work - I'm not planning to implement that. It should be easy enough to import a CSV into any spreadsheet and use the information in any way you want.

I totally agree that log display and visualization is out of System Info's scope!


I think it should export human readable (CSV) and not binary.


Then you can use all kind of spreadsheet/statistic and visualizing apps, and for community troubleshooting/performance-comparison, you can use the clear text variant, also easily extract the key periods from it.


To not write to often to the SD cards, maybe it is ok if sysinfo accumulates data in a RAM-held variable and only writes to SD every 10 seconds. In case of a crash at most 10 seconds of data are lost.

Any suggestions on which data fields to log? (not all of the displayed data makes sense to log imo, and many things can be derived from other things)


I was thinking: cpu % used, battery charge left, current, voltage, temperature, wifi status, uploaded/downloaded bytes.

I agree that values which can be calculated from other values should not be logged, but rather be implemented in one's spreadsheet via formula fields.


I would add C0,C1,C2,C3,C4,C5 which could help to analyse power saving.

Everything always together (simplifies things for me and it's easy enough to hide/remove some columns in a spreadsheet) at a time resolution of 1 second (you can pick a higher time resolution of K seconds, which just means that only one row in K is actually outputted - I'm not gonna bother to actually aggregate the K rows and output the mean or sum or whatever). Does that sound OK?

Took me a while to understand this paragraph, but eventually I understood.


I thought that polling certain state-values may influence the system's performance (and thus other values), thus thought to only poll selected values at intervals which make sense for them. Log "all into one" would be of course simpler to implement for you, and more universal at all. I'm just imagining the case of user support, the supporter just has to inquire "Please gimme your sysinfo.log" and then decide which data is relevant for that support case, and ignore the other data.


You as an expert likely know wether there is such interference or not, and what interval to choose which makes sense for the whole set of data.


Please create a log file called <YYYYMMDD-hhmmss>-<logtype>.csv


In case there is anyhow only one logging format, then there is no need for <logtype>.


Another feature idea:


Some people may also want to monitor how much and fast data is read/written to NAND and SD1 + SD2.


In that case sysinfo's read/write impact onto that statistics should be substracted (if possible).

 

[_wb_]

At the moment all information (except the disk free info) gets polled each second - that doesn't have a big impact on performance, getting the information is the cheap part, displaying it on the screen is the expensive part (mostly drawing those anti-aliased TTF letters). I'm doing that to make sure the cpu and network history gets updated even if you happen to be in a different panel.


Good point not to write to SD every second, that could indeed have some negative impact on power consumption. I could keep some rows in memory (for CPU and network I'm keeping 800 rows of info in memory anyway, each pixel in those graphs corresponds to 1 second) and write them out periodically - maybe I should then do the aggregation too so you could pick any logging interval between 1 second and 800 seconds (or let's say 10 minutes) and get aggregated rows for that interval. Do I need to ask the user to type in a number of seconds for the interval, or should I make it a toggle that switches between, say, 1s, 10s, 1m, 5m, 10m or some other list of predefined intervals?


Monitoring read/write transactions and speeds, hmyeah, maybe in some future version but not yet in the next one