iBeacon, Eddystone, Bluetooth, IoT sensor beacons, apps, platforms
We have had enquiries whether beacons can be used on aircraft. While there’s no specific guidance on beacons from aviation authorities, beacons transmit the same radio signals to other Bluetooth devices such as the FitBit, Android Wear, Apple Watch and Bluetooth headphones. These devices are classed as Personal Electronic Devices (PED).
The use of PEDs depends on the airline. Both the FAA and EASA have guidelines for the use of PEDs. Smart Luggage is No Longer Allowed.
There’s a new 3rd party Android app that can be used to configure Wellcore beacons.
CliqTags Beacon Writer allows you to set UUID, major, minor, power, and the advertising interval. It can also be used to set a new password and reset the configuration to factory settings.
There’s a great new post on Medium on iPadlocks – The Magic of Activation Beacons by Geoff Elwood of Specialist Apps. Geoff talks about using Beacons to unlock information such as Adelaide Zoo education and career trails. This allows for differentiated learning that replaces “custom codes, logins or other bits of paper”. Different experiences can be provided to different groups.
In a different scenario Geoff describes how the Bendigo Heritage Trust switches beacons on/off to provide for content that synchronises with audio/visual content and the physical location of a moving tram.
At BeaconZone was have come across beacons switching content in two other scenarios. The first is at events where content on visual video walls is synchronised with different beacon advertising and hence different content. The other use is in digital signs in streets/shopping malls that change the beacon advertising in response to different advertising.
Steffen von Bünau of Kontakt.io has an interesting article on “Jobs to be done – Accuracy in Real Time Location Systems”. He asks:
Who will use the information and what is to be achieved with it?
He questions whether organisations need room level accuracy or location within a room.
As Steffan says, trilateration can be used for positioning within a room.
However, determining accurate location within a room is much harder and more expensive to achieve and needs fingerprinting. Fingerprinting involves going over the target area to sample beacon signal strengths that’s time consuming. It’s also the case that the more you tune these things, the easier it is that they can go out of tune when the environment changes. New or changed items in a room can easily change signal strength readings and cause the need for re-fingerprinting.
As Steffen says:
“Accuracy is an expensive vanity metric unless it is necessary to get the job done.”
Read more about beacons for RTLS and our BeaconRTLS platform.
Read about BluetoothLocationEngine™
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.
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:
UPDATE for iOS 11: This problem seems to have been fixed with iOS 11.0.3
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).
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.
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.
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.