There's a lot of hype and excitement about iBeacons and BLE hardware and the kind of interactions and use-cases that are now possible. At Localz, we’ve been working with iBeacon related software services since August 2013 (iBeacon was announced by Apple in June 2013) and learned what to look for to support retail and shopping deployments. We’ll assume you know what iBeacon is and how it can be used.
iBeacon is built around the Bluetooth 4.0 - Low Energy (BLE4.0) standard. Technically, it’s possible to send iBeacon broadcasts on any device which allows customisation of BLE4.0 broadcasts. Whilst Apple has not publicly disclosed the iBeacon protocol, we and others have reverse engineered the standard. With standard in hand, any of us can use and deploy iBeacon.
For the hacker, detailed iBeacon protocols are published at:
BLE4.0 capable hardware is included in most recent smartphones. Unlike older Bluetooth technology, it uses little power which means it can be enabled at all times. However, not all BLE4.0 devices work natively with Apple’s iBeacon protocol.
For Apple devices, iOS 7.0 or later is required. iBeacon compatible devices include
iPhone: 4s, 5, 5c, 5s
iPad: 3, 4, mini
iPOD Touch: 5th gen
With a bit of code hacking (bravo Gennadi), it’s possible to use iBeacon on select Android devices. BLE4.0 capable hardware and Android API version 18 (Android OS 4.3) or later is required. Tested and working Android devices include:
Google: Nexus 7 tablet, Nexus 4 and Nexus 5
Samsung: Galaxy SIII, Galaxy S4
HTC: One, One Max, One Mini, One X+, Droid DNA (the later as per HTC rep)
With any of the above devices, it’s possible to broadcast iBeacon notifications...but that would be expensive.
Our base device criteria
When we evaluate BLE4.0 hardware, we’re looking at deployment in retail, hospitality, entertainment and destination marketing locations. For us this means:
small form factor: make it easy to put them anywhere….no eyesores
battery powered preferred: power outlets are sparse or not located in ideal spots and electrician services are expensive
long battery life: we don’t want to service these too often
radio range: we need devices capable of broadcasting 50 meters or greater
weather resistant: they need to operate in the cold Tasmanian winters, hot Australian summers, humid tropical locations and they need to work outdoors but in protected enclosures
certified: in many countries, radio emitting devices need to conform to national standards and pass a technical certification such as FCC (USA), IC (Canada), CE (Europe) and in Australia AS/NZS 4268 and Class License 2000
reliable and stable firmware: the software stack needs to run without issue 24 x 365
updatable firmware: there are likely to be changes to protocols and we need the ability to securely update firmware
adjustable radio power: for indoor placements, we need adjustable radio power to prevent cross-talk, at a minimum we need to adjust the RSSI setting
zero end user configuration: we want to make installation a frictionless experience
secure administrator configuration: only authorised applications and users should be able to change the device configuration
reportable battery life: we need to remotely read battery life to know when to service
Supported protocols: not all devices support or adhere to Apple’s iBeacon protocol. Whilst they may work with iOS, devices that use other protocols are unable to take advantage of native OS features like: background beacon detection, proximity OS notification, and OS controlled proximity ranging.
Production availability: iBeacon is a new technology. A lot of hardware developers jumped into the game but when pressed for inventory, not all can deliver production ready units.
Support documentation: we need devices to work in a commercial setting. That means having well documented technical and operational standards.
What to know more and which hardware we're currently using for different use cases?
Signup for our newsletter or contact us.