September 2012 - Bluetooth-dev

App not receiving accessory connection notification (EAFramework)
by Robert Carlsen 05 Sep '12

05 Sep '12

I'm not sure if this is the appropriate forum for classic Bluetooth / EAFramework, but I'll reach out here and follow-up with a rdar if necessary. We're observing an unexpected scenario when pairing a Bluetooth accessory. An app which declares an entry in the UISupportedExternalAccessoryProtocols plist key and declares the "external-accessory" UIBackgroundMode is not receiving the accessory connection notification in certain circumstances. Specifically, we install and launch the app (after a fresh boot of the phone). The app registers itself to receive the EAAccessoryManager's local notifications. The app is put in the background and the accessory is discovered and paired with in the iOS Bluetooth preferences. When the accessory is listed as "Connected" the app does not receive the expected connection notification. Furthermore, when the app is brought back to the foreground the EAAccessoryManager's connectedAccessories property does not contain the newly paired and connected accessory (it returns an empty array). The app *does* see the accessory in the connectedAccessories array after it has been force-quit and relaunched. Alternatively, the app will receive a connection notification (even while in the background) if the Bluetooth link with the accessory is severed and re-established. Has anyone observed something similar? Is there a more appropriate forum for this question? Regards, -Robert R/GA 350 West 39th Street New York, NY 10018 http://www.rga.com/ http://www.twitter.com/rga http://www.facebook.com/rga The Agency for the Digital Age™ This message contains information which may be confidential and privileged. Unless you are intended recipient (or authorized to receive this message for the intended recipient), you may not copy, disseminate or disclose to anyone the message or any information contained in the message. If you have received the message in error, please notify the sender by reply e-mail or forward the message to mailto:postmaster@rga.com and delete the message. Thank you very much. _______________________________________________ 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: Connecting to a known BT address with BLE
by Etan Kissling 05 Sep '12

05 Sep '12

CoreBluetooth does not expose the BdAddr at any point, although it would be technically possible. Your idea could therefore only be achieved if you would add a characteristic to read the device address to your GATT database. Etan On 05.09.2012, at 15:11, Jimmy Adler <d99fish(a)gmail.com> wrote: > Hi Etan, > > thanks for the reply, even if it wasn't the reply I was hoping for! > > Is it possible to retrieve the address in some way after connecting > to a peripheral? In that case I could connect to the device with the > best signal strengt, retrieve the address and then compare it to > the scanned address (that I get from the camera), if they don't match > I could then connect to the next device in the list until I get a match. > > Br, > > Jimmy > > On Sep 5, 2012, at 1:54 PM, Etan Kissling wrote: > >> Jimmy, >> >> the UUID is not dependent of the BdAddr and is generated only when >> you connect to the device for the first time. It is also different when you >> connect from a different iPhone. >> >> The reason for this seems to be that when you have a bond, and the >> device address changes, that then the UUID should stay the same, >> allowing you to connect to the known device again. >> >> Connecting to a device by BdAddr is not currently supported by the >> CoreBluetooth framework API. One solution would be to broadcast >> your BdAddr in your Advertising packets, and then use the scanning >> facilities to detect your device. However, it is rather a hacky solution. >> Please note that only a limited amount of data can be stored in >> advertising data (should be around 31 bytes with AD_TYPE headers). >> >> Etan >> >> On 05.09.2012, at 00:49, Jimmy Adler <d99fish(a)gmail.com> wrote: >> >>> Hi, >>> >>> I was wondering how to go about connecting (or attempt to >>> connect) to a BLE device that I know the address to. >>> >>> It seems I should do >>> [centralManager connectPeripheral:peripheral options:nil] >>> with a peripheral that I construct myself, but that is not legal >>> since all the properties in the object are readonly. >>> >>> Is there any way of doing this? >>> >>> I have tried scanning for my device and printing the resulting >>> UUID for the peripheral, but that does not match with the given >>> address of the device. (the address is printed on the device >>> and scanned using barcode scanner to initiate pairing). >>> >>> Should I not receive the correct address when printing the UUID >>> of the peripheral received in "didDiscoverPeripheral"? >>> >>> Br, >>> >>> Jimmy >>> _______________________________________________ >>> 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/etan.kissling%40obero… >>> >>> This email sent to etan.kissling(a)oberon.ch >> > _______________________________________________ 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: Connecting to a known BT address with BLE
by Jimmy Adler 05 Sep '12

