Mike, I think you need not be concerned with the battery consumption in this respect. The retina display on the iPhone probably consumes in one minute as much energy as the BLE connection would in a week or more. The devices need to be charged almost every day if they are used. If not used, then at most every third day. BLE takes or adds a few minutes to this availability but probably even less. I see that all Apple presentations are concerned with the consumption and many recommendations on this list tell that you should think about it. However, IMHO this is vastly exaggerated if we consider the magnitude of difference in "power hungriness" between other functions of the device and BLE. Of course, if your app starts to burn the CPU for 10 seconds every time it receives a BLE message, then that can severely affect availability. But that is again not because of BLE. To answer your question: background scanning is very conservative but you will probably be better off starting a connection request. You would have to do that anyway. Regards, Andras PS: this advice is based on my personal experience, so the official explanation for the cautiousness can be reasonable for other scenarios. I haven't seen any difference between having my app running in the background and trying to connect to a BLE device or not. Either way my iPhone 4S depleted in about 3 days if I left it lying on my desk. And the difference in availability depended on whether I got a few calls and messages or not. BLE virtually had no effect. On 2013.04.03., at 21:07, Michael Farley <michael.farley@gmail.com> wrote:

Steve,

Thanks for the quick response. I'm not concerned about discovery times, I've got that under control.

My main concern is how much battery will be drained when I'm trying to see if a device is within range. I see two ways:

1) Scan for the device 2) Issue a connect request to the device

Is the radio's receiver going to be on for the same amount in each scenario? Or will one cause the radio to be on more than the other? Or, are there more battery consumption factors than the receiver being on or off (e.g. maybe if you set the radio to on but only searching for a specific BLE device, it uses less power)?

Regards, Mike

On Mon, Apr 1, 2013 at 2:32 PM, Stephen Jablonski <stevejabs@gmail.com> wrote:

...

Hi Mike,

I can't speak in exact battery consumption, but I can tell you that from our tests in the past that neither had a significant impact on our battery life at all. Even better, when our test iPod Touches are in peripheral mode we've had them last for many days in the background without draining the battery (only app running at the time). I would like to assume that in a central role you would see much the same. BTLE is meant to be run at a very low power consumption.

As for the discovery time… it varies. iOS ramps up and down the amount of times it listens depending if your app is in the foreground or background. There is no exact number. If you ramp up the advertising rate on your peripheral device it will connection much faster. In our test cases we saw anything from 5 seconds to 40. It all depends on the you listening at the same time your advertising. That will always change.

Hope that helps. Sorry that there is no "conclusive" numbers.

- Steve Jablonski

On Apr 1, 2013, at 5:23 PM, Michael Farley <michael.farley@gmail.com> wrote:

...

What is the most power efficient way to find out a known BLE device is within range, while the app is in the background? Please assume that the BLE device has not been seen during this background scan (i.e. I'm aware of no-duplicates when you're in the background). iOS device is the central device, and the "BLE device" is the peripheral.

I already have the UUID of said BLE device, so I can issue a connectPeripheral(). Alternatively, I could issue a scanForPeripheralsWithServices() to find the device. Is one better than the other in terms of iOS battery consumption? How about "discovery" time (i.e. would I get a didConnectPeripheral() call faster than I would get a didDiscoverPerpheral() call)?

Thanks in advance, Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/bluetooth-dev/stevejabs%40gmail.com

This email sent to stevejabs@gmail.com

_______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/bluetooth-dev/allprog%40gmail.com

This email sent to allprog@gmail.com

_______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists.... This email sent to site_archiver@lists.apple.com