• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Options for passively communicating with BLE devices
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Options for passively communicating with BLE devices

  • Subject: Re: Options for passively communicating with BLE devices
  • From: Ramin Firoozye <email@hidden>
  • Date: Tue, 17 Jun 2014 10:25:10 -0700
FWIW, I've used both Bluegiga and Nordic to build configurable iBeacon devices. On the device end once you're connected you turn off the iBeacon advertising, read and adjust the settings, then compose a new iBeacon ad packet and start advertising it on disconnect. It's pretty straightforward.

On the iOS side you can scan for the configuration service using CB while scanning for the beacon at the same time. Haven't had an issue at all.

As for the original question on passively sending data, one option is to have your firmware send out alternate custom advertising packets. On tick you can send out iBeacon, on tock you send out your own custom packet with device-specific data. On the iOS side iBeacon consumes the beacon packet and CB returns your other peripheral advertising data.

Apple's recommended iBeacon interval is 100 msec so phones can update position data quickly. If your device battery can take it you can do alternate advertising every 50 msec and stick with Apple's recommendations, or increase the intervals and save battery at the expense of fast user updates.

On the receiving end you'll have to experiment with reception latency because CB only returns data to the app every so often. You may also want to turn off duplication removal and manage the peripheral list yourself. They also parse the advertising data and return a filtered version in a dictionary so be aware that some of the data may not make it through. And of course anyone passing by could read the data since it's a broadcast.

Best,
Ramin


On 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
  • Follow-Ups:
    • Re: Options for passively communicating with BLE devices
      • From: Richard Bown <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>)

  • Prev by Date: Re: Options for passively communicating with BLE devices
  • Next by Date: Re: Options for passively communicating with BLE devices
  • Previous by thread: Re: Options for passively communicating with BLE devices
  • Next by thread: Re: Options for passively communicating with BLE devices
  • Index(es):
    • Date
    • Thread