05 Sep '12

Hi Etan, thanks for the reply, even if it wasn't the reply I was hoping for! Is it possible to retrieve the address in some way after connecting to a peripheral? In that case I could connect to the device with the best signal strengt, retrieve the address and then compare it to the scanned address (that I get from the camera), if they don't match I could then connect to the next device in the list until I get a match. Br, Jimmy On Sep 5, 2012, at 1:54 PM, Etan Kissling wrote: > Jimmy, > > the UUID is not dependent of the BdAddr and is generated only when > you connect to the device for the first time. It is also different when you > connect from a different iPhone. > > The reason for this seems to be that when you have a bond, and the > device address changes, that then the UUID should stay the same, > allowing you to connect to the known device again. > > Connecting to a device by BdAddr is not currently supported by the > CoreBluetooth framework API. One solution would be to broadcast > your BdAddr in your Advertising packets, and then use the scanning > facilities to detect your device. However, it is rather a hacky solution. > Please note that only a limited amount of data can be stored in > advertising data (should be around 31 bytes with AD_TYPE headers). > > Etan > > On 05.09.2012, at 00:49, Jimmy Adler <d99fish(a)gmail.com> wrote: > >> Hi, >> >> I was wondering how to go about connecting (or attempt to >> connect) to a BLE device that I know the address to. >> >> It seems I should do >> [centralManager connectPeripheral:peripheral options:nil] >> with a peripheral that I construct myself, but that is not legal >> since all the properties in the object are readonly. >> >> Is there any way of doing this? >> >> I have tried scanning for my device and printing the resulting >> UUID for the peripheral, but that does not match with the given >> address of the device. (the address is printed on the device >> and scanned using barcode scanner to initiate pairing). >> >> Should I not receive the correct address when printing the UUID >> of the peripheral received in "didDiscoverPeripheral"? >> >> Br, >> >> Jimmy >> _______________________________________________ >> 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/etan.kissling%40obero… >> >> This email sent to etan.kissling(a)oberon.ch > _______________________________________________ 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: Connecting to a known BT address with BLE
by Etan Kissling 05 Sep '12

05 Sep '12

Jimmy, the UUID is not dependent of the BdAddr and is generated only when you connect to the device for the first time. It is also different when you connect from a different iPhone. The reason for this seems to be that when you have a bond, and the device address changes, that then the UUID should stay the same, allowing you to connect to the known device again. Connecting to a device by BdAddr is not currently supported by the CoreBluetooth framework API. One solution would be to broadcast your BdAddr in your Advertising packets, and then use the scanning facilities to detect your device. However, it is rather a hacky solution. Please note that only a limited amount of data can be stored in advertising data (should be around 31 bytes with AD_TYPE headers). Etan On 05.09.2012, at 00:49, Jimmy Adler <d99fish(a)gmail.com> wrote: > Hi, > > I was wondering how to go about connecting (or attempt to > connect) to a BLE device that I know the address to. > > It seems I should do > [centralManager connectPeripheral:peripheral options:nil] > with a peripheral that I construct myself, but that is not legal > since all the properties in the object are readonly. > > Is there any way of doing this? > > I have tried scanning for my device and printing the resulting > UUID for the peripheral, but that does not match with the given > address of the device. (the address is printed on the device > and scanned using barcode scanner to initiate pairing). > > Should I not receive the correct address when printing the UUID > of the peripheral received in "didDiscoverPeripheral"? > > Br, > > Jimmy > _______________________________________________ > 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/etan.kissling%40obero… > > This email sent to etan.kissling(a)oberon.ch _______________________________________________ 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: CoreBluetooth: writeValue:forCharacteristic:type: always fails when using 128-Bit UUIDs on iOS 6 beta 4
by Etan Kissling 05 Sep '12

05 Sep '12

