April 2013 - Bluetooth-dev - lists.apple.com

Re: Using CoreBluetooth from Command Line Tool
by dave-ble＠greylogic.com 05 Apr '13

05 Apr '13

If you use the retrieve and connect do you get the connect callback delegate? Everything works for me until the connect - I never get the didConnectPeripheral delegate call. I just recompiled with ARC enabled and also created a static reference for a WirelessBandManager *. It still doesn't work for me. I'm linking with IOBluetooth.framework and Foundation.framework - is there any others you are adding? BTW, I come from an embedded background so I'm more used to managing the retain/release cycle myself - ARC is a whole new concept in my old-school vocabulary... -- dave On Apr 4, 2013, at 4:33 PM, Andras Kovi <allprog(a)gmail.com> wrote: > I tried your code. Turned it to ARC and kept a reference to the WirelessBandManager in the main function. It works well for me. I tried it with the queue and the main queue too and with scan and retrieve. > > Don't you have to retain the WirelessBandManager instance in the main function? Just asking. I generally use ARC and shiver from these retain-release calls. > > Andras > > > On 2013.04.05., at 0:22, dave-ble(a)greylogic.com wrote: > >> It is a proprietary device I'm connecting with, so the UUID isn't changing (it is the same UUID I see when I scan from my GUI app or command line app). >> >> The symptoms feel like a dead lock on the queue CoreBluetooth is using to send events. Being I have no visibility it is hard to know for sure. >> >> Below is a stripped version of the code that fails to respond to the connect. Note: the UUID is hardcoded to simplify my testing. Using the same hardcoded UUID in my GUI version works and behaves as expected. >> >> The debug log output is the following (nothing more) >> >> 2013-04-04 15:18:15.836 cbtest[4025:1303] Did update state to: 5 >> 2013-04-04 15:18:15.838 cbtest[4025:1303] Did retrieve peripheral: <CBConcretePeripheral: 0x10010bf40> >> >> -- dave >> >> #import <Foundation/Foundation.h> >> #import <IOBluetooth/IOBluetooth.h> >> >> @interface WirelessBandManager : NSObject <CBCentralManagerDelegate> >> { >> CBCentralManager * mBLEManager; >> CBPeripheral * mPeripheral; >> dispatch_queue_t mBleDispatchQueue; >> } >> @end >> >> @implementation WirelessBandManager >> >> - (id)init >> { >> self = [super init]; >> if (self) >> { >> mBleDispatchQueue = dispatch_queue_create("com.xyz.ble.mgr", DISPATCH_QUEUE_SERIAL); >> mBLEManager = [[CBCentralManager alloc] initWithDelegate:self queue:mBleDispatchQueue]; >> } >> return self; >> } >> >> #pragma mark - >> #pragma mark CBCentralManager Delegate Methods >> - (void)centralManagerDidUpdateState:(CBCentralManager *)central >> { >> NSLog(@"Did update state to: %d",(int)central.state); >> if (central.state == CBCentralManagerStatePoweredOn) >> { >> NSMutableArray * uuids = [[NSMutableArray alloc] initWithCapacity:1]; >> NSString * uuidStr = @"42EF45DA-718D-42C2-AB91-A6588121E52A"; >> CFUUIDRef uuidRef = CFUUIDCreateFromString(NULL, (CFStringRef)uuidStr); >> [uuids addObject:(id)uuidRef]; >> CFRelease(uuidRef); >> >> [mBLEManager retrievePeripherals:uuids]; >> [uuids release]; >> } >> } >> >> - (void)centralManager:(CBCentralManager *)central didRetrievePeripherals:(NSArray *)peripherals >> { >> mPeripheral = [peripherals[0] retain]; >> >> NSLog(@"Did retrieve peripheral: %@",mPeripheral); >> >> NSDictionary *connOptions = [NSDictionary dictionaryWithObject:[NSNumber numberWithBool:YES] forKey:CBConnectPeripheralOptionNotifyOnDisconnectionKey]; >> >> [mBLEManager connectPeripheral:mPeripheral options:connOptions]; >> } >> >> - (void)centralManager:(CBCentralManager *)central didConnectPeripheral:(CBPeripheral *)peripheral >> { >> NSLog(@"Did connect to peripheral: %@",peripheral); >> } >> - (void)centralManager:(CBCentralManager *)central didFailToConnectPeripheral:(CBPeripheral *)peripheral error:(NSError *)error >> { >> NSLog(@"Did FAIL to connect to peripheral: %@ Error:%@",peripheral,error); >> } >> - (void)centralManager:(CBCentralManager *)central didDisconnectPeripheral:(CBPeripheral *)peripheral error:(NSError *)error >> { >> NSLog(@"Did disconnect from peripheral: %@ Error:%@",peripheral,error); >> } >> >> >> @end >> >> #pragma mark - >> #pragma mark MAIN >> // ========================================================================= >> // main() >> // ========================================================================= >> int main(int argc, const char * argv[]) >> { >> @autoreleasepool >> { >> [[WirelessBandManager alloc] init]; >> dispatch_main(); >> } >> return 0; >> } >> >> >> On Apr 4, 2013, at 2:34 PM, Andras Kovi <allprog(a)gmail.com> wrote: >> >>> Hi Dave, >>> >>> I haven't tried to run CB in a command line app, but one little note: make sure you don't use WiFi while connected. WiFi and BLE interfere severely on my Mac Mini. I guess it's similar on the MacBook. >>> >>> Do you want to connect to an i* device or a proprietary one? i* devices change their BLE addresses every few minutes. If you don't use secure connection, then I think they can get out of sync. This is probably the reason why you need to do a scan. Command line or Cocoa should not make any difference IMHO. >>> >>> Andras >>> >>> On 2013.04.04., at 22:40, dave-ble(a)greylogic.com wrote: >>> >>>> Hi, >>>> >>>> I'm trying to write a simple command line app that uses CoreBluetooth on an BLE capable mac book (OSX v10.8.3). >>>> >>>> If I use the retrievePeripherals I get the delegate didRetrievePeripherals to fire. If I then try to connect to the found peripheral, the didConnectPeripheral delegate never fires. >>>> >>>> However, if I scan for peripherals and get the delegate didDiscoverPeripheral to fire. I can then connect and connect succeeds. However, once I'm connected and have my characteristics, the data I receive from my peripheral is not reliably received. >>>> >>>> Using similar code in a GUI application works perfect. >>>> >>>> Has anyone else been successful running the CoreBluetooth stack from within a command line app? >>>> >>>> In my main I essentially create a dispatch_queue and let it run my operations via dispatch_async. Meanwhile, I let main just call dispatch_main(). >>>> >>>> -- dave >>>> _______________________________________________ >>>> Do not post admin requests to the list. They will be ignored. >>>> Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) >>>> Help/Unsubscribe/Update your Subscription: >>>> https://lists.apple.com/mailman/options/bluetooth-dev/allprog%40gmail.com >>>> >>>> This email sent to allprog(a)gmail.com >> _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)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(a)lists.apple.com

