Power Spells
I keep investigating the power drain experienced on my Blackberry Priv phone. And actually I'm getting some consistent results. The screenshots are taken at the end of days that were very similar from the phone usage perspective. And the one on the right has 50% more juice left.
The first option that helps running longer is disabling 4G/ LTE in the Cellular networks menu. Clearly when switch to HSPA+/UMTS/GSM helps while still giving very decent mobile data performance.
The second option, with results illustrated by the attached screenshots, is one I have almost entirely forgotten about. It is the Physical Web in Google Chrome. It is off by default so most people are not affected. I turned it on months ago and then simply forgot about its existence. It does very little but means a lot to the beacon industry, as it is meant to resolve signals from Bluetooth beacons into useful content links. It runs in a background continuously scanning for Bluetooth advertising packets. I am surprised it affects the power consumption that much: a Bluetooth scanner draws about 20mA so the overall energy consumed daily is 200mAh, or 5% of battery capacity. But there may be a side effect of the entire system waking up frequently to kick the scanner or process the scan results.
It seems like the beacon scanner feature should be run by the Bluetooth chip itself, without engaging the main application processor. Which - to my knowledge - is not possible on any mobile phone. This situation probably explains why the Physical Web feature is buried so deeply in the Chrome settings and turned off by default.
There is a strong trend now to offload sensor processing to external chips, even running them on specialized low power FPGAs like the Quicklogic Arcticlink 3 S2 sensor hub. Processing Bluetooth scan results should be one of such delegated functions. Today the power consumption issue is clearly gating the growth of the beacon industry.
The first option that helps running longer is disabling 4G/ LTE in the Cellular networks menu. Clearly when switch to HSPA+/UMTS/GSM helps while still giving very decent mobile data performance.
The second option, with results illustrated by the attached screenshots, is one I have almost entirely forgotten about. It is the Physical Web in Google Chrome. It is off by default so most people are not affected. I turned it on months ago and then simply forgot about its existence. It does very little but means a lot to the beacon industry, as it is meant to resolve signals from Bluetooth beacons into useful content links. It runs in a background continuously scanning for Bluetooth advertising packets. I am surprised it affects the power consumption that much: a Bluetooth scanner draws about 20mA so the overall energy consumed daily is 200mAh, or 5% of battery capacity. But there may be a side effect of the entire system waking up frequently to kick the scanner or process the scan results.
It seems like the beacon scanner feature should be run by the Bluetooth chip itself, without engaging the main application processor. Which - to my knowledge - is not possible on any mobile phone. This situation probably explains why the Physical Web feature is buried so deeply in the Chrome settings and turned off by default.
There is a strong trend now to offload sensor processing to external chips, even running them on specialized low power FPGAs like the Quicklogic Arcticlink 3 S2 sensor hub. Processing Bluetooth scan results should be one of such delegated functions. Today the power consumption issue is clearly gating the growth of the beacon industry.
Comments
Post a Comment