Page 10 of 16 FirstFirst ... 56789101112131415 ... LastLast
Results 181 to 200 of 306
  1. #181  
    Quote Originally Posted by Trekker View Post
    I don't see the point of a 1 second interval. You're just going to use up the battery quicker and tracking battery discharge second by second doesn't seem to make a whole lot of sense.
    After testing yes it does drain the battery quite significantly more so does the 5 second. I was just going on the idea for quick tests like how much does such and such drain but I think 5 sec is sufficient for that. as the difference in drain between the two seem negligible. But since it is only one line of code that had to be added to make it happen for testing I can leave it in unless it is a bad idea to do so. I am going to do another test run or two on the different intervals to satisfy my curiosity at how much mA for each interval. While I work out how the data will be logged. With that in mind should I just automatically log all data all the time or should I provide it as a toggle option?

    Oh I did observe the higher the poll count the more additional polls are required before mA average is accurately reflected for the consumption of a specific task. That is to say if you have say a poll count of 600 (10hrs at 1m poll) and load pandora without restarting battery monitor you may have to wait for a good number of polls to get accurate data on the average consumption of the app. Which is another reason why I'm running tests to see how many polls for best accuracy.
    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. #182  
    Would anyone be interested in having an option choosing between current method of predicting the remaining hours and a method based on the average mA? This would require users to enter the size in mAh of their battery 1150, 2600, etc since as far as we know there is no way to get that info since in previous versions the data was reported incorrectly from whatever service provides it. It may very well not be any more or less accurate than current method until it is tested.

    After giving the logging feature thought for several days so far I have not decided on the way I want to proceed. I'm thinking the best way to handle it may be to store each poll in an array and then provide a menu item for saving the log so that users can name the log. I figure this allows for tracking of specific scenario like what does the data look like while running pandora for say an hour. The user could save the log then as pandoratest. The data would be processed from the array into a table in a database or something else if there is a better wya to store it, and could be opened later to view charts of the data. Storing the poll data in an array would also allow for users to view a chart of the data stored to that point using a menu item to go to a view chart scene.

    I considered auto log to a database by creating a new row during each poll. However two thoughts come to mind on doing it this way. What naming convention to use for each collection of data so that all collections aren't lumped into a single table. Very large tables, potentially 1000s even 10s of 1000s of records would add up quickly, would take significant time to work with the data such as loading it into a chart. Not to mention most aren't going to want to see all the data that has even been tracked. The other thought is what effect if any would saving the data to a database in this way have on the performance of battery monitor. Not to mention I think the coding may be more complex to go this route.

    So before I proceed I would feel better having opinions from other developers on the better way to go at 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.
  3. #183  
    Thanks to StoneRyno for taking up the reins on this ap -- it is one that i downloaded the day i got my + and it gets used daily

    i have a question and a suggestion

    1) the suggestion -- is there away for the ap to sense when the pre is on a charger? and if so could the ap be set to either pause or start reading when removed from the charger?

    2) the question -- where will i be able to get the updated ap?


    additionally i agree with the run in the back ground sug. +1

    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
  4. #184  
    Quote Originally Posted by mespiff View Post
    1) the suggestion -- is there away for the ap to sense when the pre is on a charger? and if so could the ap be set to either pause or start reading when removed from the charger?

    2) the question -- where will i be able to get the updated ap?


    additionally i agree with the run in the back ground sug. +1

    thanks
    Yes I can use mA to know if it is being charged or not. mA is a positive number when charging and negative when charging stops. And I will assume I can stop and start polling again based on that. However if left on the charger once it has completely charged it would stop and start during the top 5% discharge/charge cycle. Not that it would be an issue unless it partially powers the device from the charger reducing the discharge rate (mA consumed). And in that case it could skew the data collected. But it is worth looking into.

    I was rather hoping for dev access by now but I'm guessing details are being worked out for that. So in the mean time I guess I'll post it here. I was preferring to have it in the feed so that preware et al could have access to it and the original listing. For now I guess I'll post it here. I've tested it on my pre and everything seems to be working fine. While I wouldn't say it is a beta, but since the new feature has only been tested on my pre it is possible bugs could be found as other use it.

    Updating Info

    You may need to uninstall the previous version. I added a space in the name so that the name under the icon is Battery Monitor instead of BatteryMonitor. When I installed it to my pre from eclipse during testing it was treated as a different app even though the only change to the app info was the space in the name and version number the app id is the same.

    Battery Monitor 1.04 changes

    New settings scene for settings and settings are now remembered. Note if uninstalled settings will revert to defaults. Note changes to settings apply to the main as soon as you gesture back to the main scene. Polling isn't interrupted and doesn't reset just as before.

    Main scene now contains details formerly in the detailed battery info scene. The detailed battery info scene is still present and may likely be used to provide other details in the future.

    In addition it tracks the average consumption (mA). Best use is average consumption of all use, but is als a good way to measure how much a certain app or task consumes. For example running pandora for an hour. Best to restart Battery Monitor for that sort of tracking since the more polls already averaged the multiple more needed to accurately measure the average consumption of a specific task. Note 60 polls minimum for decent accuracy, 90 for better, and at least 120 for greater to best accuracy.

    Added 1 second and 15 second intervals for polling. Test results pending but initial testing indicates 1 and 5 second intervals consume much more battery and are only suited for testing specific things like how much does listening to pandora consume. But you will need to test how much the interval itself consumes to subtract from the results. I may remove these two once test results are done because preliminary tests indicate 15 and 30 second intervals consume marginally more if any increase at all vs 1 minute.
    Attached Files Attached Files
    Last edited by StoneRyno; 04/15/2010 at 02:24 PM.
    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.
  5. #185  
    i have installed and the interface looks nice -- well let you know how it works


    thanks

    Rob
    -------------------------------------------------------------------
    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
  6. #186  
    I have to say that I have been looking for an update for the last several days (been months since update).

    So I jumped onto the forum and after reading a little bit and I learned that the original creator has decided to work on other projects. While that is disappointing, I was VERY impressed that he left the code open to anyone to tweak and continue his work. For that I am VERY THANKFUL.

    As for the new version, I like the new layout. The 1 feature that I am impressed with is that it retains the previous settings. Very nice addition.

    Mentioned before was the ability to have the program run in the background (much like Brightness Unlinked does now). I can see times that people would want to monitor there battery usage for extended times w/o the active card. Of course this would depend on how well it will run in the background.

    Another feature that "maybe" helpful, is some kinda data logging feature. Where it would save the data to some kinda file with the intervals data.

    ie. Every 5 mins (or what ever the interval was), it would save the interval, initial battery %, current battery %, etc into a text file. Then every interval append the new data onto the next line.

    Of course this would allow users to view the file (either on computer or doc viewer) and can see how it reacts through out the day. Like a longer version of the data graph.

    With that said, im happy with the app as it stands now and cant wait to see how it improves over the months.
  7. #187  
    Both data logging and run in background are in my plans. I'll probably save run in background for last. I'm working on drain per hour over time graph option vs percent remaining. That way users can choose which graph they would prefer to have generated during polling. I'm testing a preliminary design of that feature as soon as my battery fully charges.
    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. #188  
    I have played around experimenting with the graph. Currently I have set the graph to height 420 and width of 660. The scene can also now scroll horizontally respectively. This means the chart is slightly more that twice the size it was before. I have also modified the number of polls recorded for the graph. The google chart API has a limit of 2,000 characters in the URL this means somewhere between 400 and 500 data points for the chart can be kept. Originally it was coded with a limit of about 65 data points. Also there is now a chart option to choose percent remaining over time, drain per hour over time, or mA (per poll not running average) over time. Anyone have any feedback, positive or negative, on these changes?
    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.
  9. #189  
    Quote Originally Posted by StoneRyno View Post
    I have played around experimenting with the graph. Currently I have set the graph to height 420 and width of 660. The scene can also now scroll horizontally respectively. This means the chart is slightly more that twice the size it was before. I have also modified the number of polls recorded for the graph. The google chart API has a limit of 2,000 characters in the URL this means somewhere between 400 and 500 data points for the chart can be kept. Originally it was coded with a limit of about 65 data points. Also there is now a chart option to choose percent remaining over time, drain per hour over time, or mA (per poll not running average) over time. Anyone have any feedback, positive or negative, on these changes?
    I have an ap called fillups -- it graphs the mpg for my car -- it shows the graph when the pre is turned on its side and returns to the data screen when rotated back -- that is a pretty cool feature -- have you seen this it might be a cool way to make the more robust graph you are talking about more visible -- i like the idea of more info on the graph -- i have been using your version of this ap since you posted it and it is working great --

    are you posting changes at the location above?

    thanks for your work
    -------------------------------------------------------------------
    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
  10. #190  
    Quote Originally Posted by mespiff View Post
    I have an ap called fillups -- it graphs the mpg for my car -- it shows the graph when the pre is turned on its side and returns to the data screen when rotated back -- that is a pretty cool feature -- have you seen this it might be a cool way to make the more robust graph you are talking about more visible -- i like the idea of more info on the graph -- i have been using your version of this ap since you posted it and it is working great --

    are you posting changes at the location above?

    thanks for your work
    Sounds like a possible solution. The main thing is getting the aspect ratio correct so the graph doesn't look funky. I made an error in my math on the aspect ratio in my last post. 420x630 would maintain the 1:1.5 ratio. If I were to allow landscape in the app to do as you describe to avoid having to scroll the graph both horizontally and vertically the height would have to be 320. Which I don't see as a problem. However 400 data points would be crammed if I maintain the screen ratio with the width at 480. I'll have to experiment with the ratio to see what the graph will look like. The landscape mode thing should be easy enough to do. I would have to dynamically create the scene html in the scene assistant so that it's content changes with the orientation.

    I had also toyed with the idea of the chart being it's own scene with a menu item to open the scene. All that would require is passing the variables used in the URL to the new scene then I could rotate the graph in the scene instead of messing with orientation code. This would generate the chart with the current data set and at the same time remove the repeated calls to the chart API for each poll. Since technically as the user base grows the calls could reach the "abusive" level which google reserves the right to block in that case. So I guess this opens a new question have the chart in it's own scene rotated for landscape viewing or turn on ladscape mode so changing the orientation changes the content on the main scene between the list of info and the chart? Both would remove per poll calls to the chart API as a call would only be needed when the orientation changes or when the new scene is opened.
    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.
  11. #191  
    this application is great, but I think it would be more useful if you included the instantaneous drain rate as well as the average drain rate. Even if it was a simply as comparing the most recent poll results to the previous one we could have a accurate understanding of how certain tasks effect the battery in the short term...
  12. #192  
    Quote Originally Posted by Mhunterjr View Post
    this application is great, but I think it would be more useful if you included the instantaneous drain rate as well as the average drain rate. Even if it was a simply as comparing the most recent poll results to the previous one we could have a accurate understanding of how certain tasks effect the battery in the short term...
    Are you referring to the drain per hour percent? It is calculated based on the difference between the start percent and current percent divided by the run time. So in a way it is both the drain rate at the time and also an average. The mA per poll and mA average gives you more what you are asking. The capacity of the battery (ex. stock is 1150 mAh) can be compared to the mA poll and mA average to estimate usage. Ex. If the mA average is -20 then the remaining life if current remaining is 100% would be 57.5 hours. If current remaining is 50% then remaining life would be 28.75 hours. The mA of each poll can give you an idea of the varied degree of consumption moment by moment. For example when the device is idle with screen off most of the time mA will be really low with occasional spikes of varied amounts as background tasks etc occur.

    Keep in mind that mA fluctuates quick a bit due to a numbers of things outside of the user activity that draws power in varied degrees, so the mA consumption at the time of the poll in itself is only somewhat accurate of the drain of a specific task such as listening to pandora. However the mA average can be used to get the highest accuracy for this sort of thing if you start battery monitor fresh for the test. This is because with as little as 60 and as much as 120 or more polls you can get a good idea of the tasks consumption using the mA average. But the fresh start is required unless you want to run the task exponentially longer. Because if you have an mA average from 100 polls and then wanted to find out the average for accurate consumption for pandora it would take 1,000 more polls for the mA average to reflect accurately pandora's consumption. Hopefully all of this info is what you are asking about. I will have more specific info on the mA poll and mA average in another post later as I conclude my consumption tests.
    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.
  13. #193  
    ^^^I'm aware that they are both averages, but the average between the most recent 2 polls would be more accurate in predicting when my phone will die.

    lets say i've had my phone running the monitor for 5 hours idle, then i open pandora and check after 5 minutes. the estimated time of phone death would be based on the average of four hours of idle and 5 minutes of pandora. obviously that average rate is gonna be much lower than the actual rate and the estimated time of death would be worthless. If the app also displayed a rate calculated between to recent polls, i'd have a much better idea of how my reacts to certain apps as well as a way to compare it to different states without having to restart the app.
  14. #194  
    Quote Originally Posted by Mhunterjr View Post
    ^^^I'm aware that they are both averages, but the average between the most recent 2 polls would be more accurate in predicting when my phone will die.

    lets say i've had my phone running the monitor for 5 hours idle, then i open pandora and check after 5 minutes. the estimated time of phone death would be based on the average of four hours of idle and 5 minutes of pandora. obviously that average rate is gonna be much lower than the actual rate and the estimated time of death would be worthless. If the app also displayed a rate calculated between to recent polls, i'd have a much better idea of how my reacts to certain apps as well as a way to compare it to different states without having to restart the app.
    actually i think that the average would have to be more than the last couple because if your phone set idol 5 hours and then you went into a heavy use peiod for 5 minuets what is more likely to happen over the next 5 hours? 5 hours of heavy use or 5 hours of no use -- i don't know but i think we can assume to a certian degree past use will represent future use so think the longer period may be more representitive

    IMHO
    -------------------------------------------------------------------
    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
  15. #195  
    I have created a listing in the homebrew apps so that my updates can be installed by the sources that access the listings (preware etc). It is version 1.0.5. To avoid conflicts with the original app the appinfo is slightly different and upgrading from 1.0.4 and older it is likely that both will be installed or appear installed so it is best to uninstall before updating. This should not be an issue with updates after 1.0.5 since the appinfo won't change other than the version number.

    Improvements to graphing is a work in progress. Feel free to share ideas on changes to it. I'm currently pondering the two ideas so far of either showing the graph in the main scene when the device is rotated to landscape or having a new scene for the graph. Either way I figure the graph would be 320x480 so that it fits completely on the screen in landscape mode. I also figure that would allow the option to place X number of polls on more than one image side by side so that if we wanted to there could be 1,000 polls graphed with say 200 polls per image.

    Change Log:

    1.0.5

    New options for graph: Percent remaining over time, Drain per Hour over time, or mA over time.

    Graph is larger and now graphs 400 polls and the scene scrolls both directions to allow for the graph to exceed the width of the screen.

    Removed 1 and 5 second intervals.

    Quote Originally Posted by Mhunterjr View Post
    ^^^I'm aware that they are both averages, but the average between the most recent 2 polls would be more accurate in predicting when my phone will die.

    lets say i've had my phone running the monitor for 5 hours idle, then i open pandora and check after 5 minutes. the estimated time of phone death would be based on the average of four hours of idle and 5 minutes of pandora. obviously that average rate is gonna be much lower than the actual rate and the estimated time of death would be worthless. If the app also displayed a rate calculated between to recent polls, i'd have a much better idea of how my reacts to certain apps as well as a way to compare it to different states without having to restart the app.
    I'll run some tests and see what I can see running tests as you describe. This may be something I have never noticed about how the remaining time is calculated. But I think I understand it is the time remaining that is in question of accuracy?
    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.
  16. #196  
    Quote Originally Posted by StoneRyno View Post
    I have created a listing in the homebrew apps so that my updates can be installed by the sources that access the listings (preware etc). It is version 1.0.5. To avoid conflicts with the original app the appinfo is slightly different and upgrading from 1.0.4 and older it is likely that both will be installed or appear installed so it is best to uninstall before updating. This should not be an issue with updates after 1.0.5 since the appinfo won't change other than the version number.

    Improvements to graphing is a work in progress. Feel free to share ideas on changes to it. I'm currently pondering the two ideas so far of either showing the graph in the main scene when the device is rotated to landscape or having a new scene for the graph. Either way I figure the graph would be 320x480 so that it fits completely on the screen in landscape mode. I also figure that would allow the option to place X number of polls on more than one image side by side so that if we wanted to there could be 1,000 polls graphed with say 200 polls per image.

    Change Log:

    1.0.5

    New options for graph: Percent remaining over time, Drain per Hour over time, or mA over time.

    Graph is larger and now graphs 400 polls and the scene scrolls both directions to allow for the graph to exceed the width of the screen.

    Removed 1 and 5 second intervals.



    I'll run some tests and see what I can see running tests as you describe. This may be something I have never noticed about how the remaining time is calculated. But I think I understand it is the time remaining that is in question of accuracy?
    can you post a link? -- i searched i swear and could not find

    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
  17. #197  
    I think the point of having an average over a short time is that you can tell under the present conditions what the battery drain is. First you'd set a base line with no apps open, then measure battery drain again when a particular app of interest is running.
  18. #198  
    Quote Originally Posted by caj2008 View Post
    Stone Ryno,

    Would you consider making a stand alone patch that will allow internal temperature determination of the device. Perhaps you could work with WebOSInternal to do this?

    caj2008
    I assume you are referring to the CPU temp rather than or in addition to the battery temp? I was planning on including additional items to monitor during the polls. So this sounds like a good one to add. Perhaps after final exams next week when I'll have a good chunk of time to discuss what I will need to do. So far I have been writing a few lines of code here and there each day in some spare moments. Mainly experimenting with different ideas from reading all of the thread.

    Quote Originally Posted by mespiff View Post
    can you post a link? -- i searched i swear and could not find

    thanks
    It hasn't passed the approval process yet. I'm assuming it will show up in a day or two. I just wanted to let everyone know ahead of time in case they are wondering about updates.

    Quote Originally Posted by Dr.Grace View Post
    I think the point of having an average over a short time is that you can tell under the present conditions what the battery drain is. First you'd set a base line with no apps open, then measure battery drain again when a particular app of interest is running.
    This is what I had in mind as a side effect when I added the mA average over time. But to use it in that way it is best to close and open battery monitor again. Perhaps I could add a short term mA average that the user initiates and stops but runs in addition to the main polling?
    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.
  19. #199  
    I just thought of a way to allow for more data points in the graph without having to go fancy on the chart and try to use the google methods that are for more than what is needed by Battery Monitor. Without getting into code speak I'll describe it. Basically I'll store sets of 100 data points and then present each set in a separate graph. This will allow for the 320x480 size to fit to the screen landscape mode and also for viewing pretty much as much data as we want. And the graph(s) would be viewed separate from the poll info list. This gives some options on how to present the graphs.

    First two options for how to view each graph. They could be side by side and scroll through them or they can be presented one at a time and rotate through them like with a gesture or something. Second two options for how to bring up the graph(s). As mentioned before and I think I would prefer is rotate to landscape to view graph and back to portrait to view the poll info list. Or a menu item to show the graph(s) and then gesture back to the poll info list. A side effect of this so to speak which is probably beneficial, they graph is no longer redrawn every poll and google isn't called every poll. Instead it is redrawn on demand and google is only called when which ever method is used to display the graph.
    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. #200  
    I have partial progress on the next version 1.0.6. This version will include CPU temp for users who also have a kernel that supports it. I have to find out if i need to make special consideration in code if a kernel that supports it isn't present. It also will have the graph presented full screen in landscape mode when the device is rotated to either side and then the list of info displayed again when the device is rotated back to portrait mode. In addition (this is the part I have to add still) much more data can be graphed and will be presented in separate graphs in groups of 100 points. I have not decided on how to handle cycling through the graphs but I'm leaning towards gestures flick left and right. The only limit to the amount of points to store for graphing is the amount of RAM used. In other words testing to see how much to cap it at to avoid bogging down the device.
    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.
Page 10 of 16 FirstFirst ... 56789101112131415 ... LastLast

Posting Permissions