Using Power Monitor to Tackle Battery Life Problems: Examples
Power monitor (made by Monsoon solutions) is a very useful to improve device battery life. I think every OEM/ODM engineering team should have on handy to watch and troubleshoot battery life issues. Even better, bring the power monitor with your devices into the field, and perform filed tests or comparison tests. For example, how's power consumption of the GPS chip on your device? Just take a drive with your device and connected power monitor with GPS on and capture the logs. Then power monitor will parse the logs and give you a power consumption graph for the test.
The following are some examples of using power monitor to uncover mysterious battery life issues.
1. Standby Current - 30mA !
This graph shows power consumption data of several scenarios on a device: 2G MT call, 2G MO call, Switching to 3G (by changing phone settings), 3G MT call, 3G MO call, and then device gets back to standby with screen off. Device backlight, which burns about 50mA of current, will be turned off after 30 seconds of idle time. When that happens the standby current is around 2-8mA, as can seen after the 2G MT, 2G MO, and 3G MT calls.
The problem is that after the 3G MO call, and device backlight off and suspends, the standby current stays at around 30mA forever. Back-of-the-envelop calculation shows for a whole day 30mA * 24h = 720mAH, about half of the battery capacity on the device.
As this can be reproduced pretty easily, modem log and CE log can be collected and investigated. Eventually this turned out to be the audio path not being properly closed when the 3G MO out ended. After fixing it in RIL driver, the problem was solved.
2. Mysterious thread
This is a classic example of power-unaware programming. At some point the device starts to run a mysterious thread exactly every minute (see the 120mA spikes, even if in suspend mode. Essentially this leads to an average current of about 20-30mA, which is definitely unacceptable. More specifically, when the thread runs, it drains an average of 50mA for 16 seconds, and that will be 13.3mAh for an hour, or 320mAh a day!
How to find the culprit thread? Use Kernel Tracker. Try to look for WaitForSingleObject() calls that has a timeout of 1 minute. If the kernel tracker GUI does not work for you, get the CE log and look for mysterious threads that run every 60 seconds:
0:10:35.890.640 , Switch Thread , hThread=0x07A9FFAE
0:10:35.890.645 , Migrate Thread , hProcess=0x07AB230E
0:10:35.890.741 , Wait for Multiple Objects , Timeout=60000ms , WaitAll=0 , NumObjects=8 , Object 0: 0x07AA8C2A , Object 1: 0x07A9A2C6 , Object 2: 0xC7A9A5D2 , Object 3: 0x07A9A392 , Object 4: 0xC7A9A506 , Object 5: 0x07A9FAAA , Object 6: 0x47A9A986 , Object 7: 0x07AC15E2
0:11:15.961.408 , Switch Thread , hThread=0x07A9FFAE
0:11:15.961.412 , Migrate Thread , hProcess=0x07AB230E
0:11:15.961.508 , Wait for Multiple Objects , Timeout=60000ms , WaitAll=0 , NumObjects=8 , Object 0: 0x07AA8C2A , Object 1: 0x07A9A2C6 , Object 2: 0xC7A9A5D2 , Object 3: 0x07A9A392 , Object 4: 0xC7A9A506 , Object 5: 0x07A9FAAA , Object 6: 0x47A9A986 , Object 7: 0x07AC15E2
This can be further mapped to a thread name as long as you have flat release directory. For the issue, it turned out a battery monitor thread in devices.exe that has a bug which will keep the thread running forever even if the device has been suspended.
Summary:
Power monitor is a great weapon to attach battery life problems for mobile devices. Use it along with other tools such as kernel tracker, CE Log, and KITL to pinpoint what has been wrong in your system. Always has a reference device handy so you know what are normal and what are not. When you perform a scenario test, have CE Log running will be a good idea, but you have to be aware that CE Log flush will drain some battery and create some spikes in your power graph.