Author: Support

Value in the Mundane and the Internet of Diversity

As we previously mentioned, the IoT is a nebulous concept covering many specialist areas and industries. It’s more like an Internet of Diversity as opposed to an Internet of Things.

Take a simple usecase we came across at a recent IoT Meetup. A US company provides rodent control ‘as a service’, having thousands of traps over tens of mainly retail (food) sites. Every day, people go out and see which traps have caught rodents. This involves a huge amount of expensive manpower and vehicles. LORAWan, in this case, is being used with sensors on traps to allow only those traps needing attention having to be visited. This has led to a huge decrease in costs.

There are two observations. The first is that there’s value in what might initially seem to be mundane. The second is that this usecase is very different to many other diverse scenarios. There is no rat trap IoT solution you can buy off the shelf and it’s not cost effective for a 3rd party to develop and market one. Off the shelf RTLS solutions are unlikely to be suitable and even if they can collect the data, the dashboards and information aren’t applicable to this usecase.

We are already seeing that the IoT platforms that are most useful are those that are simple to change yet most flexible. Platforms need to be simple enough to customise for diverse usecases and yet be flexible enough to show data in a domain-specific way.

Troubleshooting iBeacon Background Triggering

We wrote last November on how iBeacon triggering on iOS 10 was unreliable on some phones. As of now, with iOS 10.2.1, iBeacon background triggering still isn’t reliable on all iOS 10 phones. Strangely it works on all iOS 9 phones. However, here are some things we have found that have helped:

  • Many beacons set the advertising period higher than Apple recommends to conserve battery. Try setting it to 100ms to see if it solves your problem. If so, gradually increase the advertising period to determine the ‘best’ value. We also have an article on Choosing an Advertising Interval.
  • We have found some phones don’t detect iBeacons at all, not even in foreground when the app is running. While it’s drastic, a reset of phone settings usually gets these phones working. ‘Reset All Settings’ will reset the phone and app settings but will keep your documents and apps. Go to Settings… General and select ‘Reset’. Select ‘Reset All Settings’. The phone will reboot. You will need to set up things like WiFi again as well as, importantly, Settings … Privacy … Location. Uninstall the beacon app that was misbehaving and re-install. ‘Ok’ all the permission prompts again.
  • iOS can only do so much when in background. If a lot of apps are also looking for beacons (regions) or your app has lots of regions, there might not be enough hardware acceleration slots to detect your beacon. To test this, uninstall other apps that might have registered beacon regions and/or reduce the number of regions being detected in your app.

UPDATE for iOS 11: This problem seems to have been fixed with iOS 11.0.3

Detecting Beacons on Linux Devices

Beacons don’t just work with smartphones. They can work with any other devices that have Bluetoooth LE. This includes Single Board Computers (SBCs) such as the Raspberry Pi 3 and new $10 Pi Zero W that include Bluetooth 4.1.

Pi zero Wireless

If you take a look at our article on Implementation Types, the smartphone app or gateway in each scenario could equally be a SBC.

For sensing and RTLS applications, the SBC can do additional pre-processing to extract and/or filter sensor data. It can also do post processing to aggregate data and/or reformat for specific IoT platforms. Another advantage of a SBC over a gateway is that data can be cached when WiFi or Internet connectivity isn’t available and queued for sending later so that the data isn’t lost.

The starting place for evaluating use of Linux-based SBCs is usually the command line hcitool. This can be used to scan for and connect to beacons and save data to a file. There’s also a script available to scan and decode advertising data.

Implementations usually use the Bluez library that can be programatically accessed via languages such as c, Python and Javascript (node.js).

Bluetooth 5 Beacon Implementation Tradeoffs

We previously wrote about Bluetooth 5 and beacons. Now that more technical articles are available, we have been looking deeper into Bluetooth 5 and and how it might affect beacons, particularly in terms of compatibility and battery life.

Bluetooth 5 achieves a greater range without necessarily using more battery power. How? There’s an informative article by Martin Woolley that explains how range is more to do with how far the radio signal reaches and is still intelligible as opposed to how far the signal reaches. With current Bluetooth 4, the signal is actually going further than the working range but there’s noise in the signal such that the data can’t be reliably read. Bluetooth 5 (optionally) adds extra information to the data to allow error correction to be performed. This allows the data to be intelligible at a longer range. There are various PHY ‘modes’ that Bluetooth 5 can use with different capabilities:

LE 1M is what we have at the moment and will provide backward compatibility. The new LE Coded modes add error correction at the expense of a lower data rate. The LE 2M provides twice the data rate but actually less range than with Bluetooth 4. It can be seen that the ‘headline’ of Bluetooth x4 range and x2 speed are mutually exclusive. Bluetooth 5 is better than Bluetooth 4 but you can’t have everything. Bluetooth implementations will need to choose whether range, or speed is important. As beacons transmit very little data and speed of that data isn’t that important, we expect new beacons to use the coded PHY modes.

