Apple

I filed a similar bug to Apple, complained about " Coexistence of iBeacon and connectable BLE peripheral "

Apple's office reply is " Per iBeacon spec, beacons are non-connectable and use all 30 bytes in adv payload "

See my bug report and Apple's reply:




This is a follow-up to Bug ID# 16647123. 

Behavior is as per design, i.e, feature.
Per iBeacon spec, beacons are non-connectable and use all 30 bytes in adv payload.


We consider this issue closed. If you have any questions or concern regarding this issue, please update your report directly (http://bugreport.apple.com).



Thank you for taking the time to notify us of this issue.

Best Regards,

Apple Developer Support
Worldwide Developer Relations

**************************************************************************


THE INFORMATION CONTAINED IN THIS MESSAGE IS UNDER NON-DISCLOSURE
**************************************************************************

-------------------------------------------------------
Bug ID #: 16647123


Bug Title: Coexistence of iBeacon and connectable BLE peripheral‏
-------------------------------------------------------
<GMT17-Apr-2014 16:50:26GMT> qinghui tang:
Summary:
We want to develop a BLE device that can be used both as a connectable BLE peripheral and iBeacon device.



To be able to connect with iOS device, BLE device needs to respond scan request from iOS devices with response data(such as TX power, name, etc).

Meanwhile our BLE device periodically broadcasts iBeacon packets.


But here comes the conflict part between the two.
1) If we disable scan response function of BLE device, then iOS App can find the iBeacon signal correct (distance, accuracy, etc), but our BLE device will not respond SCAN req from iOS device.



2) If we enable scan response function of BLE device, but the CoreLocation function locationManager:didRangeBeacons:inRegion show no beacon signal can be found.

The difference between 1) and 2) is just commenting or uncommenting a single line


in our BLE firmware source code, iOS App side is untouched:
GAP_LE_Set_Scan_Response_Data (a function from Stonestreeone Bluetooth stack)
It seems Apple designed iBeacon in a way to disallow a BLE device to be used as


a BLE peripheral that can respond to BLE scan request

From: email@hidden
Date: Wed, 30 Apr 2014 09:33:15 -0700
Subject: iBeacon changes from 7.0 to 7.1.1
To: email@hidden

We've built a custom peripheral and had iBeacons working with iOS 7.0. With the update to 7.1.1 something appears to be broken and we have filed bug report 16769559 with the details.

It seems that the inclusion of Manufacturic Specific data in the scan response which the peripheral sends in response to a Scan Request from iOS blocks the iOS device from recognizing our beacon.

Our peripheral sends an ADV packet which contains the beacon proximity uuid, major and minor correctly. This is seen by the iOS device and we can correctly go in/out of range, distance can be discovered, etc. The iBeacon functionality will allow our app to get launched whenever we come in range of our periperal. That's great.

Unfortunately, our app relies on a MANUFACTURER SPECIFIC element which we embed in a Scan Response packet. In iOS 7.0 this did not cause any problems, however in 7.1.1 our devices are no longer detected as beacons. Removing the mfg specific element from the scan response allows iBeacons to work, but causes problems for our app.

Anyone else dealing with this?

Spero Koulouras (408) 874-6331

_______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden

References:
	>iBeacon changes from 7.0 to 7.1.1 (From: Spero Koulouras <email@hidden>)
	>RE: iBeacon changes from 7.0 to 7.1.1 (From: Qinghui Tang <email@hidden>)