Page 12 of 16 FirstFirst ... 278910111213141516 LastLast
Results 221 to 240 of 306
  1. #221  
    Quote Originally Posted by NickDG View Post
    Any way to integrate CPU load and EVDO/WiFi data throughput into the graph?
    I'm considering other data to be included, but Govnah already tracks most CPU data (or is this something different than the load thing in it?) and netstat tracks data usage (not sure if both evdo and wifi). What do you have in mind for integrating monitoring and graphing those two things? The better picture I have the easier it will be for me to do it. The down side may be needing service dependencies that aren't part of a device out of the box.
    As requested: for my works on webOS patches and apps. Twitter: @larryboytw Patches: Small icons browser start page, 5x5 launcher. I have an AAS CIS Programming degree. I enjoy working on open source projects and alpha and beta testing.
    http://install.preware.org/ for easy to get up and running for patches and apps.
  2. #222  
    Quote Originally Posted by StoneRyno View Post
    Am I the only one or is the forum saying there are more pages and posts than there really are in this thread? Example at the time of posting this it shows to me there are 12 pages and 221 posts (222 with this post) yet this is post #217.



    Drain per hour over time graph is simply the drain per hour from each poll graphed over time. It was one of the requests and seems to be somewhat useful to see that average over time. I'm not quite sure the best way to go about really short term tracking of any one piece of data. Especially the percent drain and mA averages since it seems at least 60 polls are needed for somewhat reasonable accuracy and ideal accuracy after about 120 polls. But that is why I added the mA over time graphing and which is more like what you are looking for. It graphs the mA consumption at the time of each poll over time rather than the average for the total run time. This is the best way to observer current usage conditions and see exactly when periods of higher consumption occur.

    For example when the device is running idle the mA over time graph will show say about 10 mA give or take or less with occasional increases to about 30 to 50 mA give or take indicating a poll occurred at or near background activity other than Battery Monitor. During active usage with the screen on the mA over time graph will jump up to say 100 mA give or take depending on brightness setting and intensity of the app(s) in use. Running a 3D game or similar intensive app could indicate 100s of mA over the period of time the app(s) were in use.

    Now back to the drain per hour graph it is best used for observing impact to total expected consumption. The percent drain calculations really serve very well in projecting how much longer before the battery dies. The graph gives a good observable up and down of the impact of certain usage has on how much time is left before the battery dies. The drain per hour is more or less in between the mA at the time of each poll and the mA average for the total run time. Because of the way it is calculated it is more influenced by periods of increased usage than the mA average.
    Wow, I'm rather confused by that!

    My mA drain seems to be more like 200-400 when I have the screen active, at only 20%. Not sure why it's so much higher than what you wrote.

    What I think would be helpful is a way to calibrate the mA drain to an equivalent % per hour. That's the value that is most meaningful to me, because it's directly related to the amount of time the device can be used on a single charge. The % per hour that's calculated since the time BatteryMonitor was launched only tells you the average use over time, and that includes a certain fraction of the time when the Pre is awake and a certain fraction when it's asleep, which isn't really helpful because it only reflects your pattern of use during that time interval, which is meaningless IMO unless you keep a detailed record of your activities during that time.

    To get a reading on % per hour under a specific condition, we'd have to relaunch Battery Monitor for each different condition. Instead, perhaps you could give us a button to tap that would reset everything to zero (but still keep graphing) and type in a note to record which condition was being tested for the next interval of time.

    Alternatively, you could give us the slope (derivative) of the curve of % vs. time. That would represent the % per hour used under the current conditions. I don't understand why you need so many polls to create an average. I'd think that 5-10 would be enough. If it fluctuates a bit, that's OK. The derivative of the curve is always noisy; that's just the way things work. There's a trade-off between smoothness and detail.
  3. #223  
    Quote Originally Posted by Dr.Grace View Post
    Wow, I'm rather confused by that!

    My mA drain seems to be more like 200-400 when I have the screen active, at only 20%. Not sure why it's so much higher than what you wrote.
    Sorry you are confused I tried to keep it simple. If there are specific points you would like me to clarify let me know and I'll do my best make it clearer. When the screen is active you will see the mA fluctuate as you have observed. I made an omission typo my wording should have been to say at least 100 give or take. In my testing for how much certain aspects consume the average over about 200-300 polls with screen on but not actively doing anything resulted in average of 150mA with about 35% brightness. Which means on my device at that brightness running idle with screen on consumes about 120mA more than the device running idle with screen off.

    Quote Originally Posted by Dr.Grace View Post
    What I think would be helpful is a way to calibrate the mA drain to an equivalent % per hour. That's the value that is most meaningful to me, because it's directly related to the amount of time the device can be used on a single charge.
    I had considered this when working on the graphing feature changes and additions. I posted something about it in one of my feature idea posts but I think it was more like a footnote. Percent drain and remaining time can be predicted using mA and mA average but will require users to supply the mAh capacity of their battery for the app to make the calculations. I'll have to figure out what calculations are needed.

    Quote Originally Posted by Dr.Grace View Post
    To get a reading on % per hour under a specific condition, we'd have to relaunch Battery Monitor for each different condition. Instead, perhaps you could give us a button to tap that would reset everything to zero (but still keep graphing) and type in a note to record which condition was being tested for the next interval of time.
    I have observed this and I agree if you want to do both long term and short term (task specific) monitoring you have to chose one or the other. I'm considering how to best handle providing both. I'm considering making the short term (task specific) tracking perhaps a menu command that will store a 2nd set of data that starts when the menu item is tapped and end when the user taps the menu item to end it. And provide output of that data in a list below the current list and a graph view for the short term data. I have to work out programmatically how this will be done.

    Quote Originally Posted by Dr.Grace View Post
    Alternatively, you could give us the slope (derivative) of the curve of % vs. time. That would represent the % per hour used under the current conditions. I don't understand why you need so many polls to create an average. I'd think that 5-10 would be enough. If it fluctuates a bit, that's OK. The derivative of the curve is always noisy; that's just the way things work. There's a trade-off between smoothness and detail.
    I have no idea what math formula I need to use to do a derivative calculation thing. The number of polls is just what I observed in testing for best accuracy. Due to how wildly mA fluctuates an average of only 5 or 10 polls simply is far too short for task specific consumption accuracy. I'm working on adding mA average to the graph. It will likely look like a wave to begin with and narrow down to a flat line when optimal accuracy is reached. In testing just now with my 2600 battery screen left on and listening to pandora it took 8 minutes (32 polls at 15s interval) to begin to register a drain per hour with the initial 1% decrease in percent left. At 15 minutes (60 polls at 15s interval) mA average begins honing in on the optimal accuracy and the up and down change narrows significantly. Drain per hour because it is more predictive using amount of drain and total run time in its calculations is still quite wavy until about 22 minutes (88 polls) where it begins to narrow in but never really levels off to flat. Which is why I added the mA average to get a really accurate gauge for specific task consumption.

    Anyways so for the next version I'll get the mA average incorporated into the mA graph (personally been thinking it would be nice to see both in one); and expressing both mA values as percents, add that as a list item, and graph option. Hopefully it won't take me too long but I'll spend as much free time as I can working at it. Got a busy week ahead or two ahead of me.
    As requested: for my works on webOS patches and apps. Twitter: @larryboytw Patches: Small icons browser start page, 5x5 launcher. I have an AAS CIS Programming degree. I enjoy working on open source projects and alpha and beta testing.
    http://install.preware.org/ for easy to get up and running for patches and apps.
  4. #224  
    love this ap use it every day and stoneryno I love the things you are doing - I have noticed a large difference in he cpu temp reported by battery monitor and govnah / cpuscaler with battery monitor consistently 5-10 degrees cooler - just an observation

    Thanks
    -------------------------------------------------------------------
    Rob Chilcott

    Twitter @robchilcott
    pre2
    " I am only a stupid electrician after all"

    My house is a webOS house
    My pre 2, Touchpad 32g
    Wife Pixi, touchpad 32gb
    Daughter -- my old pre+
    of course my 16 year old son has and droid incredible but i think i remeber finding him on the porch
  5. #225  
    Progress update:

    I have added a page indicator between the back and forward buttons for how many graph segments there are. It also defaults to the newest segment rather than the beginning. Also added the mA average to the mA graphing in blue. I'm trying to figure out a way to set the y axis top of all graph segments the same for both drain per hour and the mA graphs. After running a few times I realized the varied scale from segment to segment could be confusing when looking at a glance for usage patterns.

    In the mean time I'll implement mA expressed in percent feature which will require input in the settings for the mAh size of the battery. This will also have a graphing option. And last but not least would anyone want to be able to graph voltage?

    Quote Originally Posted by mespiff View Post
    love this ap use it every day and stoneryno I love the things you are doing - I have noticed a large difference in he cpu temp reported by battery monitor and govnah / cpuscaler with battery monitor consistently 5-10 degrees cooler - just an observation

    Thanks
    The query to the service would be taking place at different times and will result in variation in reported temperature. I'm sure the sensor is probably checking the temp at least once a second the temperature will vary each time the sensor checks the temperature. How much it can vary I'm not sure but the code I use for reporting the temperature is the same code from Govnah so I wouldn't expect to see a constant big gap unless there just happens to be activity during Govnah poll and lack of activity when Battery Monitor poll occurs. If you open both Battery Monitor and Govnah at the same time with battery monitor set to, for testing purposes, 15 seconds and Govnah 1 second. And stream music in the background so there is relative consistent activity. Watch battery monitor for each poll and immediately check Govnah at each poll and see what each reported. In a short testing of about 6 polls at 15 seconds both are reporting same or withing 2 deg of each other.
    As requested: for my works on webOS patches and apps. Twitter: @larryboytw Patches: Small icons browser start page, 5x5 launcher. I have an AAS CIS Programming degree. I enjoy working on open source projects and alpha and beta testing.
    http://install.preware.org/ for easy to get up and running for patches and apps.
  6. #226  
    Any idea when the update will hit preware????
    Last edited by graffix31; 05/18/2010 at 11:51 AM.
  7. #227  
    Quote Originally Posted by graffix31 View Post
    Any idea when the update will hit preware????
    It is now showing up in preware. Whatever happened to cause it to not originally get published has now been corrected. Please note when searching for it by typing in the name that I have a space in the name "Battery Monitor" vs the original name "BatteryMonitor". Also reminder, when updating from versions 1.0.5 and earlier if I remember correctly you may end up with two different installed versions or two different instances of the name listed in the devices installed app list due to adjustments to the appinfo to distinguish having both the original listing and a listing for the updates. To avoid that simply uninstall the older version and then install the new version. Future versions this won't be necessary as I see no reason to have to change the appinfo in the future.
    As requested: for my works on webOS patches and apps. Twitter: @larryboytw Patches: Small icons browser start page, 5x5 launcher. I have an AAS CIS Programming degree. I enjoy working on open source projects and alpha and beta testing.
    http://install.preware.org/ for easy to get up and running for patches and apps.
  8. #228  
    Quote Originally Posted by StoneRyno View Post
    It is now showing up in preware.
    I'm not seeing it in Preware. What feed is it in? I have some disabled. Under "List of Everything" I type in "Battery" and I see the older version 1.0.3 by Neville but I don't see your updated version.
  9. #229  
    Quote Originally Posted by StoneRyno View Post
    I have no idea what math formula I need to use to do a derivative calculation thing.
    This web page contains a formula for taking a derivative from 5 data points (the central value plus two above and two below):

    Discrete Derivative (LTPDA Toolbox)
  10. #230  
    i dont see the update in preware either
  11. #231  
    Quote Originally Posted by Trekker View Post
    I'm not seeing it in Preware. What feed is it in? I have some disabled. Under "List of Everything" I type in "Battery" and I see the older version 1.0.3 by Neville but I don't see your updated version.
    It shows up when I search it from the precentral site apps section but I guess I should have checked that it was seeing it in the feed in preware instead of the search result being as a result of me having it installed. Perhaps there is a delay arriving in the feed vs showing up on the precentral site.

    Quote Originally Posted by Dr.Grace View Post
    This web page contains a formula for taking a derivative from 5 data points (the central value plus two above and two below):

    Discrete Derivative (LTPDA Toolbox)
    I'll take a look at this and see what I can do with it.
    As requested: for my works on webOS patches and apps. Twitter: @larryboytw Patches: Small icons browser start page, 5x5 launcher. I have an AAS CIS Programming degree. I enjoy working on open source projects and alpha and beta testing.
    http://install.preware.org/ for easy to get up and running for patches and apps.
  12. #232  
    It's showing up in Preware now.
  13. #233  
    Quote Originally Posted by StoneRyno View Post
    It shows up when I search it from the precentral site apps section but I guess I should have checked that it was seeing it in the feed in preware instead of the search result being as a result of me having it installed. Perhaps there is a delay arriving in the feed vs showing up on the precentral site.
    The delay was caused by a problem on the ipkg.preware.org server related to having to rebuild all the packages so that Preware could avoid the webOS 1.4 bug that kills your phone, email and messaging when you install homebrew.

    It's fixed now.

    Apologies for the delay.

    -- Rod
    WebOS Internals and Preware Founder and Developer
    You may wish to donate by Paypal to donations @ webos-internals.org if you find our work useful.
    All donations go back into development.
    www.webos-internals.org twitter.com/webosinternals facebook.com/webosinternals
  14. #234  
    I would like to get opinions on the setting item to input the battery mAh for the mA as percent request. It could be a list selector showing the existing capacities (would require updating for each new size that comes out). Or it could be some sort of text entry like a text box in the list item or a popup dialog asking for the battery capacity. Personally I think I prefer the list selector but I wanted to get opinions before I finish off the feature.

    Quote Originally Posted by Dr.Grace View Post
    This web page contains a formula for taking a derivative from 5 data points (the central value plus two above and two below):

    Discrete Derivative (LTPDA Toolbox)
    Unfortunately this math is either over my head or there is insufficient info in the link for me to understand how to apply it to battery monitor. If someone is willing to work with me to apply the formula I can add this method.
    As requested: for my works on webOS patches and apps. Twitter: @larryboytw Patches: Small icons browser start page, 5x5 launcher. I have an AAS CIS Programming degree. I enjoy working on open source projects and alpha and beta testing.
    http://install.preware.org/ for easy to get up and running for patches and apps.
  15. #235  
    Quote Originally Posted by StoneRyno View Post
    I would like to get opinions on the setting item to input the battery mAh for the mA as percent request. It could be a list selector showing the existing capacities (would require updating for each new size that comes out).
    I think the list selector is the best idea. There aren't that many to add and I doubt we'll see new capacities added.
  16. #236  
    I have laid the foundation for the mA represented in percent so all I need to do is get the option added to settings for users to pick their battery capacity. And format the info in the list. I was trying to keep it all as one list item but can't find a solution for multiline label and data. I started a thread in the developer section but so far no responses. I guess I'll stick with my original thought of having the info as two different items in the list which just means more text on the screen than I had wanted unless someone knows how to get newline/carriage return code to work with the strings for the list item.
    As requested: for my works on webOS patches and apps. Twitter: @larryboytw Patches: Small icons browser start page, 5x5 launcher. I have an AAS CIS Programming degree. I enjoy working on open source projects and alpha and beta testing.
    http://install.preware.org/ for easy to get up and running for patches and apps.
  17. #237  
    Hi!

    Why I didn't have any graph information in my Battery Monitor 1.0.6? It doesn't matter what I choose in the setting it doesn't show any graph, even not after hours.

    It is the first time I installed Battery Monitor.

    What did I missed?

    Greetings
    Haddock
  18. plee3ac's Avatar
    Posts
    109 Posts
    Global Posts
    115 Global Posts
    #238  
    Quote Originally Posted by Haddock View Post
    Hi!

    Why I didn't have any graph information in my Battery Monitor 1.0.6? It doesn't matter what I choose in the setting it doesn't show any graph, even not after hours.

    It is the first time I installed Battery Monitor.

    What did I missed?

    Greetings
    Haddock
    I believe the graph only shows up if turning your phone sideways into Landscape mode.

    Hope this helps... plee3
  19. #239  
    Quote Originally Posted by plee3 View Post
    I believe the graph only shows up if turning your phone sideways into Landscape mode.

    Hope this helps... plee3
    This is correct rotating to landscape mode will show the graph. This allows for a full screen graph and the ability to track near infinite data. Originally it was limited to less than 100 polls give or take and the small graph size didn't work so well for tracking the other details. Also assuming it was over looked make sure graphing is set to on. A side note having the graph displayed in landscape more the way it is now reduces processing because google isn't contacted every poll and the graph isn't redrawn every poll. Now those are done only when rotated to landscape to view the graph. Battery Monitor continues to store the graph data and the graphing is updated on demand as a result of rotating to landscape.
    As requested: for my works on webOS patches and apps. Twitter: @larryboytw Patches: Small icons browser start page, 5x5 launcher. I have an AAS CIS Programming degree. I enjoy working on open source projects and alpha and beta testing.
    http://install.preware.org/ for easy to get up and running for patches and apps.
  20. #240  
    Hi!
    Quote Originally Posted by StoneRyno View Post
    This is correct rotating to landscape mode will show the graph. This allows...
    You're right, I've found it by myself in the meantime. I was allways looking for the small graph like in the screenshots I saw, but then by random I got it in the landscaope mode. Oh man...

    But last night on work I noticed two reboots of the PrPrPr+ $during$ $working$ $in$ $the$ $Photo$ $and$ $Contact$ $applications$. $Because$ $I$ $assumed$ $Battery$ $Monitor$ $as$ $a$ $possible$ $reason$ $I$ $stopped$ $using$ $it$ $after$ $first$ $half$ $of$ $the$ $night$. $Without$ $running$ $BM$ $there$ $was$ $no$ $more$ $reboot$ $but$ $it$ $has$ $to$ $bear$ $in$ $mind$ $that$ $I$ $did$ $not$ $try$ $to$ $reproduce$ $the$ $situation$ $explained$ $above$. $Could$ $it$ $be$ $that$ $the$ $Pr$+ $could$ $be$ $unstable$ $when$ $using$ $Battery$ $Monitor$? $It$ $seems$ $for$ $me$ $that$ $the$ $reboots$ $happens$ $when$ $several$ $layers$ $were$ $opened$ $and$ $all$ $of$ $them$ $using$ $resources$.

    By the way: Due to the reboots the datas of BM were lost. Could it be made to save these datas for a period so you can recall them to get an info for that period in a graph?

    Haddock

Posting Permissions