Florian, I have tested 128-bit UUIDs on iOS 6 Beta 4 and did not encounter such problems. In my case, a CSR 1000 chip was used as peripheral, and a new iPad as well as an iPhone 4S were used as centrals. I am using both 128-bit and 16-bit UUIDs for primary services and characteristics. I am also using only short characteristics with less than or equal 20 bytes of payload. What you could do is to use the TI packet sniffer software to get an air trace. CoreBluetooth does not expose valuable information in the error-objects. Therefore, the air trace could provide you with further information on what could go wrong in your case. Could it be that your GATT-database is malformed? And do BLE tools from the AppStore also encounter errors when writing to your characteristics? Etan On 05.09.2012, at 13:51, Florian Schulz <florianschulz(a)me.com> wrote: > Hi, > > We are developing accessory hardware implementing the peripheral role - our app acts as the central. We are using the TI CC2540 chip for BLE on our hardware. > > Recently we discovered a major issue regarding iOS 6. On iOS 6 beta 4 writing values using writeValue:forCharacteristic:type: always fails, when we don't use standard profile UUIDs. We are using 128-Bit UUIDs for either our custom services and characteristics. We also tried using a 128-Bit UUID just for the service, and 16-Bit UUIDs for the characteristics with no success. The didWriteValueForCharacteristic: callback is fired immediately after starting the write request. An error object is passed to that callback, saying that the operation couldn't be completed: > peripheral:didWriteValueForCharacteristic:error: Code: 0 Domain: > CBErrorDomain Description: Unknown error. > > The write has no effect. On iOS 5.1.1 writing values using 128-Bit UUIDs works fine. We don't know exactly if the error only exists since iOS 6 beta 4, or if it was present on previous iOS 6 builds as well. > > This is a critical issue for us, since we are about to start mass production of our hardware. > > Is this behavior caused by a change in iOS 6 that will find its way to the final release, or is this a beta issue? > > Best Regards, > Florian > _______________________________________________ > 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/etan.kissling%40obero… > > This email sent to etan.kissling(a)oberon.ch _______________________________________________ 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

CoreBluetooth: writeValue:forCharacteristic:type: always fails when using 128-Bit UUIDs on iOS 6 beta 4
by Florian Schulz 05 Sep '12

05 Sep '12

Hi, We are developing accessory hardware implementing the peripheral role - our app acts as the central. We are using the TI CC2540 chip for BLE on our hardware. Recently we discovered a major issue regarding iOS 6. On iOS 6 beta 4 writing values using writeValue:forCharacteristic:type: always fails, when we don't use standard profile UUIDs. We are using 128-Bit UUIDs for either our custom services and characteristics. We also tried using a 128-Bit UUID just for the service, and 16-Bit UUIDs for the characteristics with no success. The didWriteValueForCharacteristic: callback is fired immediately after starting the write request. An error object is passed to that callback, saying that the operation couldn't be completed: peripheral:didWriteValueForCharacteristic:error: Code: 0 Domain: CBErrorDomain Description: Unknown error. The write has no effect. On iOS 5.1.1 writing values using 128-Bit UUIDs works fine. We don't know exactly if the error only exists since iOS 6 beta 4, or if it was present on previous iOS 6 builds as well. This is a critical issue for us, since we are about to start mass production of our hardware. Is this behavior caused by a change in iOS 6 that will find its way to the final release, or is this a beta issue? Best Regards, Florian _______________________________________________ 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

Connecting to a known BT address with BLE
by Jimmy Adler 04 Sep '12

04 Sep '12

Hi, I was wondering how to go about connecting (or attempt to connect) to a BLE device that I know the address to. It seems I should do [centralManager connectPeripheral:peripheral options:nil] with a peripheral that I construct myself, but that is not legal since all the properties in the object are readonly. Is there any way of doing this? I have tried scanning for my device and printing the resulting UUID for the peripheral, but that does not match with the given address of the device. (the address is printed on the device and scanned using barcode scanner to initiate pairing). Should I not receive the correct address when printing the UUID of the peripheral received in "didDiscoverPeripheral"? Br, Jimmy _______________________________________________ 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: BTLE test environment
by Gabriele Merlonghi 04 Sep '12

04 Sep '12

_______________________________________________ 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: Which specification talks about how may master [ i.e. iPhone ] can be bonded with each peripheral?
by Craig Dooley 04 Sep '12

04 Sep '12

_______________________________________________ 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

Why didDiscoverPeripheral is invoked if i invoke connectPeripheral in didDisconnectPeripheral?
by ramprakash.thinakaran＠wipro.com 04 Sep '12

04 Sep '12

_______________________________________________ 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