Re: [Sugar-devel] [IAEP] XO power management hindering collaboration
On Tue, May 17, 2011 at 3:14 AM, Sridhar Dhanapalan wrote: > This is with OLPC OS 10.1.3 (XO-AU 10.1.3-au2 - we haven't made any > changes that would affect reliability of collaboration). The XOs were > registered and using an XS. > > I've reported this at http://dev.laptop.org/ticket/10878 thanks for filing this! You'll see questions and discussion, because we are trying to understand what exactly it is you are seeing. The initial problem description you give us is something we strongly believe we fixed between 10.1.2 and 10.1.3 -- and we tested 10.1.3 a lot to confirm it was working. So we think that there's something else at play -- and we'll be needing for info (and needling you for it :) ). cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] [IAEP] XO power management hindering collaboration
On 16 May 2011 04:51, Samuel Greenfeld wrote: > In what build(s) is this occurring? And are you using a schoolserver or > not? > > OLPC release 10.1.3 fixed some issues with XO 1.5's waking up in response to > multicast traffic on the network. This is necessary for Salut/"under the > tree" usage to work with power management. XO-1's with 10.1.3 are > configured by default to always stay on, as they (to the best of my > understanding) historically have had an occasional issue where the network > card might not reappear after suspending. > > In 11.2.0 both XO-1's and 1.5's currently are allowed to suspend, although I > do not know if that will be the final setting. This is with OLPC OS 10.1.3 (XO-AU 10.1.3-au2 - we haven't made any changes that would affect reliability of collaboration). The XOs were registered and using an XS. I've reported this at http://dev.laptop.org/ticket/10878 Sridhar Sridhar Dhanapalan Technical Manager One Laptop per Child Australia M: +61 425 239 701 E: srid...@laptop.org.au A: G.P.O. Box 731 Sydney, NSW 2001 W: www.laptop.org.au ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] [IAEP] XO power management hindering collaboration
In what build(s) is this occurring? And are you using a schoolserver or not? OLPC release 10.1.3 fixed some issues with XO 1.5's waking up in response to multicast traffic on the network. This is necessary for Salut/"under the tree" usage to work with power management. XO-1's with 10.1.3 are configured by default to always stay on, as they (to the best of my understanding) historically have had an occasional issue where the network card might not reappear after suspending. In 11.2.0 both XO-1's and 1.5's currently are allowed to suspend, although I do not know if that will be the final setting. On Sun, May 15, 2011 at 12:40 PM, wrote: > On Sat, May 14, 2011 10:04 am, Sridhar Dhanapalan wrote: > > It's looking to us that the aggressive power management enabled on the > > XO can sometimes create confusion when children are collaborating on > > activities. > > > > Take for example a turn-based game like Memorise. If a child is > > waiting for their turn, they might leave the XO untouched. In that > > time, power management can kick in, and the XO stops communicating > > over the wireless network. Waking up the XO (e.g. by touching the pad) > > doesn't always rejoin the XO to the game properly. The whole game is > > stalled because the turn cannot be completed. > > Is this in the bug tracking system? If not, please file a bug report. (We > can help.) If it is, please add your experience to the existing bug > report. > > > Are there any ways we can manage this in our deployments? Perhaps some > > guidelines to give to teachers so that they have a reasonable > > expectation? > > An obvious workaround is to keep touching the XO so that it does not go to > sleep. > > The more clumsy process is for the active player to exit and save, then > open the saved Journal entry and share again. > > > Thanks, > > Sridhar > > > > > > > > Sridhar Dhanapalan > > Technical Manager > > One Laptop per Child Australia > > M: +61 425 239 701 > > E: srid...@laptop.org.au > > A: G.P.O. Box 731 > > Sydney, NSW 2001 > > W: www.laptop.org.au > > ___ > > IAEP -- It's An Education Project (not a laptop project!) > > i...@lists.sugarlabs.org > > http://lists.sugarlabs.org/listinfo/iaep > > > > > -- > Edward Mokurai > > (默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر > ج) Cherlin > Silent Thunder is my name, and Children are my nation. > The Cosmos is my dwelling place, the Truth my destination. > http://www.earthtreasury.org/ > > ___ > Sugar-devel mailing list > sugar-de...@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
XO power management hindering collaboration
It's looking to us that the aggressive power management enabled on the XO can sometimes create confusion when children are collaborating on activities. Take for example a turn-based game like Memorise. If a child is waiting for their turn, they might leave the XO untouched. In that time, power management can kick in, and the XO stops communicating over the wireless network. Waking up the XO (e.g. by touching the pad) doesn't always rejoin the XO to the game properly. The whole game is stalled because the turn cannot be completed. Are there any ways we can manage this in our deployments? Perhaps some guidelines to give to teachers so that they have a reasonable expectation? Thanks, Sridhar Sridhar Dhanapalan Technical Manager One Laptop per Child Australia M: +61 425 239 701 E: srid...@laptop.org.au A: G.P.O. Box 731 Sydney, NSW 2001 W: www.laptop.org.au ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO power management
On 04/19/2011 03:52 PM, Pablo Iguiniz wrote: > Hello Richard, > > This is Eng. Javier Iguiniz from Ceibal. Ismael has recently changed > work so I am now taking over part of his tasks, in particular the > testing related to the XO batteries. Welcome Javier. > I tried to catch up with the plan, so we have carried the test to > another batch of batteries we had here. The initial batch had 50 > batteries and there was all kind of them: newer and older from different > years. > From the 50 units only 28 remained functional, meaning that they could > accoplished the full charge/discharge test cycle. The damaged batteries > showed different problems, which I list below: > > Battery not recognized - "No Battery" reported , LED does not light up. This failure is possibly recoverable if you have an external 1-wire interface. Check these batteries by putting them in a XO. Stop at OFW and run 'see-bstate'. If you see a series of 0 1 2 over and over then you will need an external 1-wire interface to recover the batteries. If you see more numbers than 0 1 2 then the battery should be recoverable with OFW. > Battery recognized but error message is shown, red LED blinks This should be recoverable. Do you have a XO-1.5 handy? In the latest XO-1.5 firmware 'watch-battery' will tell you what the error is when you exit. So put the battery in a 1.5 and let the LED blink red. Then run 'watch-battery' and after it prints a line then press a key to exit. It will print out what the reported error is. > Bad data retrieved from EEPROM Please describe this more. You can get a listing of the EEPROM by running 'bat-dump-banks' from the OFW prompt. Its handy if you have a serial port connected so you can log the results. Also try to put the battery in a XO-1.5 with the latest firmware. The 1.5 firmware has code that can try and fix some types of EEPROM problems. If not then we can fix the EEPROM via OFW. > Never finishes trickle mode > Battery appears as full but doesn´t allow the XO to start > Initial tricke mode, does not charge after recover phase These are interesting. Only the 4 you show in the spreadsheet have this problem or do you have more? There are only 47 entries in your spreadsheet. > From those 28 functional batteries I´m ataching a zip file with data > collected and a file with the batteries status summary . I hope you > could find it useful.You may find some files which have a minor data > process or include a graph. Your .zip file contains mostly .xls files that have been converted from the .csv files. My processing tools cannot operate on excel files. Please send me the .csv files that olpc-pwr-log generated. They do not have to be in separate directories. You can copy them all into a single directory. > At the moment we don´t have many more batteries left. I will try to find > some more from now on. I'm confused. I thought you had hundreds of batteries to process. Thats why you needed the fast procedure. > I saw that there was another side on the investigation regarding the > information of charge and discharge cycles collected in EEPROM. I would > like to know if you had any chance to go further on this point. I've modified my processing tool to output the lifetime numbers but right now they don't appear to be useful. They don't make sense. After you send the rest of the .csv files I'll summarize the results. -- Richard A. Smith One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO power management
On 04/05/2011 09:33 AM, Ismael Schinca wrote: > Thanks! This is very useful information. I'll try to run some new tests > and try to look at the data more thoroughly. The new batteries' capacity > is pretty puzzling. I'll repeat the tests on these batteries and add a > couple more of new ones to get more results. Please continue to run the test on your other batteries as well. More data is better than lest data. Grab as many XO's as you can and run new tests daily on your stock of batteries. > I think it's a good idea to think about discarding the 07 batteries. > They are pretty old anyways. Even if you plan to recycle the < 008 batteries please continue to include them in the your tests. That way I can build up a profile of what the _actual_ capacity loss over time vs my estimates. -- Richard A. Smith One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO power management
Thanks! This is very useful information. I'll try to run some new tests and try to look at the data more thoroughly. The new batteries' capacity is pretty puzzling. I'll repeat the tests on these batteries and add a couple more of new ones to get more results. I think it's a good idea to think about discarding the 07 batteries. They are pretty old anyways. Any information regarding the total number of charge/discharge cycles would be really useful. Regards, Ismael 2011/4/4 Richard A. Smith > On 03/31/2011 03:43 PM, Ismael Schinca wrote: > >> Richard, Ceibal about to start working heavily in reworking how to >> classify used batteries. Due to the number of batteries involved, we >> were asked to devise a "good enough" procedure to estimate the battery >> condition in less than 10 minutes. The plan would be to get several >> parameters from the batteries and try to estimate it's condition based >> on them. Have you been able to analyze the results from the logs I sent >> you? >> > > Sorry. I've been very busy lately and its taken me a while to look at > them. I'm currently in route to Taiwan where I'll be for the next 2 weeks. > I've been looking at your logs on the plane. Note that after about 4pm PST > I'll be out for a day or so . After that I'll be out of sync with your > timezone (I'll be +11 or +12 or so from you) and I'll be very busy so my > responses my lag quite a bit. > > I'm afraid its difficult to make any judgments from the data you have sent > so far. You are going to have to test many more batteries to get more > data. > > I'm going to have to do some work on my processing tools to help with the > comparison. I'll try to get to that later on. > > Here's a quick look at the capacity of the batteries you have tested so > far. Thank you very much for the battery serial number in the filename that > is very helpful. Please continue to do that. I've broken up the serial > number so that we can see the age easily. The 2nd column is the ammount of > Watthours that was extracted from the battery sorted into ascending order of > Watthours. > > 00401 071229 110002160OLD.csv -4.177 > 00401 071229 110002221OLD.csv -11.663 > 00602 080608 11600.csv -13.915 > 00802 100751 10002447NEW.csv-13.992 > 00602 080616 110002384.csv -14.405 > 00802 100804 110003201NEW.csv -14.803 > 00802 090331 110002400.csv -15.066 > 00802 081130 110001133.csv -15.768 > 10102 080109 31524.csv -15.863 > 00702 080710 11901.csv -16.009 > 00802 090829 110001062.csv -15.914 > 00802 081231 11683.csv -16.576 > 00702 080714 11474.csv -16.826 > 00802 090415 110001059.csv -16.995 > 00802 090429 110002159.csv -17.705 > 00802 090206 110001307.csv -18.489 > > The first thing to notice is that it roughly correlates with age which > makes sense. The both the 004's are suffering from charge balance. > Something you can see from the charging voltage logs. If you want a quick > first pass of segregating the batteries then you can use the first 3 digits > as guide. Any battery with the first 3 digits that are less than 008 (ie, > 007,006,005,004...) is subject to charge balance. I recommend you group > your batteries int < 008 and >= 008. Depending on how many you have you may > or may not want to even try to analyze the < 008 group. > > The next thing to notice is that your batteries that you marked as NEW are > showing a capacity that is much less than expected. Those should have had a > capacity of 18Wh or more. Please re-run the test on those batteries and see > if the data is consistent. > > I've estimated that the capacity loss should be .025% per/cycle. If we > assume the rough age of the batteries is 2 to 3 years and that they average > 1 cycle per day then I'm expecting the available capacity to be in the 73% > to 82% range or 15-16 Wh. Looking at your numbers I say its right on par. > So perhaps you can also use the battery age as a guide. > > What is the minimum capacity you want to allow to be re-used? > > The attached graph shows your charging voltage in detail. As you can see > the the screen turning off and on has an effect on the voltage. This graph > also illustrates why this is going to be a difficult thing to accomplish in > only a 10 minute test. > > > Another question. Is there information in the battery controller >> regarding total number of charge/discharge cycles? >> > > There is an attempt to do that and the logs extract that information from > the EEPROM. However, I don't have any idea how accurate it is. Its legacy > code that I've never had a reason to examine closely. I'll examine the code > that does that in detail and then add decoding of the values to my > processing script next so I can take a look at the numbers. > > -- > Richard A. Smith > One Laptop per Child > -- Ismael Schinca Centro Ceibal - Depto. Técnico - I+D Avda. Italia 6201 - Edificio Los Ceibos Montevideo - Uruguay. Tel.: 2601 57 73
Re: XO power management
On 03/31/2011 03:43 PM, Ismael Schinca wrote: Richard, Ceibal about to start working heavily in reworking how to classify used batteries. Due to the number of batteries involved, we were asked to devise a "good enough" procedure to estimate the battery condition in less than 10 minutes. The plan would be to get several parameters from the batteries and try to estimate it's condition based on them. Have you been able to analyze the results from the logs I sent you? Sorry. I've been very busy lately and its taken me a while to look at them. I'm currently in route to Taiwan where I'll be for the next 2 weeks. I've been looking at your logs on the plane. Note that after about 4pm PST I'll be out for a day or so . After that I'll be out of sync with your timezone (I'll be +11 or +12 or so from you) and I'll be very busy so my responses my lag quite a bit. I'm afraid its difficult to make any judgments from the data you have sent so far. You are going to have to test many more batteries to get more data. I'm going to have to do some work on my processing tools to help with the comparison. I'll try to get to that later on. Here's a quick look at the capacity of the batteries you have tested so far. Thank you very much for the battery serial number in the filename that is very helpful. Please continue to do that. I've broken up the serial number so that we can see the age easily. The 2nd column is the ammount of Watthours that was extracted from the battery sorted into ascending order of Watthours. 00401 071229 110002160OLD.csv -4.177 00401 071229 110002221OLD.csv -11.663 00602 080608 11600.csv -13.915 00802 100751 10002447NEW.csv-13.992 00602 080616 110002384.csv -14.405 00802 100804 110003201NEW.csv -14.803 00802 090331 110002400.csv -15.066 00802 081130 110001133.csv -15.768 10102 080109 31524.csv -15.863 00702 080710 11901.csv -16.009 00802 090829 110001062.csv -15.914 00802 081231 11683.csv -16.576 00702 080714 11474.csv -16.826 00802 090415 110001059.csv -16.995 00802 090429 110002159.csv -17.705 00802 090206 110001307.csv -18.489 The first thing to notice is that it roughly correlates with age which makes sense. The both the 004's are suffering from charge balance. Something you can see from the charging voltage logs. If you want a quick first pass of segregating the batteries then you can use the first 3 digits as guide. Any battery with the first 3 digits that are less than 008 (ie, 007,006,005,004...) is subject to charge balance. I recommend you group your batteries int < 008 and >= 008. Depending on how many you have you may or may not want to even try to analyze the < 008 group. The next thing to notice is that your batteries that you marked as NEW are showing a capacity that is much less than expected. Those should have had a capacity of 18Wh or more. Please re-run the test on those batteries and see if the data is consistent. I've estimated that the capacity loss should be .025% per/cycle. If we assume the rough age of the batteries is 2 to 3 years and that they average 1 cycle per day then I'm expecting the available capacity to be in the 73% to 82% range or 15-16 Wh. Looking at your numbers I say its right on par. So perhaps you can also use the battery age as a guide. What is the minimum capacity you want to allow to be re-used? The attached graph shows your charging voltage in detail. As you can see the the screen turning off and on has an effect on the voltage. This graph also illustrates why this is going to be a difficult thing to accomplish in only a 10 minute test. Another question. Is there information in the battery controller regarding total number of charge/discharge cycles? There is an attempt to do that and the logs extract that information from the EEPROM. However, I don't have any idea how accurate it is. Its legacy code that I've never had a reason to examine closely. I'll examine the code that does that in detail and then add decoding of the values to my processing script next so I can take a look at the numbers. -- Richard A. Smith One Laptop per Child chg_voltage.pdf Description: Adobe PDF document ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO power management
Sounds like someone we really really need to help out with the power problems we have been havingf throughout SA These problems already originated in España so I wouldn't be surprised if there is a link... who knows, maybe we can fix it in a couple of days optimism ALWAYS amigo! kindr regards, David 'nubae' Van Assche On Thu, Mar 31, 2011 at 9:43 PM, Ismael Schinca wrote: > Richard, Ceibal about to start working heavily in reworking how to classify > used batteries. Due to the number of batteries involved, we were asked to > devise a "good enough" procedure to estimate the battery condition in less > than 10 minutes. The plan would be to get several parameters from the > batteries and try to estimate it's condition based on them. Have you been > able to analyze the results from the logs I sent you? > Another question. Is there information in the battery controller regarding > total number of charge/discharge cycles? > Thanks! > Ismael > > 2011/3/30 Ismael Schinca >> >> Ok. Better late than never. >> Attached here are the logs from the XO batteries. >> Each file has one .csv log with the battery serial at the end of the file >> name given by the olpc-pwr-log. >> The tests were all run simultaneously even though some timestamps are off. >> There are two logs for each battery. The first one chronologically is the >> one corresponding to the battery discharging and the second one is for the >> charging process. >> There were two XO with a brand NEW battery, with a label NEW at the end of >> the file names and two tests run with really OLD and badly shaped batteries, >> labeled OLD. The rest are from old but "good enough" batteries. >> Caveat: the charging tests were done with the xset -dpms not set due to >> some miscalculation, so the screen went off some times. Sorry about that. >> The discharging process went as planned. >> I haven't had time yet to analyze the logs, so I don't have comments >> regarding the results. >> Cheers! >> 2011/3/24 Paul Fox >>> >>> ismael wrote: >>> > OK. Great. Is the attached version newer than the one in Sugar 0.88?? >>> >>> almost certainly. >>> >>> paul >>> >>> >>> > Because the latest dextrose image is mainly based on Sugar 0.88 >>> > >>> > 2011/3/24 Richard A. Smith >>> > >>> > > On 03/24/2011 10:41 AM, Ismael Schinca wrote: >>> > > >>> > > I'm planning to use different XO's, all of them 1.0 hardware. I >>> > >> definately won't be able to finish today because they all have >>> different >>> > >> OS images and I think it would be best if I update them all (even >>> for >>> > >> future tests). Maybe tomorrow, maybe monday. >>> > >> >>> > > >>> > > Yes certainly please use the same image on all of them. If you have >>> to >>> > > install software then please use the latest version of olpc-pwr-log. >>> I have >>> > > it attached to this mail. >>> > > >>> > > >>> > > I think it will be very hard to perform the same test under the >>> same >>> > >> conditions as you suggest because: >>> > >> - It will be very time consuming (though it doesn't need a lot of >>> > >> attention during the test) >>> > >> >>> > > >>> > > My goal is to automate the test and use a very short test window. >>> ie 20 >>> > > minutes or so. >>> > > >>> > > >>> > > - The air conditioning in our building is quite frankly chaotic so >>> > >> temperature is really variable (which is actually a lot worse for >>> us >>> > >> humans than batteries ;) ) >>> > >> >>> > > >>> > > Yes. Sorry my use of the word exactly was probably too strong. I >>> don't >>> > > mean that it has to be 25 degC ambient and only that temperature. >>> The temp >>> > > fluctuations in a air conditioned office should be within reason. I >>> just >>> > > don't want the profiles generated in an office and then the test run >>> in a >>> > > outside warehouse at 33C. Or the curves generated on a XO-1 with >>> build 8.2 >>> > > but the test run on a 1.5 with build 10.1.3. That sort of thing. >>> > > >>> > > The closer I might get, which I think could be pretty close is: >>> > >> - Install the SAME fresh OS image and firmware version on all the >>> test XOs >>> > >> - Disable power management in every XO. >>> > >> >>> > > >>> > > and dpms. xset -dpms from the sugar terminal other wise the screen >>> will >>> > > turn off in 20 minutes and change the power draw. >>> > > >>> > > >>> > > - The laptops batteries are mostly charged, so it will be a charge >>> after >>> > >> discharge, so I think temperature there is less of a concern >>> > >> - Run the tests at the same time in every XO >>> > >> >>> > > >>> > > Yes. I believe that will work fine. >>> > > >>> > > Note: I'm getting on a plane in a few minutes so this will be my >>> last >>> > > e-mail until much later on today. Possible tonight or tomorrow. >>> > > >>> > > >>> > > -- >>> > > Richard A. Smith >>> > > One Laptop per Child >>> > > >>> > >>> > >>> > >>> > -- >>> > Ismael Schinca >>> > Centr
Re: XO power management
Richard, Ceibal about to start working heavily in reworking how to classify used batteries. Due to the number of batteries involved, we were asked to devise a "good enough" procedure to estimate the battery condition in less than 10 minutes. The plan would be to get several parameters from the batteries and try to estimate it's condition based on them. Have you been able to analyze the results from the logs I sent you? Another question. Is there information in the battery controller regarding total number of charge/discharge cycles? Thanks! Ismael 2011/3/30 Ismael Schinca > Ok. Better late than never. > Attached here are the logs from the XO batteries. > > Each file has one .csv log with the battery serial at the end of the file > name given by the olpc-pwr-log. > The tests were all run simultaneously even though some timestamps are off. > > There are two logs for each battery. The first one chronologically is the > one corresponding to the battery discharging and the second one is for the > charging process. > > There were two XO with a brand NEW battery, with a label NEW at the end of > the file names and two tests run with really OLD and badly shaped batteries, > labeled OLD. The rest are from old but "good enough" batteries. > > Caveat: the charging tests were done with the xset -dpms not set due to > some miscalculation, so the screen went off some times. Sorry about that. > The discharging process went as planned. > > I haven't had time yet to analyze the logs, so I don't have comments > regarding the results. > > Cheers! > > 2011/3/24 Paul Fox > >> ismael wrote: >> > OK. Great. Is the attached version newer than the one in Sugar 0.88?? >> >> almost certainly. >> >> paul >> >> >> > Because the latest dextrose image is mainly based on Sugar 0.88 >> > >> > 2011/3/24 Richard A. Smith >> > >> > > On 03/24/2011 10:41 AM, Ismael Schinca wrote: >> > > >> > > I'm planning to use different XO's, all of them 1.0 hardware. I >> > >> definately won't be able to finish today because they all have >> different >> > >> OS images and I think it would be best if I update them all (even >> for >> > >> future tests). Maybe tomorrow, maybe monday. >> > >> >> > > >> > > Yes certainly please use the same image on all of them. If you have >> to >> > > install software then please use the latest version of olpc-pwr-log. >> I have >> > > it attached to this mail. >> > > >> > > >> > > I think it will be very hard to perform the same test under the same >> > >> conditions as you suggest because: >> > >> - It will be very time consuming (though it doesn't need a lot of >> > >> attention during the test) >> > >> >> > > >> > > My goal is to automate the test and use a very short test window. ie >> 20 >> > > minutes or so. >> > > >> > > >> > > - The air conditioning in our building is quite frankly chaotic so >> > >> temperature is really variable (which is actually a lot worse for us >> > >> humans than batteries ;) ) >> > >> >> > > >> > > Yes. Sorry my use of the word exactly was probably too strong. I >> don't >> > > mean that it has to be 25 degC ambient and only that temperature. >> The temp >> > > fluctuations in a air conditioned office should be within reason. I >> just >> > > don't want the profiles generated in an office and then the test run >> in a >> > > outside warehouse at 33C. Or the curves generated on a XO-1 with >> build 8.2 >> > > but the test run on a 1.5 with build 10.1.3. That sort of thing. >> > > >> > > The closer I might get, which I think could be pretty close is: >> > >> - Install the SAME fresh OS image and firmware version on all the >> test XOs >> > >> - Disable power management in every XO. >> > >> >> > > >> > > and dpms. xset -dpms from the sugar terminal other wise the screen >> will >> > > turn off in 20 minutes and change the power draw. >> > > >> > > >> > > - The laptops batteries are mostly charged, so it will be a charge >> after >> > >> discharge, so I think temperature there is less of a concern >> > >> - Run the tests at the same time in every XO >> > >> >> > > >> > > Yes. I believe that will work fine. >> > > >> > > Note: I'm getting on a plane in a few minutes so this will be my last >> > > e-mail until much later on today. Possible tonight or tomorrow. >> > > >> > > >> > > -- >> > > Richard A. Smith >> > > One Laptop per Child >> > > >> > >> > >> > >> > -- >> > Ismael Schinca >> > Centro Ceibal - Depto. Técnico - I+D >> > Avda. Italia 6201 - Edificio Los Ceibos >> > Montevideo - Uruguay. >> > Tel.: 2601 57 73 Int. 2232 >> > part 2 text/plain 129 >> > ___ >> > Devel mailing list >> > Devel@lists.laptop.org >> > http://lists.laptop.org/listinfo/devel >> >> =- >> paul fox, p...@laptop.org >> > > > > -- > Ismael Schinca > Centro Ceibal - Depto. Técnico - I+D > Avda. Italia 6201 - Edificio Los Ceibos > Montev
Re: XO power management
ismael wrote: > OK. Great. Is the attached version newer than the one in Sugar 0.88?? almost certainly. paul > Because the latest dextrose image is mainly based on Sugar 0.88 > > 2011/3/24 Richard A. Smith > > > On 03/24/2011 10:41 AM, Ismael Schinca wrote: > > > > I'm planning to use different XO's, all of them 1.0 hardware. I > >> definately won't be able to finish today because they all have different > >> OS images and I think it would be best if I update them all (even for > >> future tests). Maybe tomorrow, maybe monday. > >> > > > > Yes certainly please use the same image on all of them. If you have to > > install software then please use the latest version of olpc-pwr-log. I > > have > > it attached to this mail. > > > > > > I think it will be very hard to perform the same test under the same > >> conditions as you suggest because: > >> - It will be very time consuming (though it doesn't need a lot of > >> attention during the test) > >> > > > > My goal is to automate the test and use a very short test window. ie 20 > > minutes or so. > > > > > > - The air conditioning in our building is quite frankly chaotic so > >> temperature is really variable (which is actually a lot worse for us > >> humans than batteries ;) ) > >> > > > > Yes. Sorry my use of the word exactly was probably too strong. I don't > > mean that it has to be 25 degC ambient and only that temperature. The temp > > fluctuations in a air conditioned office should be within reason. I just > > don't want the profiles generated in an office and then the test run in a > > outside warehouse at 33C. Or the curves generated on a XO-1 with build 8.2 > > but the test run on a 1.5 with build 10.1.3. That sort of thing. > > > > The closer I might get, which I think could be pretty close is: > >> - Install the SAME fresh OS image and firmware version on all the test XOs > >> - Disable power management in every XO. > >> > > > > and dpms. xset -dpms from the sugar terminal other wise the screen will > > turn off in 20 minutes and change the power draw. > > > > > > - The laptops batteries are mostly charged, so it will be a charge after > >> discharge, so I think temperature there is less of a concern > >> - Run the tests at the same time in every XO > >> > > > > Yes. I believe that will work fine. > > > > Note: I'm getting on a plane in a few minutes so this will be my last > > e-mail until much later on today. Possible tonight or tomorrow. > > > > > > -- > > Richard A. Smith > > One Laptop per Child > > > > > > -- > Ismael Schinca > Centro Ceibal - Depto. Técnico - I+D > Avda. Italia 6201 - Edificio Los Ceibos > Montevideo - Uruguay. > Tel.: 2601 57 73 Int. 2232 > part 2 text/plain 129 > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO power management
OK. Great. Is the attached version newer than the one in Sugar 0.88?? Because the latest dextrose image is mainly based on Sugar 0.88 2011/3/24 Richard A. Smith > On 03/24/2011 10:41 AM, Ismael Schinca wrote: > > I'm planning to use different XO's, all of them 1.0 hardware. I >> definately won't be able to finish today because they all have different >> OS images and I think it would be best if I update them all (even for >> future tests). Maybe tomorrow, maybe monday. >> > > Yes certainly please use the same image on all of them. If you have to > install software then please use the latest version of olpc-pwr-log. I have > it attached to this mail. > > > I think it will be very hard to perform the same test under the same >> conditions as you suggest because: >> - It will be very time consuming (though it doesn't need a lot of >> attention during the test) >> > > My goal is to automate the test and use a very short test window. ie 20 > minutes or so. > > > - The air conditioning in our building is quite frankly chaotic so >> temperature is really variable (which is actually a lot worse for us >> humans than batteries ;) ) >> > > Yes. Sorry my use of the word exactly was probably too strong. I don't > mean that it has to be 25 degC ambient and only that temperature. The temp > fluctuations in a air conditioned office should be within reason. I just > don't want the profiles generated in an office and then the test run in a > outside warehouse at 33C. Or the curves generated on a XO-1 with build 8.2 > but the test run on a 1.5 with build 10.1.3. That sort of thing. > > The closer I might get, which I think could be pretty close is: >> - Install the SAME fresh OS image and firmware version on all the test XOs >> - Disable power management in every XO. >> > > and dpms. xset -dpms from the sugar terminal other wise the screen will > turn off in 20 minutes and change the power draw. > > > - The laptops batteries are mostly charged, so it will be a charge after >> discharge, so I think temperature there is less of a concern >> - Run the tests at the same time in every XO >> > > Yes. I believe that will work fine. > > Note: I'm getting on a plane in a few minutes so this will be my last > e-mail until much later on today. Possible tonight or tomorrow. > > > -- > Richard A. Smith > One Laptop per Child > -- Ismael Schinca Centro Ceibal - Depto. Técnico - I+D Avda. Italia 6201 - Edificio Los Ceibos Montevideo - Uruguay. Tel.: 2601 57 73 Int. 2232 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO power management
On 03/24/2011 10:41 AM, Ismael Schinca wrote: I'm planning to use different XO's, all of them 1.0 hardware. I definately won't be able to finish today because they all have different OS images and I think it would be best if I update them all (even for future tests). Maybe tomorrow, maybe monday. Yes certainly please use the same image on all of them. If you have to install software then please use the latest version of olpc-pwr-log. I have it attached to this mail. I think it will be very hard to perform the same test under the same conditions as you suggest because: - It will be very time consuming (though it doesn't need a lot of attention during the test) My goal is to automate the test and use a very short test window. ie 20 minutes or so. - The air conditioning in our building is quite frankly chaotic so temperature is really variable (which is actually a lot worse for us humans than batteries ;) ) Yes. Sorry my use of the word exactly was probably too strong. I don't mean that it has to be 25 degC ambient and only that temperature. The temp fluctuations in a air conditioned office should be within reason. I just don't want the profiles generated in an office and then the test run in a outside warehouse at 33C. Or the curves generated on a XO-1 with build 8.2 but the test run on a 1.5 with build 10.1.3. That sort of thing. The closer I might get, which I think could be pretty close is: - Install the SAME fresh OS image and firmware version on all the test XOs - Disable power management in every XO. and dpms. xset -dpms from the sugar terminal other wise the screen will turn off in 20 minutes and change the power draw. - The laptops batteries are mostly charged, so it will be a charge after discharge, so I think temperature there is less of a concern - Run the tests at the same time in every XO Yes. I believe that will work fine. Note: I'm getting on a plane in a few minutes so this will be my last e-mail until much later on today. Possible tonight or tomorrow. -- Richard A. Smith One Laptop per Child #!/bin/sh # Copyright One Laptop Per Child # Power loging script # Released under GPLv3 VERSION="2.0.1" FDATE=`date "+%y%m%d-%H%M%S"` HOST=`hostname -s` B_INFO=/sys/class/power_supply/olpc-battery # This is the delay in the wallclock_delay. Its the minimum sample time for the # system date. WALL_PERIOD=5 # This is the (approx) delay inbetween readings. # This delay should be some where in the middle of integer mutiples of WALL_PERIOD # delays that bound the desired delay. # That way if our timer and system date are out of phase you don't end up having to wait a whole # new WALL_PERIOD for the RTC check to expire. # DELAY=12 # As of ver 1.14 I've switched back to using sleep rather than my wallclock_delay. # I the previous issues I had with using sleep were never resolved. # I'm going to try to resolve them this time if I see them since they are considered # a bug. # A delay of 10 seconds seems to be too low. DELAY=20 if [ -e /sys/class/dmi/id/product_version ] then XO_VERSION=$(< /sys/class/dmi/id/product_version ) else XO_VERSION="1" fi KERNVER=`uname -r | cut -c 1-6 | sed 's/\.//g'` if [[ $KERNVER -gt 2625 ]]; then KERNAPI=2 else KERNAPI=1 fi echo "Checking/waiting for a battery" until [ $(< $B_INFO/present ) = 1 ] do sleep 1 done # If we just inserted a battery the EC needs time to # read all the info. echo "Found one." echo "Pausing to let the EC think" sleep 3 # Now that we wait for a battery we can use the battery serial number in the filename DS_SERNUM=$(< $B_INFO/serial_number ) LOGFILE="pwr-$FDATE-$DS_SERNUM.csv" ACR_PROP="charge_counter" if [ ! -e $B_INFO/$ACR_PROP ] then ACR_PROP="accum_current" fi if [ -e /boot/olpc_build ] then BUILD=$(< /boot/olpc_build ) fi if [ -e /bootpart/boot/olpc_build ] then BUILD=$(< /bootpart/boot/olpc_build ) fi if [ -e $B_INFO/eeprom ] then # Skip 64 bytes and read 5 bytes; display without an address and in single byte mode # I don't use od directly since the -j skip does not do a real fseek. echo "Reading eeprom data." MFG_SER=`dd if=$B_INFO/eeprom bs=1 skip=64 count=5 2> /dev/null | od -A n -t x1` CHGCNT=`dd if=$B_INFO/eeprom bs=1 skip=74 count=2 2> /dev/null| od -A n -t x1 ` CHGSOC=`dd if=$B_INFO/eeprom bs=1 skip=76 count=1 2> /dev/null| od -A n -t x1 ` DISCNT=`dd if=$B_INFO/eeprom bs=1 skip=77 count=2 2> /dev/null| od -A n -t x1 ` DISSOC=`dd if=$B_INFO/eeprom bs=1 skip=79 count=1 2> /dev/null| od -A n -t x1 ` else echo "Can't read the eeprom data because your kernel dosen't support eeprom dump" MFG_SER="NA" CHGCNT="NA" CHGSOC="NA" DISCNT="NA" DISSOC="NA" fi echo "Starting log $LOGFILE" echo echo "pwr_log Ver: $VERSION" > $LOGFILE echo -n "HOST: ">> $LOGFILE echo $HOST >> $LOGFILE echo -n
Re: XO power management
I'm planning to use different XO's, all of them 1.0 hardware. I definately won't be able to finish today because they all have different OS images and I think it would be best if I update them all (even for future tests). Maybe tomorrow, maybe monday. I think it will be very hard to perform the same test under the same conditions as you suggest because: - It will be very time consuming (though it doesn't need a lot of attention during the test) - The air conditioning in our building is quite frankly chaotic so temperature is really variable (which is actually a lot worse for us humans than batteries ;) ) The closer I might get, which I think could be pretty close is: - Install the SAME fresh OS image and firmware version on all the test XOs - Disable power management in every XO - Keep the XOs close together - The laptops batteries are mostly charged, so it will be a charge after discharge, so I think temperature there is less of a concern - Run the tests at the same time in every XO Ismael 2011/3/24 Richard A. Smith > On 03/24/2011 10:31 AM, Richard A. Smith wrote: > > If you run _exactly_ the same test under the same conditions. Same >> temperature, same test duration, same XO, then it might be possible to >> compare the current voltage, >> > > Battery temperature will also be a concern. If you test the discharge > immediately after a charge when the battery is hot you are going to get a > different result than if the battery was sitting on the table all night and > is at room temperature when you start the discharge. > > > -- > Richard A. Smith > One Laptop per Child > -- Ismael Schinca Centro Ceibal - Depto. Técnico - I+D Avda. Italia 6201 - Edificio Los Ceibos Montevideo - Uruguay. Tel.: 2601 57 73 Int. 2232 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO power management
On 03/24/2011 10:31 AM, Richard A. Smith wrote: > If you run _exactly_ the same test under the same conditions. Same > temperature, same test duration, same XO, then it might be possible to > compare the current voltage, Battery temperature will also be a concern. If you test the discharge immediately after a charge when the battery is hot you are going to get a different result than if the battery was sitting on the table all night and is at room temperature when you start the discharge. -- Richard A. Smith One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO power management
On 03/24/2011 09:45 AM, Ismael Schinca wrote: > We would really like to have a relatively accurate result *as fast as > possible *of the condition of a battery. That's what I'm trying to get to. > I could run the olpc-pwr-log on 15 batteries aprox. Used batteries but > in a "probably good" condition. If you run _exactly_ the same test under the same conditions. Same temperature, same test duration, same XO, then it might be possible to compare the current voltage, to the SOC and make a fast assessment. The battery voltage is dependent on a lot of different variables and those will need to be held constant. The profiles you are about to generate will tell us if this is possible. > I'm also trying to get some really bad but functioning batteries to test > them. Don't have them yet. Sounds good. > I'll try to run the script on those 15 batteries today and share the > results here. I could attach the csv files for example. My idea is to > deplete the batteries and run the script from that point on. Let me know > if you would prefer another procedure. Today? Each charge takes approx 2 hours. Are you going to do it on 15 different XO's? That procedure is fine for the charge files. -- Richard A. Smith One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO power management
On 03/24/2011 09:53 AM, Ismael Schinca wrote: > > If you would prefer a different test please let me know. oh and if this is a build that running powerd then you need to stop it or disable power management and turn off dpms screen blanking. On 1.5 dpms is not active but it is on XO 1.0. The machine needs to be running idle so don't use it for anything either. If its an older build with ohmd then you need to stop that as well. We don't want power management to kick in for this test. Also what version of olpc-pwr-log are you runing? There is a version output field in the log file and you can also see by looking at the file. It's a bash script. -- Richard A. Smith One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO power management
On 03/24/2011 09:53 AM, Ismael Schinca wrote: > OK. Just read this email. > So the plan would be: > - Start from a fully charged battery, run the olpc-pwr-log script until > poweroff. > - Remove battery, plug XO, run script and insert battery until fully > charged. Yes. Or the other way around if you have an empty battery. Start discharged, charge, then discharge. But only do it that way if the battery is very low. > If you would prefer a different test please let me know. Nope thats it. I'd like the serial number for each battery as well. Do you have a hand held USB barcode scanner? If so then you can use it to quickly read the battery serial number. I find them very useful when dealing with a large number of batteries. -- Richard A. Smith One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO power management
OK. Just read this email. So the plan would be: - Start from a fully charged battery, run the olpc-pwr-log script until poweroff. - Remove battery, plug XO, run script and insert battery until fully charged. If you would prefer a different test please let me know. Ismael 2011/3/24 Richard A. Smith > On 03/24/2011 09:25 AM, Ismael Schinca wrote: > > I have several batteries, some of them pretty old (that's the idea). A >> couple of S/Ns: >> >> > 00602 080616 110002384 >> 00602 080608 11600 >> > > The mfg is embedded in the serial number pos 6-11 format YYMMDD > > So these 2 batteries where produced 2008/06/16 and 2008/06/08. Close to 33 > months old. Indeed I would really like charge/discharge profiles from these > batteries. > > > know if the results were valid since I was having different starting >> points. Some batteries started from 5%, some from 10%, etc. Now I know >> that's probably correct anyways. >> > > Please do a charge/discharge cycle while running olpc-pwr-log. > > -- > Richard A. Smith > One Laptop per Child > -- Ismael Schinca Centro Ceibal - Depto. Técnico - I+D Avda. Italia 6201 - Edificio Los Ceibos Montevideo - Uruguay. Tel.: 2601 57 73 Int. 2232 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO power management
We would really like to have a relatively accurate result *as fast as possible *of the condition of a battery. That's what I'm trying to get to. I could run the olpc-pwr-log on 15 batteries aprox. Used batteries but in a "probably good" condition. I'm also trying to get some really bad but functioning batteries to test them. Don't have them yet. I'll try to run the script on those 15 batteries today and share the results here. I could attach the csv files for example. My idea is to deplete the batteries and run the script from that point on. Let me know if you would prefer another procedure. Ismael 2011/3/24 Richard A. Smith > On 03/24/2011 09:15 AM, Richard A. Smith wrote: > > > Whats the serial number of your battery? You may also want to run a > > olpc-pwr-log run with that battery so you can determine what the actual > > capacity of the battery is. > > Even better you are in a position to help me figure out how best to deal > with this.Adding a full blown calibration procedure is perhaps > possible but its tricky to do automatically. A possible 1st step could > be the addition of a manual value that let you adjust the maximum mAh. > Then you could run a manual calibration procedure and update the value. > > You say you have many of these batteries? Would you be able to run > olpc-pwr-log on each one of them? > > -- > Richard A. Smith > One Laptop per Child > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > -- Ismael Schinca Centro Ceibal - Depto. Técnico - I+D Avda. Italia 6201 - Edificio Los Ceibos Montevideo - Uruguay. Tel.: 2601 57 73 Int. 2232 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO power management
On 03/24/2011 09:25 AM, Ismael Schinca wrote: > I have several batteries, some of them pretty old (that's the idea). A > couple of S/Ns: > > 00602 080616 110002384 > 00602 080608 11600 The mfg is embedded in the serial number pos 6-11 format YYMMDD So these 2 batteries where produced 2008/06/16 and 2008/06/08. Close to 33 months old. Indeed I would really like charge/discharge profiles from these batteries. > know if the results were valid since I was having different starting > points. Some batteries started from 5%, some from 10%, etc. Now I know > that's probably correct anyways. Please do a charge/discharge cycle while running olpc-pwr-log. -- Richard A. Smith One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO power management
On 03/24/2011 09:15 AM, Richard A. Smith wrote: > Whats the serial number of your battery? You may also want to run a > olpc-pwr-log run with that battery so you can determine what the actual > capacity of the battery is. Even better you are in a position to help me figure out how best to deal with this.Adding a full blown calibration procedure is perhaps possible but its tricky to do automatically. A possible 1st step could be the addition of a manual value that let you adjust the maximum mAh. Then you could run a manual calibration procedure and update the value. You say you have many of these batteries? Would you be able to run olpc-pwr-log on each one of them? -- Richard A. Smith One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO power management
That's exactly what I wanted to know. How was the SOC evaluated when the battery lost capacity. If there was some estimation on the battery loss or just a full capacity assumption and then early poweroff. I have several batteries, some of them pretty old (that's the idea). A couple of S/Ns: 00602080616110002384 0060208060811600 I've been running olpc-pwr-log with depleted batteries to evaluate the battery condition, but since I wasn't sure how the SOC worked, I didn't know if the results were valid since I was having different starting points. Some batteries started from 5%, some from 10%, etc. Now I know that's probably correct anyways. Ismael 2011/3/24 Richard A. Smith > On 03/24/2011 08:55 AM, Ismael Schinca wrote: > > Thanks, for starters this is really useful, because it's not at all > > similar to what I've been observed. The computer powers off with battery > > levels between 10-15% and the led starts blinking around 5-10%. I'm > > using several batteries on the same XO 1.0 computer. Granted, the > > batteries are not fresh ones, but that's exactly what I am trying to > > figure out. How the battery behaviour changes when battery capacity > > starts to decrease over time. > > Any additional information will be most welcome. > > What you are observing is exactly what will happen as the battery > reduces capacity. We don't have a calibration procedure so the SOC > assumes 3100mAh. The SOC is a mAh/1% counter. After so many mAh it > subtracts 1%. The critical level is a voltage reading. Its not coupled > to the SOC. So with a battery that has less capacity you will reach the > critical level sooner. > > Whats the serial number of your battery? You may also want to run a > olpc-pwr-log run with that battery so you can determine what the actual > capacity of the battery is. > > -- > Richard A. Smith > One Laptop per Child > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > -- Ismael Schinca Centro Ceibal - Depto. Técnico - I+D Avda. Italia 6201 - Edificio Los Ceibos Montevideo - Uruguay. Tel.: 2601 57 73 Int. 2232 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO power management
On 03/24/2011 08:55 AM, Ismael Schinca wrote: > Thanks, for starters this is really useful, because it's not at all > similar to what I've been observed. The computer powers off with battery > levels between 10-15% and the led starts blinking around 5-10%. I'm > using several batteries on the same XO 1.0 computer. Granted, the > batteries are not fresh ones, but that's exactly what I am trying to > figure out. How the battery behaviour changes when battery capacity > starts to decrease over time. > Any additional information will be most welcome. What you are observing is exactly what will happen as the battery reduces capacity. We don't have a calibration procedure so the SOC assumes 3100mAh. The SOC is a mAh/1% counter. After so many mAh it subtracts 1%. The critical level is a voltage reading. Its not coupled to the SOC. So with a battery that has less capacity you will reach the critical level sooner. Whats the serial number of your battery? You may also want to run a olpc-pwr-log run with that battery so you can determine what the actual capacity of the battery is. -- Richard A. Smith One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO power management
Thanks, for starters this is really useful, because it's not at all similar to what I've been observed. The computer powers off with battery levels between 10-15% and the led starts blinking around 5-10%. I'm using several batteries on the same XO 1.0 computer. Granted, the batteries are not fresh ones, but that's exactly what I am trying to figure out. How the battery behaviour changes when battery capacity starts to decrease over time. Any additional information will be most welcome. Ismael 2011/3/24 Paul Fox > ismael wrote: > > Hello everyone, I'm trying to perform some tests on XO battery life > > performance and I have some questions which I couldn't find a clear > answer > > in the wiki or this list: > > i'm sure richard will chime in, but here's a start. > > > > > - When the battery level is "critically low" the OS (Sugar 0.88 based > > Dextrose) performs a safe shutdown. I would like to know what is the > exact > > condition that triggers this. > > the answer to this depends on what version of powerd is running. in > the latest powerd versions, we force a shutdown if the capacity is 1% > (or less :-), or if the battery voltage is 5.7V or less. we don't > bother with these checks unless the capacity is below 40% (which may > be a pointless optimization). these checks were slightly different > in powerd versions 27 and earlier, but i suspect dextrose is running > something newer than that. > > > - Likewise, at some level controlled by the XO EC, the battery led light > > begins to flash orange/red. I would also like to know which is the exact > > condition that triggers this. Is it the SOC, battery voltage, ACR... ? > And > > i believe this value is 5.7V. (i.e., battery voltage) > > > what level triggers this condition? I would also like to know the level > in > > which the XO performs a "hard" poweroff. > > 5.5V on XO-1.5, 5.4V on XO-1. > > also remember that the voltage at the battery will change, substantially, > between the suspended and running states -- so what the EC sees during > suspend may be several tenths of a volt higher during suspend than when > the system is running. > > paul > > > > > Any help is appreciated. > > > > Thanks! > > > > Regards, > > Ismael > > > > -- > > Ismael Schinca > > Centro Ceibal - Depto. Técnico - I+D > > Avda. Italia 6201 - Edificio Los Ceibos > > Montevideo - Uruguay. > > Tel.: 2601 57 73 Int. 2232 > > part 2 text/plain 129 > > ___ > > Devel mailing list > > Devel@lists.laptop.org > > http://lists.laptop.org/listinfo/devel > > =- > paul fox, p...@laptop.org > -- Ismael Schinca Centro Ceibal - Depto. Técnico - I+D Avda. Italia 6201 - Edificio Los Ceibos Montevideo - Uruguay. Tel.: 2601 57 73 Int. 2232 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO power management
ismael wrote: > Hello everyone, I'm trying to perform some tests on XO battery life > performance and I have some questions which I couldn't find a clear answer > in the wiki or this list: i'm sure richard will chime in, but here's a start. > > - When the battery level is "critically low" the OS (Sugar 0.88 based > Dextrose) performs a safe shutdown. I would like to know what is the exact > condition that triggers this. the answer to this depends on what version of powerd is running. in the latest powerd versions, we force a shutdown if the capacity is 1% (or less :-), or if the battery voltage is 5.7V or less. we don't bother with these checks unless the capacity is below 40% (which may be a pointless optimization). these checks were slightly different in powerd versions 27 and earlier, but i suspect dextrose is running something newer than that. > - Likewise, at some level controlled by the XO EC, the battery led light > begins to flash orange/red. I would also like to know which is the exact > condition that triggers this. Is it the SOC, battery voltage, ACR... ? And i believe this value is 5.7V. (i.e., battery voltage) > what level triggers this condition? I would also like to know the level in > which the XO performs a "hard" poweroff. 5.5V on XO-1.5, 5.4V on XO-1. also remember that the voltage at the battery will change, substantially, between the suspended and running states -- so what the EC sees during suspend may be several tenths of a volt higher during suspend than when the system is running. paul > > Any help is appreciated. > > Thanks! > > Regards, > Ismael > > -- > Ismael Schinca > Centro Ceibal - Depto. Técnico - I+D > Avda. Italia 6201 - Edificio Los Ceibos > Montevideo - Uruguay. > Tel.: 2601 57 73 Int. 2232 > part 2 text/plain 129 > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
XO power management
Hello everyone, I'm trying to perform some tests on XO battery life performance and I have some questions which I couldn't find a clear answer in the wiki or this list: - When the battery level is "critically low" the OS (Sugar 0.88 based Dextrose) performs a safe shutdown. I would like to know what is the exact condition that triggers this. - Likewise, at some level controlled by the XO EC, the battery led light begins to flash orange/red. I would also like to know which is the exact condition that triggers this. Is it the SOC, battery voltage, ACR... ? And what level triggers this condition? I would also like to know the level in which the XO performs a "hard" poweroff. Any help is appreciated. Thanks! Regards, Ismael -- Ismael Schinca Centro Ceibal - Depto. Técnico - I+D Avda. Italia 6201 - Edificio Los Ceibos Montevideo - Uruguay. Tel.: 2601 57 73 Int. 2232 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
review of XO power management patches for upstream
Hi, I've finished working on the power management code, ready for review before I sent it upstream if anyone is interested. The patches are here: http://dev.laptop.org/~dsd/20110114/ The architecture is a bit different from before: olpc-xo1-pm (previously olpc-xo1) is a driver for the core power management functions - suspend/resume and poweroff. olpc-xo1-sci is a driver for OLPC's usage of the CS5536 SCI interrupt and its linkage with the EC GPE/SCI, providing features such as ebook switch, lid switch, power supply events, etc. olpc-xo1-pm is a child device of the new cs5535-mfd driver, and olpc-xo1-sci is a child of olpc-xo1-pm The interfaces have changed from the earlier olpc-pm code. Instead of having our own custom /proc node to control wakeups, I tried to integrate into the Linux driver model more. For example, to enable keyboard/mouse wakeups, you now have to request wakeups from the actual i8042 device. There is no longer a device node to read the state of the lid/ebook switches; instead we will use ioctls to query the state through evdev. This will require userspace tweaks in powerd and so on, work that I'll take on afterwards (I imagine the upstreaming process will cause further changes to be made). Patch 1 defines the interface for communication to the cs5536. We are uncertain about how this will end up, Andres in the process of proposing a new generic system for communication between MFD drivers and child devices (yes, 19 patches): [RFC] [PATCH 0/19] mfd sharing support http://marc.info/?a=11678082506&r=1&w=2 However, whatever the result is, only small changes are needed on the other patches to change interface. While that is being decided, I can start submitting some of the independent patches: 2, 5, 6, 12, 14, 16 I'm not going to submit patch 11 (XO-1 wakeup source info), and also I don't have code for wakeup source detection on XO-1.5. After getting the other patches off my back, I plan to revisit this area with the possibility of not needing to know what the wakeup source is, on the basis that the relevant wakeup event (e.g. mouse move) would arrive at userspace anyway. I think this is the direction that Linux's new wakeup events architecture is taking us: "My understanding (which probably isn't exactly the same as Rafael's) is that a "wakeup event" is any event which should either prevent the system from going to sleep or should wake up the system if it is already asleep. After all, these are the same events (user typing, network packet arriving, alarm firing) -- the only difference is what state the system is in when they occur." context: http://www.spinics.net/lists/linux-pm/msg22764.html Comments welcome! Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