1 0

Re: Using CoreBluetooth from Command Line Tool
by Andras Kovi 04 Apr '13

04 Apr '13

I tried your code. Turned it to ARC and kept a reference to the WirelessBandManager in the main function. It works well for me. I tried it with the queue and the main queue too and with scan and retrieve. Don't you have to retain the WirelessBandManager instance in the main function? Just asking. I generally use ARC and shiver from these retain-release calls. Andras On 2013.04.05., at 0:22, dave-ble(a)greylogic.com wrote: > It is a proprietary device I'm connecting with, so the UUID isn't changing (it is the same UUID I see when I scan from my GUI app or command line app). > > The symptoms feel like a dead lock on the queue CoreBluetooth is using to send events. Being I have no visibility it is hard to know for sure. > > Below is a stripped version of the code that fails to respond to the connect. Note: the UUID is hardcoded to simplify my testing. Using the same hardcoded UUID in my GUI version works and behaves as expected. > > The debug log output is the following (nothing more) > > 2013-04-04 15:18:15.836 cbtest[4025:1303] Did update state to: 5 > 2013-04-04 15:18:15.838 cbtest[4025:1303] Did retrieve peripheral: <CBConcretePeripheral: 0x10010bf40> > > -- dave > > #import <Foundation/Foundation.h> > #import <IOBluetooth/IOBluetooth.h> > > @interface WirelessBandManager : NSObject <CBCentralManagerDelegate> > { > CBCentralManager * mBLEManager; > CBPeripheral * mPeripheral; > dispatch_queue_t mBleDispatchQueue; > } > @end > > @implementation WirelessBandManager > > - (id)init > { > self = [super init]; > if (self) > { > mBleDispatchQueue = dispatch_queue_create("com.xyz.ble.mgr", DISPATCH_QUEUE_SERIAL); > mBLEManager = [[CBCentralManager alloc] initWithDelegate:self queue:mBleDispatchQueue]; > } > return self; > } > > #pragma mark - > #pragma mark CBCentralManager Delegate Methods > - (void)centralManagerDidUpdateState:(CBCentralManager *)central > { > NSLog(@"Did update state to: %d",(int)central.state); > if (central.state == CBCentralManagerStatePoweredOn) > { > NSMutableArray * uuids = [[NSMutableArray alloc] initWithCapacity:1]; > NSString * uuidStr = @"42EF45DA-718D-42C2-AB91-A6588121E52A"; > CFUUIDRef uuidRef = CFUUIDCreateFromString(NULL, (CFStringRef)uuidStr); > [uuids addObject:(id)uuidRef]; > CFRelease(uuidRef); > > [mBLEManager retrievePeripherals:uuids]; > [uuids release]; > } > } > > - (void)centralManager:(CBCentralManager *)central didRetrievePeripherals:(NSArray *)peripherals > { > mPeripheral = [peripherals[0] retain]; > > NSLog(@"Did retrieve peripheral: %@",mPeripheral); > > NSDictionary *connOptions = [NSDictionary dictionaryWithObject:[NSNumber numberWithBool:YES] forKey:CBConnectPeripheralOptionNotifyOnDisconnectionKey]; > > [mBLEManager connectPeripheral:mPeripheral options:connOptions]; > } > > - (void)centralManager:(CBCentralManager *)central didConnectPeripheral:(CBPeripheral *)peripheral > { > NSLog(@"Did connect to peripheral: %@",peripheral); > } > - (void)centralManager:(CBCentralManager *)central didFailToConnectPeripheral:(CBPeripheral *)peripheral error:(NSError *)error > { > NSLog(@"Did FAIL to connect to peripheral: %@ Error:%@",peripheral,error); > } > - (void)centralManager:(CBCentralManager *)central didDisconnectPeripheral:(CBPeripheral *)peripheral error:(NSError *)error > { > NSLog(@"Did disconnect from peripheral: %@ Error:%@",peripheral,error); > } > > > @end > > #pragma mark - > #pragma mark MAIN > // ========================================================================= > // main() > // ========================================================================= > int main(int argc, const char * argv[]) > { > @autoreleasepool > { > [[WirelessBandManager alloc] init]; > dispatch_main(); > } > return 0; > } > > > On Apr 4, 2013, at 2:34 PM, Andras Kovi <allprog(a)gmail.com> wrote: > >> Hi Dave, >> >> I haven't tried to run CB in a command line app, but one little note: make sure you don't use WiFi while connected. WiFi and BLE interfere severely on my Mac Mini. I guess it's similar on the MacBook. >> >> Do you want to connect to an i* device or a proprietary one? i* devices change their BLE addresses every few minutes. If you don't use secure connection, then I think they can get out of sync. This is probably the reason why you need to do a scan. Command line or Cocoa should not make any difference IMHO. >> >> Andras >> >> On 2013.04.04., at 22:40, dave-ble(a)greylogic.com wrote: >> >>> Hi, >>> >>> I'm trying to write a simple command line app that uses CoreBluetooth on an BLE capable mac book (OSX v10.8.3). >>> >>> If I use the retrievePeripherals I get the delegate didRetrievePeripherals to fire. If I then try to connect to the found peripheral, the didConnectPeripheral delegate never fires. >>> >>> However, if I scan for peripherals and get the delegate didDiscoverPeripheral to fire. I can then connect and connect succeeds. However, once I'm connected and have my characteristics, the data I receive from my peripheral is not reliably received. >>> >>> Using similar code in a GUI application works perfect. >>> >>> Has anyone else been successful running the CoreBluetooth stack from within a command line app? >>> >>> In my main I essentially create a dispatch_queue and let it run my operations via dispatch_async. Meanwhile, I let main just call dispatch_main(). >>> >>> -- dave >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) >>> Help/Unsubscribe/Update your Subscription: >>> https://lists.apple.com/mailman/options/bluetooth-dev/allprog%40gmail.com >>> >>> This email sent to allprog(a)gmail.com > _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)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(a)lists.apple.com

