Category: Apps

iBeacon App Development Considerations

If you are considering writing apps to communicate with iBeacons, here are some high level things you need to think about that are specific to beacon app development:

  • Detecting whether Location and Bluetooth are on/off and alerting the user for permission to use these
  • Detecting beacons in background when the iOS app is closed or the Android app is in doze mode
  • On Android, taking account of the various Bluetooth APIs that exist for the different Android releases
  • Fetching data, associated with a beacon, from a service, such that it’s cached and not fetched every time
  • Arranging for some initial data bundled with the app so that it works straight away without a data connection
  • Fetching data before it is needed such that it’s available with no delay and when there’s no network connection
  • Re-fetching of data when it becomes stale
  • Fetching metadata from the server to control the behaviour of triggering
  • Arranging how Apple will test the app for app review otherwise complications will arise and the review will take weeks
  • Assessing whether to use the mobile OS or manufacturer supplied SDKs (or both)
  • If connecting to beacons, taking account of the unreliability of wireless connections
  • Collecting and uploading statistics/analytics to assess usage
  • Providing end user diagnostics to aid support troubleshooting

Need an experienced beacon app developer to get these things done quicker? Consider our development services.

App-Based Indoor Mobility Detection

The new paper titled A Mobile App-based Indoor Mobility Detection Approach using Bluetooth Signal Strength (PDF) by Muztaba Fuad, Anthony Smith and Debzani Deb from Winston-Salem State University, explores the development and application of a novel system for detecting indoor mobility patterns using the Bluetooth signal strength from mobile devices. This research is significant for its potential real-world applications, particularly in optimising indoor layouts for efficiency.

The research underscores the limitations of GPS in indoor settings, necessitating alternative localisation techniques such as Bluetooth for indoor mobility detection. The study is motivated by the potential efficiency improvements in industries like healthcare, where space optimisation can significantly enhance operational efficiency and patient care.

The approach uses a mobile application to collect Received Signal Strength Indicator (RSSI) data to determine paths taken by mobile devices within indoor spaces. The system comprises a vectorised algorithm for path determination, highlighting its low-cost and ease of implementation advantages. The methodology faced challenges related to software system creation, data collection and mobility detection. Despite these, the study demonstrates that Bluetooth RSSI data can effectively determine indoor paths with reasonable accuracy.

Experiments conducted in controlled indoor environments validated the system’s ability to detect mobility patterns accurately. Parameters such as data aggregation methods and normalisation significantly impacted the accuracy of detected paths. The study’s findings indicate that the proposed approach can effectively map indoor mobility without specialised hardware, relying solely on mobile devices and a custom application.

The authors conclude that while the system presents a promising solution for indoor mobility detection using Bluetooth RSSI, further research is necessary to improve accuracy and applicability in real-world scenarios. Future work will explore the impact of varying the number of stationary devices and the distance between them on detection accuracy. Additionally, real-world testing in clinical settings is planned to validate the approach’s effectiveness in operational environments.

Reverse Engineering iBeacon and Eddystone Bluetooth GATT Services

For some of our beacons such the manufacturers haven’t documented their Bluetooth Service Characteristics. This means that while they are ok for scanning/proximity type applications, you can’t write your own app to, for example, change programmatically the UUID, major and minor, transmit power, advertising period and must rely on the manufacturer’s configuration app. While this of no consequence for the majority of uses that set and forget settings, more ambitious scenarios might want directly access the Bluetooth GATT services to change settings.

Uri Shaked has a great article on Medium on how to Reverse Engineer a Bluetooth Lightbulb. His method uses the developer logging in Android 4.4 and later to allow inspection of the Bluetooth packets and hence the Bluetooth Services and Characteristics that are being used. This method can equally be used with iBeacon and Eddystone beacons to reverse engineer the Bluetooth GATT information.

Another method is to use a Bluetooth sniffer. This listens in on the Bluetooth communication between two devices. One way of doing this is with Nordic Semiconductor’s Sniffer software on a dongle. There’s a tutorial on JimmyIoT.

It’s usually ill-advised to reverse engineer interfaces to discover undocumented features because the manufacturer can change the implementation thus breaking your solution. However, it’s very rare that firmware is ever updated in beacons and when it is, it’s usually only to fix bugs rather than change the implementation.

Is it Possible To Use One App to Manage All Beacons?

There are lots of brands of iBeacon and Eddystone beacon. Each brand has its own management app. We have often been asked,

“Is it possible to have just one app to manage different brands of beacon?”

While it’s technically possible, there’s no incentive for anyone to create such an app. Creating just one app to manage one beacon brand, across iOS and Android is significant effort in itself.

Google identified this problem and created the Eddystone Configuration GATT Service. The idea is that if manufacturers used just this, apps and beacons would be inter-operable. However, people want to configure iBeacon as well as Eddystone. Manufacturers also want to allow users to configure and read sensor data. Also, using Eddystone Configuration GATT Service software in all future beacons does nothing to help manage the large number of beacons that are already out there.

As of writing this, in 7 years since Eddystone Configuration GATT Service was published, no apps have been published that work with the Eddystone Configuration GATT Service. However, the Nordic nRF Connect app does understand some of the Bluetooth Characteristics to better read these kinds of beacons. There hasn’t been a rush for manufacturers to use Eddystone Standard GATT.

Back to the question. It looks like there will be a separate app per manufacturer for the foreseeable future.

Who Controls Your Beacons?

One of our most popular FAQs is

“Which Beacons Don’t Require Registration/Login/Subscription to a Platform to Configure Them?”

Conversations with our customers are showing that people are starting to become wary of beacons that require online logins because:

  • They can’t be administered ‘in the field’ where there might be no connectivity
  • They can’t be easily used with other people’s platforms
  • They tie you into platform availability that you can’t control
  • They tie you into future changes of platform subscription model you can’t control

None of our beacons require you to register, login or subscribe to a proprietary platform to administer them. All can use stand-alone apps for configuration.

Why Doesn’t the Manufacturer’s Configuration App Connect?

When in typical use, it’s not necessary to connect to a beacon. A beacon just advertises and is detected by a smartphone or Bluetooth gateway. However, to initially set up a beacon you usually connect via a smartphone app. The 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.
  • Make sure you are using the correct password to connect. It’s not the password on the sticker which is the web site technical area password.
  • 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.

Starting Android iBeacon App Development

Here are some pointers how to go about Android beacon development:

  • The Android documentation is excellent.
  • Read the posts tagged Android on this blog.
  • 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.
  • The TI SensorTag library has some great examples of how to connect via GATT.
  • Nordic Semiconductor, the manufacturer of the System on a Chip (SoC) in most beacons, has useful libraries for scanning and connecting via GATT.
  • Take a look at the Bluetooth LE Wiki for links to more resources.

If you need more help we provide beacon app development services.

Caching Information in iOS and Android Beacon Apps

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.

Bluetooth Sleuth App

There’s a new app Bluetooth Sleut‪h by Sean McNeil for iPhone, iPad and Mac.

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.

Mobile Forms for Eddystone and iBeacons

We recently came across TracerPlus, a system that allows you to scan and collect Eddystone and iBeacon data into forms on iOS and Android.

A desktop application builder is used to design the forms:

The system can be used to efficiently take inventory and capture additional data from beacons for example, unique identifiers for items, battery life, temperature and URL information.

TracerPlus provides semi-custom mobile applications at a fraction of the cost of custom software.