However, what about compatibility? If beacons need to remain backward compatible with current Bluetooth 4 phones then they will need to transmit LE 1M. There will be a tradeoff between long range needs and compatibility with today’s phones. Some beacons might do timeslicing between long range Coded and LE 1M advertising with a consequent significant degradation of battery life.

Another aspect that will affect battery use is that Bluetooth 5 allows a maximum transmit power +20dBm rather than +10dBm as at present. However, as now, higher output power will be under user (initial configuration) control.

In terms of using the new, larger Bluetooth advertising data size, this will need the iBeacon and Eddystone specifications to evolve. This is reliant on work by Apple and Google. Larger data sizes imply longer transmission time, about x2 to x8 the current transmission time. Most current beacons transmit for about 1ms (1 millisecond) every 100ms to 1000ms. New beacons will transmit between 2ms and 8ms again every 100ms to 1000ms. The transmission time has a direct, almost linear, affect on battery use.

[As an aside, if a beacon uses use LE 2M, without the longer range, then the transmission time will be cut by about a half. As most beacons are expected to support the longer range, in most cases there’s going to be a corresponding increase in battery use.]

It can be seen that for ‘Beacons 2.0’, compromises will have to be made. There are tradeoffs between long range, high speed, legacy (today’s) phone compatibility and efficient battery use that mean no beacon will have all these desirable attributes. There’s likely to be an even larger range of beacons and/or configuration parameters that tradeoff range, speed, compatibility and battery life. This is likely to complicate evaluation and rollouts.

Beacon Trajectory Smoothing

The problem with using RSSI for detecting location is that raw data contains lots of noise. Also, this noise becomes more prevalent in the viewed data when location samples are taken less often. There’s a useful new article at InfoQ on Processing Streaming Human Trajectories with WSO2 CEP.

The idea uses Kalman filtering to smooth noisy human trajectories.

Before and after filtering

This method is particularly useful for large realtime IoT rollouts because it uses a very small memory resource, is very fast and the calculation is recursive, so new values can be processed as they arrive.

Machine Monitoring Using Bluetooth Beacon Sensors

There’s a new article at RFID Journal BLE Eavesdrops on Machine Health With Augury System that describes how Bluetooth LE sensors can be used to monitor machine health. Such systems can be used to detect when machines have been working, when they weren’t working and the ‘big data’ can sometimes be used to predict failure. Such events can trigger real-time alerts.

This scenario is an example of Beacon Proximity and Sensing for the Internet of Things (IoT). This isn’t limited to monitoring machines. It can be used to monitor people, animals, plants, stock assets or just about anything.

Beacon Compatibility

We previously wrote a lot about beacon compatibility where we concluded that phone compatibility is more of an issue than beacon compatibility and that you might choose an Apple MFi certified beacon if you wanted additional assurance. However, what does MFi mean?

Certified beacons meet Apple’s beacon specifications. There was a time that these specifications were secret and only available to MFi partners. However, these have since become available after you have ok’d an agreement. If you wish to view them, go to the iBeacon for Developers web page and click on Download Artwork and Specifications.

Chrome, Eddystone and the Omnibox

There are some posts on Twitter and articles talking about how Eddystone appearing in iOS Chrome’s Omnibox might transform proximity notification scenarios. So what is this and what does it look like?

This came about due to the Physical Web/Chrome teams experimenting with new ways to show Eddystone notifications:

At the moment, notifications appear at the end of the ‘Today’ view. They get a bit lost because you have to swipe down get the notifications, swipe left and then scroll to the bottom:

BeaconZone Eddystone notification at the bottom

Noone is going to see this unless they know it’s there and are trying very very hard. Even though Eddystone detection is designed to be ‘pull’ rather than ‘push’, it’s a bit too difficult to find local Physical Web beacons.

With Google’s experimental Omnibox implementation, beacons come up when you go to do a Chrome search. At the moment, to try it out you have to enable an experimental flag by visiting chrome://flags:

After you do this, local physical web beacons appear when you start a search:

It’s far more likely people will see this rather than the Chrome widget at the bottom of the notifications Today panel.

It’s unknown whether this will find it’s way into future versions of Chrome without having to set the flag or whether it might appear on Android. Android has more visible Eddystone detection as it’s built in Android itself (Play Services to be more specific) and appears near the top of the notifications panel.

UPDATE: As of October 2017, Google removed Eddystone detection from Chrome on iOS and Android. Only Android can provide notifications.

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.