1 0

Re: Using CoreBluetooth from Command Line Tool
by dave-ble＠greylogic.com 04 Apr '13

04 Apr '13

It is a proprietary device I'm connecting with, so the UUID isn't changing (it is the same UUID I see when I scan from my GUI app or command line app). The symptoms feel like a dead lock on the queue CoreBluetooth is using to send events. Being I have no visibility it is hard to know for sure. Below is a stripped version of the code that fails to respond to the connect. Note: the UUID is hardcoded to simplify my testing. Using the same hardcoded UUID in my GUI version works and behaves as expected. The debug log output is the following (nothing more) 2013-04-04 15:18:15.836 cbtest[4025:1303] Did update state to: 5 2013-04-04 15:18:15.838 cbtest[4025:1303] Did retrieve peripheral: <CBConcretePeripheral: 0x10010bf40> -- dave #import <Foundation/Foundation.h> #import <IOBluetooth/IOBluetooth.h> @interface WirelessBandManager : NSObject <CBCentralManagerDelegate> { CBCentralManager * mBLEManager; CBPeripheral * mPeripheral; dispatch_queue_t mBleDispatchQueue; } @end @implementation WirelessBandManager - (id)init { self = [super init]; if (self) { mBleDispatchQueue = dispatch_queue_create("com.xyz.ble.mgr", DISPATCH_QUEUE_SERIAL); mBLEManager = [[CBCentralManager alloc] initWithDelegate:self queue:mBleDispatchQueue]; } return self; } #pragma mark - #pragma mark CBCentralManager Delegate Methods - (void)centralManagerDidUpdateState:(CBCentralManager *)central { NSLog(@"Did update state to: %d",(int)central.state); if (central.state == CBCentralManagerStatePoweredOn) { NSMutableArray * uuids = [[NSMutableArray alloc] initWithCapacity:1]; NSString * uuidStr = @"42EF45DA-718D-42C2-AB91-A6588121E52A"; CFUUIDRef uuidRef = CFUUIDCreateFromString(NULL, (CFStringRef)uuidStr); [uuids addObject:(id)uuidRef]; CFRelease(uuidRef); [mBLEManager retrievePeripherals:uuids]; [uuids release]; } } - (void)centralManager:(CBCentralManager *)central didRetrievePeripherals:(NSArray *)peripherals { mPeripheral = [peripherals[0] retain]; NSLog(@"Did retrieve peripheral: %@",mPeripheral); NSDictionary *connOptions = [NSDictionary dictionaryWithObject:[NSNumber numberWithBool:YES] forKey:CBConnectPeripheralOptionNotifyOnDisconnectionKey]; [mBLEManager connectPeripheral:mPeripheral options:connOptions]; } - (void)centralManager:(CBCentralManager *)central didConnectPeripheral:(CBPeripheral *)peripheral { NSLog(@"Did connect to peripheral: %@",peripheral); } - (void)centralManager:(CBCentralManager *)central didFailToConnectPeripheral:(CBPeripheral *)peripheral error:(NSError *)error { NSLog(@"Did FAIL to connect to peripheral: %@ Error:%@",peripheral,error); } - (void)centralManager:(CBCentralManager *)central didDisconnectPeripheral:(CBPeripheral *)peripheral error:(NSError *)error { NSLog(@"Did disconnect from peripheral: %@ Error:%@",peripheral,error); } @end #pragma mark - #pragma mark MAIN // ========================================================================= // main() // ========================================================================= int main(int argc, const char * argv[]) { @autoreleasepool { [[WirelessBandManager alloc] init]; dispatch_main(); } return 0; } On Apr 4, 2013, at 2:34 PM, Andras Kovi <allprog(a)gmail.com> wrote: > Hi Dave, > > I haven't tried to run CB in a command line app, but one little note: make sure you don't use WiFi while connected. WiFi and BLE interfere severely on my Mac Mini. I guess it's similar on the MacBook. > > Do you want to connect to an i* device or a proprietary one? i* devices change their BLE addresses every few minutes. If you don't use secure connection, then I think they can get out of sync. This is probably the reason why you need to do a scan. Command line or Cocoa should not make any difference IMHO. > > Andras > > On 2013.04.04., at 22:40, dave-ble(a)greylogic.com wrote: > >> Hi, >> >> I'm trying to write a simple command line app that uses CoreBluetooth on an BLE capable mac book (OSX v10.8.3). >> >> If I use the retrievePeripherals I get the delegate didRetrievePeripherals to fire. If I then try to connect to the found peripheral, the didConnectPeripheral delegate never fires. >> >> However, if I scan for peripherals and get the delegate didDiscoverPeripheral to fire. I can then connect and connect succeeds. However, once I'm connected and have my characteristics, the data I receive from my peripheral is not reliably received. >> >> Using similar code in a GUI application works perfect. >> >> Has anyone else been successful running the CoreBluetooth stack from within a command line app? >> >> In my main I essentially create a dispatch_queue and let it run my operations via dispatch_async. Meanwhile, I let main just call dispatch_main(). >> >> -- dave >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/bluetooth-dev/allprog%40gmail.com >> >> This email sent to allprog(a)gmail.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)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(a)lists.apple.com

