An app might not connect for a number of reasons. Here are some tips:
Most beacons need to be put into ‘connectable’ mode. For example, for most AnkhMaway beacons this means tapping them sharply on a table until they ring – they remain connectable for 45 secs and once connected remain so until you have configured the beacon. For Axaet and Meeblue beacons they stay connectable for a few minutes after turning them on.
Make sure you are connecting to the correct beacon. This is especially important if you are seeing multiple Bluetooth devices in the list. For example, we had one customer who hadn’t removed the plastic battery slip and had been trying to connect to some other Bluetooth beacon/device.
Connecting, via what is a wireless interface, might not work first time. While most connections do happen first time, there can be radio interference and radio signal reflections that can cause the connection to fail. Some configuration apps re-try if the first connect fails while others don’t. Make sure you have tried a few times before concluding a particular scenario doesn’t work.
Some phones have a faulty Bluetooth beacon stack. That’s the Bluetooth software built into your phone. While you might be able to view the beacon, connecting to it to change settings uses more advanced functionality that’s sometimes faulty. Over time, we have discovered about 5% of our customers have such problems, more so on Android. It’s a much more common problem than a faulty beacon. You can isolate this possibility by trying a different phone and/or different phone OS type.
Don’t try connecting from more than one phone at a time. When connected, that phone has exclusive access to the beacon and other phones won’t be able to see the beacon and connect.
Try rebooting your phone to reset the internal Bluetooth software.
Try resetting the beacon by removing and replacing the battery (where possible). This isn’t the same as turning off via a button press which usually only puts the beacon into hibernation and doesn’t restart the device.
Some configuration apps have known bugs. Read the BeaconZone technical area for your particular beacon manufacturer where we document known problems and workarounds.
The beacon could be faulty. This is actually a very rare occurrence and you should initially be considering other more likely possibilities (above). You can isolate this possibility if you have another similar beacon. Please contact us for replacement if you conclude you have a faulty beacon.
Avoid the libraries produced by the beacon manufacturers. They tend to add little value, are usually poorly documented and aren’t changed when there are updates to underlying Android libraries. You can achieve everything with the Android APIs. The only exception is connecting via GATT to Sensoro beacons where the Service/Characteristic information isn’t publicly available and hence you have to use their SDK.
If you are developing a beacon app to receive unique iBeacon and Eddystone ids (as opposed to URLs), an area you should think about is caching text, images and other media.
Beacons transmit unique ids and these ids need to match up with information held elsewhere, not on the beacon, that determine what the app does and what’s displayed to the user. The problem is that in many scenarios the beacons have to be placed where the user is likely to have no or poor Internet connectivity. Poor connectivity can be as just as bad as no connectivity if larger size media such as images needs to be downloaded.
Your app and sometimes server design might need to take into account the caching of information. Some of this information can usually be bundled with the app at the time of install while information that needs to be up to date might need to be fetched ahead of time. In some cases, you might need to use a combination of the two with information bundled with the app being replaced as new information becomes available.
Here are the kinds of things you need to think about:
What information is included at the time of install. In the extreme case, where you think a large number of people will be foreign and roaming, this could be all your information.
Whether the bundled information needs to be updated at the time of install.
A server side mechanism to determine when information is out of date and needs to refreshed. Such mechanisms should prevent the same information from being downloaded more than once.
A client, app side mechanism to get notified of information updates.
Whether the information is updated in app background or under control of the user.
For optimal display of images, provision of different size images for different (screen) size devices.
Strategies to reduce client device resources (battery) and server stress. This might include grouping associated information that’s likely to have to be used together.
What the end user sees when information is being updated or not available yet.
If and how information eventually gets purged to save space.
A alternative to complex caching schemes is to provide free on-site WiFi. This is particularly suitable for indoor visitor spaces such as museums and galleries. This way the app can be less complex and data fetched as needed. However, remember there will always be some people who, for security reasons, won’t connect to public WiFi.
The app scans for advertising devices, optionally with a specific CoreBluetooth UUID, and displays them including RSSI (signal strength). It can connect to devices that are connectable and then browse device the Bluetooth Services and Characteristics. For iBeacons, it’s also possible to observe region updates for specified beacons.
The app monitors and graphs recent RSSI values. You can also set up your device to advertise iBeacon or custom services with custom Bluetooth Characteristics.
There’s a new app for iOS called Stepping In & Out that uses iBeacons to remind you when you move into or out of an area containing a beacon.
The source code is available on GitHub. It provides an example how to create an app using Swift that triggers when going into and out of zones. This can also be used for commercially oriented applications.
Flutter is Google’s UI toolkit for building native applications for mobile, web, and desktop from a single codebase. There are plugins that add functionality to Flutter. One such plugin is the beacon_plugin that makes it easier to scan and range iBeacons on iOS and Android. The plugin is open source on GitHub.
A new version of Nordic Semiconductor’s Android BLE library has been released. Nordic is the manufacturer of the system on a chip (SoC) inside some Bluetooth devices. Connecting to these devices, as opposed to just scanning for their advertising data, can be very tricky and there are lots of different ways of doing things depending on the Android version and workarounds based on specific situations. Nordic’s Android library aims to solve these problems and claims it “makes working with Bluetooth LE on Android a pleasure”. The library uses standard Bluetooth and hence works for all Android Bluetooth development, not just Nordic’s devices.
The new Android BLE Library v2.2.0 adds GATT server support and tidies up the callback mechanism. GATT server is where the Android device itself can be connected to from another device as opposed to Android initiating the connection. Note that this library is all about Bluetooth GATT connections. Connections are rare in the BLE World as most information is obtained through non-connected scanning for Bluetooth advertising. Connections tend to be used for settings or where you need higher or larger throughput than advertising can provide.
Note that the library doesn’t include scanning which is required before you can connect. Nordic provides a separate scanning library.
Also be aware that these libraries are relatively large. When we used them they took us over the Android 64K method limit thus complicating development slightly. Also, the later versions have dependencies on AndroidX. Finally, while the libraries hide the complications of Android development, this can be good and bad. When problems happen, as they always do with Bluetooth GATT, if you didn’t write the workarounds in the first place, debugging and fixing can be difficult.
However, the iOS and Android mechanisms are still there for more worthy applications such as visitor space usecases that need to provide location based information. For these types of application, there’s the need for good app onboarding explaining location and Bluetooth usage in order to provide the location-based information that the end-user is requiring.
There’s a new article at Bluetooth.com that explains how to capture Bluetooth packets on iOS. The PacketLogger can decode all protocols defined by the Bluetooth Special Interest Group (SIG) and Apple, perform filtering, automatically highlight problems and search and export data.
This will work for both Core Location and Core Bluetooth. Core Location is using the iBeacon APIs while the lower level Core Bluetooth allows scanning and connection to any Bluetooth LE devices, not just beacons. It’s best to use the Core Location APIs and only use Core Bluetooth for more involved scenarios not supported by Core Location.
Note that Core Bluetooth, even though it’s lower level, can’t scan the iBeacon UUD, major and minor. Apple hides these values to force you to use Core Location.