Release Pandora System Info


Looks good. A Network Traffic Monitor is wHat I don't have on my Pandora at the moment. I really want to see how fast (or better: SLOW ) my WiFi is. Compared to my PC, the ones in the Pandora is really, treally slow.


However, because of obvious reasons, please make the logging function optional. :)
 
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?

As originally described > Setting logging interval > Pressing "I" starts a dialogue:


Set logging interval:


hh:mm:ss


Note: If you start logging,


don't remove the SD card


holding sysinfo's appdata!


Pro/Contra:

  • + Gives freedom for arbitrary intervals to the user.
  • - A little slower than choosing from given values. But the given freedom & flexibility outweighs this.
  • + If one wants larger intervals (i.e. long time monitoring) a mixed units scheme (hh:mm:ss) is more user friendly than a singular unit scheme (seconds, milliseconds, etc), as one must then convert mentally or with external tools.


The warning note:

  • Should also appear when triggering logging the first time ("L"). Either fade away after 7 seconds.
  • Or append an info such as "'L' to start logging" "'ESC' to abort logging and warn me again next time.


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

please make the logging function optional.
+1. As described, I even would like it to be pause/resume-able. (key "P")

getting the information is the cheap part
Btw, I would love to see a CLI version of your app, which can run as a daemon or autostart-process or thelike, as I'd like to do some long term monitoring. I already invested so much time in taking manual notes and providing that data to the community — having a software utility for it would help me a lot!


Maybe you could add this as app n°2 in the PND package, named "System Info to NAND installation" (not a nice name, but in listings such as MiniMenu, XFCE-Menu, etc your two apps from one PND package would be alphabetically grouped, which is quite useful).


Some more interaction design:


For a good first use of your app, I suggest this:


If the app is started the first time (simply create a check-file in appdata),


the user gets to the help (about) screen, which has these contents:


Panels Commands


1 or B: Battery L: Start new log file


2 or C: CPU P: Pause/resume logging


3 or S: Storage I: Set logging interval


4 or N: Network H: Help screen (this screen)


0 or O: Overview Q or ESC: Quit program


EDIT: Forum software destroys the layout, but you get the idea I guess.


At the next launch the app shows the user's previously used screen (sysinfo saves this state/choice to appdata at its termination).


Further usage hints in the GUI are not necessary, as the top-left and top-right "panel-signposts" bare enough trace that there are more screens, the beginner will expect the help somewhere there.


And beyond that app-immanent help, that help shall be stated in the repo, and in the supplied PND help document.
 
Last edited by a moderator:
I'm going to partially follow your proposal: "L" to toggle logging (this means you can pause/unpause too with that button; there's currently no way to start a new logfile except by restarting the program); there's a permanent on-screen message in a small font reminding you that logging is turned on if it is turned on, and it also mentions the log interval. You can use dpad up/down to change the log interval by +- 1 second, and pgup/pgdn (X/Y) to change it by +- 30 seconds. The default is 10 seconds, so you don't have to change that if 10 seconds if fine for you.


Removing the card containing appdata is always a bad idea, because that's also the card containing the pnd. I'm assuming people have the common sense to not remove that card.


Good idea to show the about screen on first use, and to have alternative letter shortcuts for the panels. Also a good idea to make the panel persistent - I'll also make the logging choices persistent (on/off and interval).


By the way, here's a graph I made from logging overnight (I charged it overnight), one data point per 5 seconds (which is complete overkill, LibreOffice could barely draw those 7500 data points):


pandora-battery-log.png
 
Interval: Your method of setting the interval is fine too, as the effect of user input is reflected in the logging screen zone, providing instant input feedback. I hope that you can also change the interval while logging is off. Note that if you change the interval while logging, you get irregular intervals, and your spreadsheet needs to take these into account, if you want to get a truthful graph!


Logging: You suggested "only one global on/off logging switch" instead of my twofold commands "start/stop new file and pause/resume logging". I like my idea better. Why? With your proposal you get all data in one gigantic ever growing log file. Except if you plan to generate a new file per session! But then again, why not give the ability to the user?


Use case for my method: I start logging while I perform a particular activity A. I stop logging. I prepare my activity B. Then I start logging into a new file, and start my activity B. Then I have the monitoring of activities A and B nicely separated in two files. With your suggestion, I need to inspect the data stream, and determine myself where activity A stops and B starts, or I have to again reside (!) to external means (paper, possibly a parallel texteditor in multitasking, but if one uses MiniMenu, you need paper or a 2nd computer) and note when activity A started/stopped and when activity B started/stopped. But this leads SysInfo's logging purpose ad absurdum again! As one main goal of sysinfo's logging is easy empirical logging with minimal administrative/manual effort!