1 0

Re: Using CoreBluetooth from Command Line Tool
by Andras Kovi 04 Apr '13

04 Apr '13

Hi Dave, I haven't tried to run CB in a command line app, but one little note: make sure you don't use WiFi while connected. WiFi and BLE interfere severely on my Mac Mini. I guess it's similar on the MacBook. Do you want to connect to an i* device or a proprietary one? i* devices change their BLE addresses every few minutes. If you don't use secure connection, then I think they can get out of sync. This is probably the reason why you need to do a scan. Command line or Cocoa should not make any difference IMHO. Andras On 2013.04.04., at 22:40, dave-ble(a)greylogic.com wrote: > Hi, > > I'm trying to write a simple command line app that uses CoreBluetooth on an BLE capable mac book (OSX v10.8.3). > > If I use the retrievePeripherals I get the delegate didRetrievePeripherals to fire. If I then try to connect to the found peripheral, the didConnectPeripheral delegate never fires. > > However, if I scan for peripherals and get the delegate didDiscoverPeripheral to fire. I can then connect and connect succeeds. However, once I'm connected and have my characteristics, the data I receive from my peripheral is not reliably received. > > Using similar code in a GUI application works perfect. > > Has anyone else been successful running the CoreBluetooth stack from within a command line app? > > In my main I essentially create a dispatch_queue and let it run my operations via dispatch_async. Meanwhile, I let main just call dispatch_main(). > > -- dave > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/bluetooth-dev/allprog%40gmail.com > > This email sent to allprog(a)gmail.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)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(a)lists.apple.com

