Category: Android

Devices That Can See Beacons

When people think about beacons they often imagine them being detected in smartphone apps. This post explores other devices that can also see beacons allowing for different interaction possibilities and new scenarios.

Apps – Apps aren’t limited to just smartphone apps. You can run apps on TV boxes that run Android. Just make sure they have Bluetooth 4.3 or later.

Gateways – Gateways are small single pupose devices that look for beacons and send the information on via MQTT or REST (HTTP) to any server. This allows web servers to see beacons.

Desktops and Laptops – PC/Mac devices with built-in Bluetooth or dongles can see beacons.

Walky Talkies – Motorola manufacture the MOTOTRBO range of digital radios that can detect iBeacons and show their location on a map.

Raspberry Pi – This has Bluetooth and can be used to detect beacons.

AndroidThings – This special IOT version of Android can run apps that detect beacons and store and/or forward information to other devices.

Arduino – Arduino boards often have Bluetooth and can do things based on the presence of beacons.

Pixl.js – The manufacturer of the Puck.js also supplies a device with a screen that can detect and interact with beacons.

Single Board Computers (SBC) have an advantage over gateways in that data can be cached locally when there isn’t an Internet connection. They can also make decisions locally and send out alerts directly rather than having to rely on a server. This is so called ‘IoT Edge’ computing.

Bluetooth 5 in Smartphones

Last February we wrote about the progress of Bluetooth 5 in recent smartphones. A few months on and Nordic Semiconductor, the company that produces the System on a Chip (SoC) used in most beacons, has a new blog post on Bluetooth 5 in Smartphones and how we are about to experience a tipping point in support for Bluetooth 5.

The final observation from the article is:

Even if sticking to previous incarnations of Bluetooth may look like the right choice, the marketing power of Bluetooth 5, regardless of whether it’s needed or not, is likely to help companies differentiate products and increase sales.

This is true. Some companies currently claiming Bluetooth 5 support in products don’t actually use Bluetooth 5 yet but instead offer an upgrade path to Bluetooth 5.

Beacon Programming Examples

We have some new documentation for our AnkhMaway customers*. In the Ankhmaway Technical Area we have two new Android examples on:

We also have a new user guide for the iB001W rechargeable wrist beacon.

* Password protected – only available to customers who have purchased products.

One Beacon App – Many Uses

Many existing or new mobile apps can be made more immersive and hence improve retention through the use of beacons. Sometimes, app authors add beacon detection and suddenly realise their app is also useful to totally different usecases.

One such app is Tourist Chat which started out as a travel app to allow tourists to connect. The author recently started using the same app and server side to support exhibition events.  Many beacon apps are essentially the same. They detect beacons and match this up to information in a server-side CMS. The ‘use’ or scenario can be many things: for example travel, exhibitions, hotels, retail, galleries and museums.

If you are creating a beacon-driven app, take a moment to think how it might also be re-purposed for other types of user. You might find a new market and revenue stream with relatively little effort.

Bluetooth Scanning on Android Oreo

Successive Android versions have become increasingly strict on what goes on in background in order to save battery power. The usual way of scanning for beacons on Android is to have an Android Service that uses the Bluetooth API to scan for beacons every n seconds. From Android Oreo (8.0), this is no longer reliable as the OS has background limitations that kill the Service soon after the app UI has gone from the foreground.

Apps now have to use the BluetoothManager BluetoothLEScanner call that sets up a

“The scan results will be delivered via the PendingIntent. Use this method of scanning if your process is not always running and it should be started when scan results are available.”

Apps that target multiple Android versions need to support both the old and new mechanisms which complicates development (and support).

We offer development services should you need any further advice.

Android O Bluetooth 5 Device API Observations

Last March we took a closer look at Bluetooth 5 and concluded there are tradeoffs between long range, high speed, legacy (today’s) phone compatibility and efficient battery.

We are starting to see corresponding development APIs appear for devices that will detect Bluetooth 5 beacons. Android (O) has a new setPreferredPhy call that allows apps to choose the PHY modes mentioned in our previous article.

As expected, high speed and long range are mutually exclusive and if you want to remain compatible with older (current) beacons then you can’t have the high speed or long range. Long range and high speed are only supported if the hardware supports it which means old (current) smartphones won’t get Bluetooth 5 support through a software upgrade.

The availability of the Android API raises new questions. Our understanding is that PHY is a low level thing and that the Bluetooth hardware can only work in one PHY mode at a time. If so, what if an app changes the PHY? Does this switch for all apps? What are implications? For example, what if one app, for example an existing app, needs to use older beacons in compatibility mode while another app wants to use Bluetooth 5 long range beacons? Maybe we are wrong and the underlying Bluetooth 5 firmware somehow multi-tasks PHY modes? Finally, how does the app know the device is Bluetooth 5 capable? It remains to be seen how the fragmentation of capability and behaviour is going to be workable on a typical app. Will most apps end up defaulting to compatibility mode, the long range and high speed only being used for special cases (devices)? In any case, we can see it’s likely that Bluetooth 5 is going to complicate beacon app development.

28/6 UPDATE: In response to this post, Martin Woolley of the Bluetooth SIG answered all our questions! Hardware, hence Android O, can have several PHY modes active at the same time provided the underlying device supports this.

Google’s Proximity Beacon API

Most beacon platforms are fairly limited in that they are designed around retail marketing scenarios. If you are creating a non-retail marketing solution you might want to look into Google’s little publicised Proximity Beacon API. It allows you to register beacons and have arbitrary data, called attachments, associated with them. What’s more, it supports the registration of iBeacon as well as Eddystone beacons and you can use it free of charge.

The usual usecase is setup via Google’s console followed by update from apps detecting beacons. Android and iOS example are available.

It’s not always apps that are used to detect beacons. For example, you might have a single board computer such as the Raspberry Pi or Bluetooth-WiFi gateway detecting beacons and a web front end managing and monitoring the beacons. Google also provides example scripts that show how other entities can be used to register, list and filter beacons. Alternatively, other entities might even call these scripts.

The storing of arbitrary data allows the proximity Beacon API to be used for scenarios beyond retail marketing such as sensing with sensor beacons and real time locating (RTLS).

Beacon Locator Android App

A growing number of people are using beacons for personal use. Today, we added the Beacon Locator Android app to our Solutions Directory. It allows you to set up action types such as opening a URL, broadcasting an Android intent, starting an app, changing the sound profile and running tasks via Tasker in response to detecting or losing a beacon signal.

What’s especially interesting about this app is that it’s open source allowing you to extend it to a multitude of personal and business scenarios.

Using Beacons For a Library Tour

There’s an interesting article at code4lib on Creation of a Library Tour Application for Mobile Equipment using iBeacon Technology by Virginia Tech. It describes a project where a QR code driven library tour was updated to use beacons.

Some insights include how attractive beacons can become ‘lost’, the problem of replacing batteries, limited battery life due to the iOS requirement for beacons to advertise every 100ms and challenges physically fixing beacons.

As mentioned in our article on Choosing an Advertising Interval, it’s possible to set the advertising interval to between 300ms and 600ms while maintaining a reasonable detection time. Also, had the library chosen Android tablets they could have used a much longer advertising interval. 100ms is an artificial thing set by Apple for very quick detection on iOS devices. On Android, the scanning is more controllable,you can scan for longer and hence have beacons that advertise less often and have much longer battery life.