Apple

On Tue, Jun 17, 2014 at 9:50 AM, Spero Koulouras <email@hidden> wrote:

iBeacons are not connectable, so the BLE Peripheral must actively switch between advertising as an iBeacon and advertising its "native", connectable services. The iBeacon advertisements trigger notifications, the native services interact with Core Bluetooth.

Spero Koulouras (408) 874-6331

On Tue, Jun 17, 2014 at 9:21 AM, William Henderson <email@hidden> wrote:

Interesting. In the past I’ve read (on this list) that folks have had trouble getting iBeacon and CoreBluetooth to work together. Is there a trick to getting them both to work?

Best,
William

On Friday, June 13, 2014 at 6:07 PM, Spero Koulouras wrote:

Our use case, for home automation, requires that many BLE Peripherals (lights, plugs, locks, etc) can be controlled by multiple smartphones acting as BLE Centrals. Our approach has evolved to a hybrid iBeacon/long running scan model:

- All peripherals act as iBeacons, triggering a notification when the phone comes in range. Our app can be brought to the foreground as a result of the notification.

- When in the foreground our app uses long-running scans for our automation service uuid's. We continue to scan in the background at a significantly reduced rate.

- Our peripherals advertise our service UUID and also advertise MFG specific data including current device state.
- When the smartphone scans and receives the MFG specific data it updates local state for each discovered device. This has an impact on the smartphone UI of indicating a light is on/off or a lock open/closed whether the change was caused manually on the peripheral or via command from any controller.

- When we need to control a device the smartphone connects, updates a characteristic, then disconnects. Our connection lifetimes are as short as possible.

Operating in this "disconnected" mode allows multiple controllers to operate with the same set of peripherals. State updates are conveyed through the advertising packets without a connection required. The downside to this method of operation is that even though control messages are secure, state information in the advertising packets is transmitted in the clear. Other issues include a potential race condition when two controllers try to update the same device (very small window, safely ignored for us) and latency on slave updates proportional to the frequency of advertising packets.

Spero Koulouras (408) 874-6331

On Fri, Jun 13, 2014 at 3:52 PM, William Henderson <email@hidden> wrote:

From what I’ve seen, there are a few ways for an iPhone to passively communicate with a BLE device when it comes in range:

- Use iBeacon
- Lower power, iOS takes care of the details including app being killed

- Can take a while to discover (up to 15 minutes)
- No way to transmit any data with the peripheral – from what I’ve heard on this list there is no way to make an iBeacon that is also discoverable/connectable via CoreBluetooth

- Example use case: indoor location or advertising beacons
- Use long-running connections

- Lower power, iOS takes care of the details including app being killed
- Need to discover the device first (unless there is a way to have all devices ‘pretend’ to be the same device?)

- From what I’ve heard, doesn’t work well with multiple devices.
- Example use case: a door lock or other single device you need to talk to

- Use long-running scans
- Higher power, iOS takes care of the details including app being killed

- Higher latency.
- Must scan for specific UDIDs but does work with multiple devices

- Canonical use case: Not sure. Has anyone used this approach?
- Have the iPhone act as a peripheral, always advertising.

- Lower power, iOS takes care of the details including app being killed
- Pretty fast, or at least as fast as you can afford to scan with your central

- iOS rotates UDIDs so you have to always scan versus reconnect
- This essentially off loads the power responsibility to the other side, which means your central is going to need a big battery or an intelligent way to limit scanning.

- Example use case: Knock uses this approach

Anyone care to expand on these strategies or maybe know of one I missed? I’m specifically interested in approaches that can passively (in the background) communicate with a large number of BLE 1st party peripherals (similar to iBeacon but with the ability to transmit data).

William

_______________________________________________
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

_______________________________________________
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:
	>Options for passively communicating with BLE devices (From: William Henderson <email@hidden>)
	>Re: Options for passively communicating with BLE devices (From: Spero Koulouras <email@hidden>)
	>Re: Options for passively communicating with BLE devices (From: William Henderson <email@hidden>)
	>Re: Options for passively communicating with BLE devices (From: Spero Koulouras <email@hidden>)
	>Re: Options for passively communicating with BLE devices (From: Martijn The <email@hidden>)