1 0

Using CoreBluetooth from Command Line Tool
by dave-ble＠greylogic.com 04 Apr '13

04 Apr '13

Hi, I'm trying to write a simple command line app that uses CoreBluetooth on an BLE capable mac book (OSX v10.8.3). If I use the retrievePeripherals I get the delegate didRetrievePeripherals to fire. If I then try to connect to the found peripheral, the didConnectPeripheral delegate never fires. However, if I scan for peripherals and get the delegate didDiscoverPeripheral to fire. I can then connect and connect succeeds. However, once I'm connected and have my characteristics, the data I receive from my peripheral is not reliably received. Using similar code in a GUI application works perfect. Has anyone else been successful running the CoreBluetooth stack from within a command line app? In my main I essentially create a dispatch_queue and let it run my operations via dispatch_async. Meanwhile, I let main just call dispatch_main(). -- dave _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)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(a)lists.apple.com

1 0

RE: A2DP with AAC codec: non-existent document reference in the "Bluetooth Accessory Design Guidelines for Apple Products"
by John Westing 04 Apr '13

04 Apr '13

_______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)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(a)lists.apple.com

1 0

Re: Battery Usage - Connect vs. Scan - App in Background
by Michael Farley 04 Apr '13

04 Apr '13

_______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)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(a)lists.apple.com

1 0

UUID across Factory Reset
by Ram Jayaraman 04 Apr '13

04 Apr '13

_______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)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(a)lists.apple.com

1 0

Re: Battery Usage - Connect vs. Scan - App in Background
by Andras Kovi 03 Apr '13

03 Apr '13

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(a)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(a)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(a)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(a)lists.apple.com) >>> Help/Unsubscribe/Update your Subscription: >>> https://lists.apple.com/mailman/options/bluetooth-dev/stevejabs%40gmail.com >>> >>> This email sent to stevejabs(a)gmail.com >> > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/bluetooth-dev/allprog%40gmail.com > > This email sent to allprog(a)gmail.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)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(a)lists.apple.com

1 0

Re: Battery Usage - Connect vs. Scan - App in Background
by Michael Farley 03 Apr '13

03 Apr '13

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(a)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(a)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(a)lists.apple.com) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/bluetooth-dev/stevejabs%40gmail.com >> >> This email sent to stevejabs(a)gmail.com > _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)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(a)lists.apple.com

1 0