The highest ranking hub for IoT in India

Bluetooth Beacon Applications and Real World Developer Issues

By Mr Martin Woolley, Bluetooth Special Interest Group (SIG). Curated by Ahalya Mandana.
11.31K 0
Home » Blog » Bluetooth Beacon Applications and Real World Developer Issues

A beacon is a Bluetooth Low Energy (BLE) device that enables a business to provide certain location-based services to their customers. Beacons have an edge over GPS services – they do not require any kind of satellite, and they provide location services indoors and even underground. The basic process that is responsible for the functioning of beacons is known as ‘advertising’. In this process, the devices emit packets of data using Bluetooth low energy and other scanning devices nearby, such as smartphones that are in the vicinity, detect this data.

Types of beacons

There are a few types of beacons in the market. The original one, from Apple, is the iBeacon. It uses Bluetooth low energy proximity sensing technology to transmit a universally unique identifier (UUID). This UUID can be detected by a smartphone that has the required app installed on it. iBeacons come in various forms, such as Universal Serial Bus (USB) sticks and small coin cell devices. iBeacon has certain licensing requirements. To make iBeacon devices, a manufacturer license from Apple is needed, as well as a license requirement for the logo of iBeacon. There is an alternative to the iBeacon, known as AltBeacon, which was designed by Radius Networks a few years ago. It has been specifically designed to create an open market for beacon applications. It is free to use and anyone can implement beacons using their technology. Google has also brought out a beacon known as Eddystone. It is an open beacon format, and has an Apache Open License, which make it easy to work with. Google allows businesses to manage their beacons using the Proximity Beacon Application Programming Interface (API).

Advertising packets

The packets consist of 37 octets of data, out of which six octets are reserved for the device address. The 31 remaining octets are used to store data in the Beacon. The 31 octets are divided into fields that are referred to as Advertisement Data (AD) Types. The AD Types are structured data types, consisting of three parts: a length byte, a type indicator, and an associated value. A particular AD type that is used with beacons is the manufacturer data field. It provides a space in an advertising data packet for the manufacturer to fill in with data.

There is one restriction, however. There is a rule that the first two octets must contain the company ID, which is issued by the Bluetooth SIG. For example, iBeacon belongs to Apple, so the first two bytes of the manufacturer data field must contain Apple’s company identifier.

After the company ID, there is an iBeacon type value, followed by a length field. After that there is a UUID, which basically represents the company who owns the beacons. A good example of this is all the beacons in a particular shopping mall. They will all have the same UUID, since they are all owned by the same organisation. Then there are four other bytes, which are split into two parts: major and minor, which represent the location of the beacon. In the case of the shopping mall, the major part will represent the actual store in the mall, and the minor part will indicate which part of the store the beacon is located in.

At the end, there is a field called Tx Power. This parameter is used to estimate the distance of devices from the beacon. It assigns a reference value to the power that is measured at a distance of one metre from the beacon. Other distances can be calculated using this as a reference. AltBeacon is very similar to iBeacon, but instead of a terming the bytes as major and minor, it just allocates four bytes to the manufacturer to use in any way that they want.

How Eddystone is different from the rest

Eddystone beacons do not use a manufacturer data field. They use a service ID field instead. Services represent the tasks that the device can do, and there are certain identifiers for each beacon service.

They use these identifiers in their service ID field, and they are very useful while selecting and filtering beacons based on their function. There is a field that can store URLs (Uniform Resource Locators). There are also frame types that represent URLs. So, instead of designing an application that receives the packet, maps the ID it finds to a location, and then takes some action, a URL can be used. This means that a browser can process the advertising package.

There can be a general-purpose application that uses Bluetooth advertising packets and responds to them in the form of some action, if they have Eddystone URL advertising packets. Special applications need not be developed for this purpose. There is also another type of data that the beacon can advertise, which is known as TLM (telemetric data). This allows the beacon to advertise information about itself, such as its battery level. Information like this is very useful when it comes to managing tens of thousands of beacons at a time.

The image shows a beacon manufactured by Estimote that supports Eddystone.

The image shows a beacon manufactured by Estimote that supports Eddystone.

Developing the Application Programming Interface (API)

Android programming is object-oriented, and involves the use of classes. There are objects that are used for programming applications for beacons. An example of this is a Bluetooth LE scanner object. It is used to trigger scanning for advertising packets from an application. After the scanning is triggered, there will be callbacks, which will provide you with software objects that represent the devices that have been discovered. The callbacks indicate the devices that have been discovered in the environment. The application needs to check inside the advertising packet to determine if it’s a beacon or not.

An important task that needs to be performed by the application is to filter all the packets that it receives, as only the beacon-related packets are required.

Real world issues concerned with developing apps

All platforms have their own native application programming interfaces (APIs). However, one doesn’t always have to use them. There are a variety of APIs offered by beacon manufacturers to choose from, depending on one’s requirements.

The process of beacon advertising happens at certain intervals and for certain duration. The phone application has to scan in a way that is roughly synchronised with the advertising intervals. If the phone scans too often, it will reduce its battery life. On the other hand, if the phone does not scan fast enough, it will not be responsive enough and it will not detect the beacons properly.

The IDs that are advertised by beacons need to be mapped to real information. There are three ways to do this task. One method is to have hard-coded, static local data within the application. Another method that can be used, if there is good Internet connectivity, is a remote look-up to the cloud. Lastly, one can synchronise remote data to a local store, and perform local look-ups.

To calculate the distance of a beacon from a smartphone, a process known as distance sensor estimation is used. The smartphone uses the strength of the signal that it receives to perform a calculation known as path loss calculation, based on the reference transmission power value that is present inside the advertising packet.

There may be certain situations in which a beacon that has been detected by the smartphone during one scan, is no longer present during a later scan. This could be due to some obstruction like a pillar, or a wall, and does not mean that the distance between the smartphone and the beacon has actually increased. Certain environmental factors can also have an effect on the range of Bluetooth and hence can affect the way beacons are detected. Due to these factors, a method known as fuzzy tracking can be used, which only removes a beacon from the list of detected beacons on the smartphone, if it remains undetected for more than 30 seconds.

Once the beacon has been detected, some action needs to be taken. There are two actions that can be performed. The application can be designed to send the user some useful information. An example of this is a message regarding discounts on a particular product in a store. This message can be sent to the users when they are close to the discounted product. The other action that the application can be coded to perform is automatic processing in the background. This can help store owners by giving them information about which store areas are not visited by customers. However, the privacy of the customers needs to be kept in mind in this case.

Bluetooth Beacons are extremely useful in the retail industry.

Bluetooth Beacons are extremely useful in the retail industry.

Future applications of beacons

Bluetooth beacons can be used in multiple ways in the future. Smartwatches can be used along with beacons to provide updates to the user. Using a smartwatch would be more convenient than having to take out one’s smartphone every time there is a notification. When it comes to developing beacons, one can work with developer boards. It is advantageous to develop beacons using developer boards like Raspberry Pi and Arduino, because they allow designers to experiment with test scenarios. This is not an option with commercial beacons. In 2016, BLE beacons are set to become very widely used in hospitals, restaurants, industries, and airports.

The video for the conference program on ‘Bluetooth Beacon Applications and Real World Developer Issues’ at IEW 2016 can be found here:

[vimeo 156846605 w=640 h=360]

‘Bluetooth Beacon Applications and Real World Developer Issues’ at the India Electronics Week 2016.

Leave A Reply

Your email address will not be published.