Possible use cases and business models for the beacon that enables location-dependent user interaction even inside buildings are currently being hotly debated. In-store advertising and discounts, mobile payments, navigation, public transport, localization in public buildings and museums and home automation are just the tips of the iceberg. And of course the omnipresent collection of data – now new and with precise location information. Before learning more about iBeacon technology, we will also mention the iBeacon SDK in the article.
What is the hype?
The iBeacon protocol developed by Apple based on Bluetooth Low Energy is supported by a variety of devices. The article explains iBeacons and Bluetooth Low Energy and uses the example of developing an Android app for location-dependent shopping lists to show the location-dependent interaction of an app with iBeacons. The implementation is based on MOKOSmart iBeacon SDK.
iBeacon, Bluetooth 4.0, BLE, SMART. Wot?
The basic technology for iBeacon is Bluetooth. Bluetooth Low Energy (BLE), which is often referred to as the Bluetooth Smart marketing label, has been included in version 4.0 of the Bluetooth standard. BLE is not backward compatible with previous versions called Bluetooth Classic. Bluetooth 4.0 specifies that standard-compliant devices must implement one or both variants, i.e. Low Energy or Classic.
BLE is implemented on almost all current smartphones such as the iPhone 4+ and the Samsung Galaxy 3+. An iPhone can function both as a receiver of iBeacon signals and – unlike Android – as a beacon itself. Android includes BLE drivers from API version 18, i.e. Android 4.3. Incidentally, current computers are also BLE-capable. In Windows, however, the drivers are only on board from Windows 8 and since around mid-2011, BLE has been available on Apple computers.
BLE continues to support a variety of peripheral devices such as heart rate monitors and toy helicopters, thermometers, fitness equipment and toothbrushes, yes, toothbrushes and sneakers.
Interesting in connection with iBeacons is the Sensor
Tag from Texas Instruments, which in addition to its function as an iBeacon can also measure temperature, humidity, pressure, and acceleration. The Sensor Tag also comes with a gyroscope, a magnetometer, and two hardware buttons. The ideal device to remotely control presentations while transmitting and displaying the moisture and temperature of the speaker’s hands. I think my next sandpit project will be stage fright-o-mat. You can find a detailed list of devices on the official Bluetooth website.
The communication model used by devices to exchange data is called the GATT – Generic Attribute Profile. GATT defines the roles of the client and server. The client requests data from the server via services. A service groups several atomic key/value pairs, which are called characteristics. Both services and characteristics are identified via UUIDs and can also contain further descriptions. Services and their characteristics are cataloged in the form of profiles; the specification defines a whole range of them from the fields of healthcare, sport and fitness and – in our case interesting – proximity sensing. The individual profiles and their services and characteristics can be found in the Bluetooth developer portal under GATT Specifications.
Get to the beacon
So what are iBeacons? iBeacon is a very simple technology (and a trademark of Apple that enables location-dependent interaction with applications. A beacon sends out a signal that can be received with BLE-compatible devices and processed by applications installed on it Signal contains the identification of the beacon and the reception strength. iBeacons themselves are, therefore – contrary to inaccurate statements in the press – unable to deliver content or track customer behavior. This is the responsibility of the receiving applications and therefore developers.
Larger deployments of iBeacons in Germany will probably be a long time coming, but there are some examples from the USA and the Netherlands. For example, Major League Baseball has equipped 28 stadiums with iBeacons and uses them, among other things, for check-ins in the MLB app “At the Ballpark”.
A showcase was implemented in the Rubens House in Antwerp, which offers background information such as X-rays of paintings and geocaching games for visitors.
The prime example in terms of size comes from Apple itself. Over 250 Apple Stores have been equipped with iBeacons. In combination with the Apple Store app, location-dependent messages are sent to buyers who are in the store. However, the possible interactions currently seem to be quite limited: First reviews report only two different (and quite generic) messages that they would have received. Special offers or specific information about individual products nearby were not offered.
iBeacon SDK does not use a separate BLE profile, but rather Bluetooth advertising packages, i.e. broadcast packages, which are used to discover Bluetooth devices. If you are interested in the exact structure of the package, you can read this, for example, on Adam Warski’s blog.
Such a package is sent at regular intervals that can be configured via GATT. It contains the UUID of the beacon, which is typically preconfigured by the manufacturer. So all MOKOSmart beacons send the same UUID. Major and minor IDs are also used to identify the individual beacons. Major IDs can represent, for example, a branch of a shop or a restaurant in a franchise chain, the minor IDs a single shelf or a table.
Furthermore, the signal strength is included in the advertising package, which can be used to measure the distance of the receiver from the beacon. However, you cannot expect high accuracy here, since the signal can be obstructed by spatial obstacles such as furniture or people.
IBeacon SDK offers two concepts for the interaction of an app with this information: ranging and region monitoring. When ranging, the distance to the beacon is determined. Due to the inaccuracy mentioned above, this takes place in only three stages. “Immediate” is a distance of a few centimeters, “Near” is a few meters and “Far” is a distance of over ten meters. Ranging is only possible if the receiving app is active.
This is not necessary for region monitoring. In this mode, an inactive app can also be notified when entering or leaving a region defined by one or more beacons. At the latest now it is becoming clear what makes this technology attractive for advertising and retail. In addition, for most beacons, the transmission strength and the interval can be configured in order to optimize the battery life based on local conditions.
“Most beacons” implies that there is more than one manufacturer of iBeacons on the market. In fact, there are quite a few: MOKOSmart, Kontakt.io, Gelo, Estimote, and Gimbal. In addition to the hardware, these manufacturers also offer iBeacon SDK service and cloud solutions for the management of beacons. The hobbyists among us can set up iBeacon transmitters themselves with relatively little effort using Raspberry Pi or Arduino.
Let us assume the following situation for the implementation example: The developer is in the supermarket on Saturday morning. Hungry children are waiting at home and in the afternoon there is a bake sale at school. Only then will the weekend really start. So good reasons to hurry up. Unfortunately, the shopping list is long and not adapted to the layout of the supermarket. If the supermarket were equipped with iBeacons in the different departments, a shopping list app could highlight the appropriate entries and significantly reduce the stress level of the (of course completely fictional) developer.
Since our app has to communicate with Bluetooth, we first require BLUETOOTH and BLUETOOTH_ADMIN authorizations in the Android manifest. In order to be able to use the service offered by the Estimote API to interact with iBeacons, we must also make it known and place the downloaded API in our libs/directory.
Our prototype consists of a simple, pre-filled list and pre-defined regions, i.e. departments in our supermarket. A list entry knows which region it is assigned to. In our example, we only assign one beacon to each region. It is also possible to combine a list of beacons into one region. The main activity is responsible for recognizing the current region and forwards this information to an adapter, which is responsible for highlighting the list entries. In addition, we add the option to select the active region without beacons to make our UI testable without additional hardware.
In the activity’s on Create method, we instantiate a Beacon Manager from MOKOSmart for our app. We use a listener for the region monitoring by making the current region known to our adapter and defining the interval for the beacon scans. In the example, we define that one second should be scanned and then 250 ms should wait. These values
The adapter is implemented as a derivative of android.widget.Array Adapter and overrides the get View () method, which is called for each line to be displayed. The title of the item is written in the first line of the review defined in the layout, in the second the assigned region.
As can be seen in Listing 1, the entered region is transferred to the adapter in the on Entered Region () callback of the MonitoringListener, which is assigned to our BeaconManager: item list Adapter. segregation (region). When calling getView (), this checks whether the region of the entry in the line matches the current region. If this is the case, it colors the background of the line. Additionally or alternatively, one could also put the entries for the current zone at the beginning by sorting the list.
The code of the application is clear; it doesn’t take many implementations effort to receive iBeacon signals and handle them in the app. The iBeacon concepts ranging and monitoring are mapped in the MOKOSmart iBeacon SDK so that they can be used intuitively. The full source code of the app can be found on GitHub.
Conclusion and outlook
We saw that interacting with iBeacons using the MOKOSmart iBeacon SDK is easy to do. So I don’t expect major hurdles in the technology of implementation, but rather in the deployment of the beacons and the tuning of transmission power. These parameters have a direct impact on the responsiveness of the application when the location changes. In any case, the balancing should be difficult.
For particularly interesting, e.g. B. in the area of
It remains to be seen whether the “Indoor Navigation” application area can be mapped robustly with this technology. Due to the susceptibility of the Bluetooth signal to interference factors, strong illumination with iBeacon signals of the corresponding area and position calculations using triangulation with room plans would be necessary. Appropriate solutions are offered by MOKOSmart (Indoor Navigation iBeacon SDK) and various other manufacturers such as LabWerk, but the author is not aware of any practical reports.
With the development of an app interacting with iBeacons, security and data protection aspects must also be taken into account. Due to the simplicity of the signal, iBeacon is prone to spoofing, which should not be forgotten during development. Data such as the current location and the movement profile that can be collected based on user behavior also have a high need for protection.
MOKOSMART iBeacon SDK