My graph for charging sadly is far worse than yours. :(


The x/y-axis ratio may be different, but still, my charging graph practically flattens out towards infinity already as early as 2500 mAh.


I took manual notes, and then generated that graph with a spreadsheet software.


You gain ~ 3500 mAh in ~ 4 hours, whereas I gain ~ 3000 mAh in ~ 8 hours.


SuperZaxxon Final - Charging after RMA - worse.gif


SuperZaxxon Final - Charging after RMA - worse.pdf
 

Attachments

  • SuperZaxxon Final - Charging after RMA - worse.pdf
    52.3 KB · Views: 198
To create very accurate graphs you indeed have to take the timestamps into account, also for another reason: if the interval is e.g. 5 seconds, there will be at least 5 seconds between each measurement, but it could be slightly more than that (e.g. 5.01 seconds), especially under heavy load. The error is cumulative, so every now and then you'll see a 6 second jump between two rows instead of 5 seconds.


About the logfiles: Yes, it creates a new file each session, as soon as you start logging it creates the file (filename reflects time when you started logging), and then it keeps logging to that file until you quit. I could add a button to create a new file without having to quit/restart, it's trivial to implement that.


Your battery does seem to be in a bad shape indeed. The current going in while charging is low, it seems you don't get the "fast charge" behavior but have to use the "near-full, slowly topping off" slow charging all the time, or something like that.
 
About the logfiles: Yes, it creates a new file each session, as soon as you start logging it creates the file (filename reflects time when you started logging), and then it keeps logging to that file until you quit. I could add a button to create a new file without having to quit/restart, it's trivial to implement that.

I will try explaining again, now even more illustrative. I hope I can communicate my point at this 3rd attempt:


There is no need for a visual button, I'd suggest to just handle that with key presses, as this is the overall operation mode of sysinfo.


Key commands:


L: Start logging into a new file / stop logging of current file.


P: Pause/resume logging into the currently active file. (Or to be even more mnemonic, I'd call those coupled functions pause/proceed)


I try to illustrate an example session:


L: Create a new log file (<timestamp1>.log) and start logging into it.


P: Pause logging for whatever reason.


P: Resume logging for whatever reason.


P: Pause logging for whatever reason.


P: Resume logging for whatever reason.


[...]


L: Stops logging into currently active file (<timestamp1>.log).


[...]


L: Start logging into a new file (<timestamp2>.log)


[...]


Q: Quits SysInfo.


Concept idea: At quit time, Sysinfo notes in which logging condition it is into its appdata settings (Which logfile? Active logging or not?)


[...]


Starting SysInfo again from Pandora OS.


Concept idea: Sysinfo continues with the previous logging condition. (Was active at quit time, thus continues logging. Conceptual question: Into last active logfile or new logfile?)


[...]


If concept idea "automatic logging condition resume" is not used, then you would need to trigger logging manually after launch.


L: Starts logging into a new file (<timestamp3>.log)
 
Last edited by a moderator:
Version 0.2 is on the repo!


New stuff: network panel (as suggested by porg), alternative "friendly" theme (as proposed by ekianjo) , logging to CSV file (as suggested by porg).


@porg: I'm using the keys L and P for logging like you suggest, but I didn't put P in the help screen because I don't think it is that useful. It's in the README though.
 
Thanks for taking in account the feedback _wb_ !!! I will look it up right now.


I checked and I really liked what you did for the theme I requested :) thanks!
 
Last edited by a moderator:
@_wb_: Wow, what great achievements!


I am really glad that our co-operation as developer and interaction-designer works out that fine!


Concerning pure technical functionality my suggestions are completely implemented besides some minor technicalities,


concerning interaction design & user interface design, some things can be improved, and I joyfully provide my feedback to you.


INTERACTION DESIGN:


Not showing the pause/proceed usage hint on the help page:


Ok, as it is an extravagant pro feature, a mention in the help-file is sufficient.


Logging status info:


If logging is off and the interval is modified by the user, there nevertheless should be feedback to his/her input in the GUI.


Suggesting to show this line in the "logging-info-area":


Logging off. Interval Xs.


And hide that info after $info-timeout seconds (suggesting 2-3 secs).


Should the user modify the interval before the 3s timeout (most likely use case: successive key presses to achieve a certain number), the $info-timeout starts to count again, and 3 seconds after the last keypress the info disappears.


If logging is paused, this should be shown for $info-timeout secs as well:


Logging paused. Interval Xs.


Additional info. If logging gets turned off, it would be fine to see:


Log file closed: <filename>


for the duration of $info-timeout secs.


Interaction of "L" and "P":


Should behave like this:


"L" is the master toggle, "P" subordinate to it.


"P" only has an effect if "L" is on, else it is ignored. (Currently "P" starts logging although "L" is off)


If "L" if off and gets turned on, the state of "P" (pause or proceed-ready) is irrelevant, shall not prevent "L" from starting to log.


After "L" (logging into a new file) is active, the next "P" press is for pause, then proceed, then pause, and so on.


Praise: Key "5" also linked to the help screen:


Good idea as after successively pressing 1,2,3,4 … you intuitively press 5.


And there are enough available keys in your app anyhow.


GRAPHICAL USER INTERFACE:


Praise: The new lightweight theme is:

  • visually pleasing
  • with less info (not overwhelming)


thus a good alternative for novice (or less techy) users.


Praise: Consistent navigation metaphor:


"About" only has left signpost ("Network"),


"CPU" only has right signpost ("Battery"),


creates a spatial feeling.


In addition the first (="leftmost") panel has a left text-alignment, the last(="rightmost") a right text-alignment.


But the "help screen"'s remaining text layout is ugly, thus the concept is not grasped immediately, rather seems as a unconscious side effect of the ugly layout.


But I am sure, you had this thinking behind.


If the help screen's remaining layout is improved (no need to describe, I think you have the feeling for it), then also the navigational concept is complete.


SEMANTICAL & TECHNICAL:


File name:


log_YYYY-MM-DD-hhmmss.csv


Somehow a strange mixture of multiple styles:

  • Underscore and hyphen symbol.
    Suggesting to use only one. My personal taste (and Google's recommendation for URLs): "-" (hyphen aka minus).
[*]Separators between YYYY MM DD, but not hh mm ss.


[*]The generic name "log".

  • Would be good if you have a filename which:
    Opens with the correct application on launch: ".csv" achieves that well ("filename.log" would transport the meaning just as well and spare log from the filename into the extension, but likely open a unsuited app, such as a Console utility.
  • Unambiguity: Can be taken right away and shared without further renaming, bares enough self-immanent info and provides a recognition value, also working as a promotion for the platform & your software.
    pandora-sysinfo-log-YYYYMMDD-hhmmss.csv
  • pandora-log-YYYYMMDD-hhmmss.csv
[*]Not conflict with filename length and character encoding standards.

  • I think DOS 8.3 can be gently ignored, but possibly stay within the 32 char limit of some systems (although most contemporary systems anyhow have 256)
    pandora-log-YYYYMMDD-hhmmss.csv










CSV header:


It's a brilliant idea to simply write "Design charge" and "Full charge" as the first 2 rows, and put their corresponding number into the suitable column right away.


I had also thought of a header with basic data such as "Design charge" and "Full charge" and the Pandora model and serial, but my testing in various spreadsheet apps, showed that they all had a problem, if the first lines had a different format then the remaining lines. Thus your solution elegantly solves this!


Suggestions:

  • Simply write "Full charge" instead of "'Full' charge", as some speadsheet apps have problems with quotation marks, as they could misinterpret them as string separators.
  • Its fine to write out the full names, nevertheless "degrees Celsius" can be abbreviated to "°C" (not ASCII compatible) or at least to "Celsius" or "C".


CSV delimiter format:

  • Your format as-is (comma + tab) is inconsistent with itself between the columns "battery temperature" and "downloaded bytes" (tab + comma).

  • Regardless of this, I anyhow propose to use a single delimiter character.
    Preference from most to least like-able:
    Semicolon (works best in most spreadsheet apps, bad to read in pure text editors)
  • Tab (troubles some spreadsheet apps, good to read in pure text editors as it aligns columns quite well)
  • Colon (Not that good, as this is often used as a decimal-separator in some countries)




I tested your comma+tab file in these apps with these results:

  • Apple Numbers 2009 (2.1): Fails, all shown as one column.
  • Microsoft Excel 2012 (14.1.4): Fails, all shown as one column.
  • NeoOffice 3.1.2 (based on OpenOffice): Fails, although one has many interpretation options at file open time.
    All this separator settings fail: Tab, Colon, Tab and Colon, Custom ",\t".
  • QuickLookCSV file preview in Mac OS X Finder (file browser): Works.
    Even the maliciously formatted column border is shown correctly (as a number only without any disturbing comma within cell content).
    Seems to have a very tolerant parser!


SD writing interval:


If I set my logging interval to as low as 1sec, sysinfo writes to SD quite often, I see my LED blinking about every estimated 3-5secs.


As agreed for SD card longevity a lower write interval would be good, somehow in balance with the risk of a potential data-loss for the duration of the last 1 interval in case of a crash.


Logging time continuum:


It seems a timeshift occurs over time.


Run every x seconds + delay from OS + app, instead of run every x seconds as thread, to ensure precise timing.
 
Last edited by a moderator:
My charging graph:


Pandora Charging Graph 2012-10-16.png


Additional SysInfo:


4240 mAh Design charge


3869 mAh Full charge


Graph analysis:


2500 mAh At this point, charging reduces drastically, practically stalls.


Other observation:


Before my repair I had funtastic runtimes with SuperZaxxon, could have chimed in to @Kumaki, who later wrote The Battery Life Is Incredible!


I had 15-30h of gameplay! Now I have comparatively disappointing 6-10h of gameplay.


Conclusion:


The battery health status (ratio actual achievable charge / design charge) is not reliable!


(2500/4240 is rather 59% as opposed to SysInfo's "90% health")


Certainty: The battery or its charging is not functioning well. I could verify that to a certain precision with manual logging, and now with SysInfo logging even more easily and precisely.


Uncertainty: Probably the new board I got into the Pandora after repair drains more power than the previous one?


Software as a factor can be excluded, as I flashed the new board it with the exact same version as my previous board.
 
Last edited by a moderator:
Conclusion:


The battery health status (ratio actual achievable charge / design charge) is not reliable!


(2500/4240 is rather 59% as opposed to SysInfo's "90% health")


Certainty: The battery or its charging is not functioning well. I could verify that to a certain precision with manual logging, and now with SysInfo logging even more easily and precisely.


Uncertainty: Probably the new board I got into the Pandora after repair drains more power than the previous one?


Software as a factor can be excluded, as I flashed the new board it with the exact same version as my previous board.

It's worth asking ED or Notaz what they think is happening there.
 
It's worth asking ED or Notaz what they think is happening there.
Of course!


I had put my feedback & conceptual efforts into this co-operation with _wb_ in order that the community and also OpenPandora's repair workshop gets a reliable monitoring & logging tool, which easily enables you to conduct long time studies, particularly necessary for troubleshooting power-related issues.


This night I contacted ED with my findings, and he already replied!


We are resolving this issue now, I hope.
 
Thanks for the detailed feedback, porg! I agree with all your points and will try to make those improvements.


Only thing that's a bit tricky is the timeshift issue - I could try to make it more precise, but I want to make sure that the overhead of running the logging remains low (I don't want the logging to wake up the cpu too often because that has an impact on the CPU and power measurements). By the way, for that reason it's best to put the program in the help screen when you're doing long-term measurements, because that screen doesn't need to be refreshed, which saves quite a bit of cpu/power. So I'll have to be careful - I don't want to do more wake-ups than what I'm doing now. It should be possible to get it more precise though.
 
Thanks for the detailed feedback, porg!
You are welcome! I thank you for advancing the project!

I agree with all your points and will try to make those improvements.
Glad to read that!

Only thing that's a bit tricky is the timeshift issue - I could try to make it more precise, but I want to make sure that the overhead of running the logging remains low (I don't want the logging to wake up the cpu too often because that has an impact on the CPU and power measurements). So I'll have to be careful - I don't want to do more wake-ups than what I'm doing now. It should be possible to get it more precise though.
Delay per se is ok, as long as the delay is always the same. (i.e. log interval 10 + delay 0.5)


But as dumb spreadsheet apps do not normalize irregular intervals, a delay variing over time (0-3 seconds), will produce a distorted graph.


But if regular intervals are too much effort for sysinfo, then it might be easier to handle that responsibility over to external tools, to use time-axis normalizing apps.

By the way, for that reason it's best to put the program in the help screen when you're doing long-term measurements, because that screen doesn't need to be refreshed, which saves quite a bit of cpu/power.
That info would be worthy in the help & repo.

SD writing interval: If I set my logging interval to as low as 1sec, sysinfo writes to SD quite often, I see my LED blinking about every estimated 3-5secs. As agreed for SD card longevity a lower write interval would be good, somehow in balance with the risk of a potential data-loss for the duration of the last 1 interval in case of a crash.
This my question also concerned the topics efficiency and "as little side effects as possible". Answer appreciated.
 
SD writing interval: If I set my logging interval to as low as 1sec, sysinfo writes to SD quite often, I see my LED blinking about every estimated 3-5secs. As agreed for SD card longevity a lower write interval would be good, somehow in balance with the risk of a potential data-loss for the duration of the last 1 interval in case of a crash.


This my question also concerned the topics efficiency and "as little side effects as possible". Answer appreciated.

At the moment it simply writes at the same rate as the logging interval - if you set it to 10 seconds, it will write every 10 seconds, if you set it to 1s, it'll write every second. Of course the operating system might buffer some of those writes - but I think the writeback setting is set really low on the Pandora to avoid data loss when you eject a card. I could buffer some writes from the program side, but I don't think it's that important - I don't think there's much use for logging every second, an interval of 10 seconds to 1 minute makes more sense. I could still buffer those, but I don't think the overhead of a small write to SD every 10 seconds is going to be significant.


If you're really worried about it, you can make a folder in /tmp (which is in RAM) and make appdata/sysinfo a symlink to that folder, so it effectively logs to RAM. Then you don't have any SD card overhead at all, but of course all logs are gone when you reboot.


Maybe someone (perhaps me ;) ) could create some gnuplot example files to produce graphs from the logfiles; they should take the timestamp as x-value so it gives reliable graphs even if you change the log interval and pause/unpause etc. It might be a good idea to add a field with the timestamp as a POSIX number (seconds since 01/01/1970), because that's much easier to process.
 
/tmp (ramfs) in combination with symlink: Not very practicable, as most users have FAT formatted SD cards, symlinks not possible. But thanks for the hint.


I'd suggest that you buffer SD writes for 10 seconds. If the interval is below, then one gets buffered writeing, if it is above, then it is written just in time. At termination time the buffer shall be written as well (to not discard the last 10 seconds).


Graphing templates: Fine idea! Also fine would be a server based service, at best a plugin for this forum software. One uploads the CSV and on the server the graph is plotted, and made available for display.
 
Last edited by a moderator:
OK, I managed to fix the timeshift issue without using any more resources. In the previous version I did essentially just SDL_Delay(1000) between measurements, so the timeshift was very large since measuring and drawing can take maybe 200ms. The simple way to fix it is to do something like SDL_Delay(1000 - ticks_spent_in_last_iteration), but that still causes a long-term timeshift because the delay has only a 10ms accuracy and the errors add up.


I used a rather neat simple trick: the gist of it is to do SDL_Delay(1000 - (SDL_GetTicks%1000)). In the long term, that modulo thing will ensure that you still reliably get one measurement per second.


(The real thing is a bit more complicated because to keep the interface responsive, I have to do intermediate polls of key events - you don't want to wait up to 1 second before it reacts to keypresses. Also the battery screen gets refreshed twice per second.)


Meanwhile I'm implementing your other comments. The only thing I'm not gonna do is to display the log filename when you stop logging - I don't think that's very useful because nobody will remember such long filenames, and you're probably going to see the logfiles alphabetically ordered which means the most recent one will always be the last one in the list, so that's easy enough.


Server based plotting service would be possible but quite a bit of work to make it work reliably. It might be easier to package gnuplot in a PND and add some basic zenity stuff to select a logfile to plot.
 
I reworked the help screen a bit, is this better?


helpscreen.png



Suggestions are welcome.


In the next version I'm planning to include a copy of gnuplot and a simple script that creates plots from logfiles. Here's an example:


plot-charge.png



Here's another example:


plot-power.png



Both plots are generated from the same logfile, it's just showing different fields. I tried to get my Pandora to use as little power as possible (close the lid, disabled wifi etc) around 14:30, and then I tried to make it use as much power as possible around 14:55. As you can see, standby takes about 0.1 Watt, normal use about 0.6 Watt, and the maximum I got was about 3.6 Watt - that's with the cpu stress test running while downloading files over wifi and copying very big files from one SD card to the other with the backlight at max, USB and bluetooth enabled, and playing Super Mario 64.
 
ok.. this is great... but where abouts on the menu does it install it to? I can`t find it... if I move the pnd so I can view it in the menus it runs ok.. but when I open pndmanager and click on update it doesn`t update because I moved the pnd ( so I can run it )


Darren
 
Back
Top