Mouser has a free ezine called ‘Methods’ (pdf) that has in-depth articles on the latest advances in Bluetooth.
Steven Hegenderfer, Director of Developer Programs at Bluetooth SIG explains how Bluetooth 5 will enable design engineers to pioneer innovative solutions. Steven Keeping shows how Bluetooth has evolved and Barry Manz explains Bluetooth Mesh Networking and beacons.
Beacons are small computers with a complete System on a Chip (SoC). There are four main companies that manufacturer SoCs: TI, Dialog, NXP and Nordic. Nordic is the most popular SoC for use in beacons, mainly because of the lower (tool) license cost and ease for beacon manufacturers developing the software (actually called firmware) that runs in the beacons.
Nordic has a new free Wireless Quarter Magazine that showcases uses of Nordic SoCs in many types of device, not just beacons.
The magazine also has articles on how Nordic is the first to launch a Bluetooth mesh Software Development Kit, how Mesh strengthens Bluetooth wireless’ IoT credentials and explains Bluetooth 5’s advertising extensions. The article says of Bluetooth 5’s advertising extensions:
“Advertising extensions, periodic advertisements, and connectionless broadcast will have a major impact on beacons”
However, the article says:
“This won’t happen overnight because few current smartphones incorporate Bluetooth 5, but expect beacons to proliferate over the next several years as new smartphones are rolled out”
A beacon has many settings such as the mode (iBeacon, Eddystone), transmission (ids or URL), power and advertising period. These settings are set via the manufacture app. However, what happens if the beacon is switched off via a button on the side of the button? What happens if the battery is removed? What happens to the settings?
First of all, if you turn off a beacon via a side switch beacons don’t power down but instead go into a very low power sleep mode.
All beacons have a portion of non-volatile flash memory that can be used to save values even when the power is removed by taking out the battery or removing from a USB slot. This means for almost all beacons, removing the power doesn’t cause the beacon to lose its settings. We say ‘almost all’ because we have found one exception to be Sky beacons that while they retain settings when the side switch is pressed on/off, they don’t retain settings if the battery is removed. This is because the firmware (code) in the beacon isn’t saving settings to non-volatile memory.
One thing to be aware of is that the non-volatile memory can only be updated so many times before it stops working. The number of times is very large and isn’t of consequence unless you have your own app that is frequently programatically changing settings. However, for some specialist beacons, for example mesh beacons, internally saved data can and will change more often thus introducing the possibly that beacons can become ‘worn out’ if the software isn’t designed to reduce the frequency of changed saved data.
If you take a look at the recently announced Bluetooth SIG mesh, it’s described by three specifications with around 1000 pages! It took three years to create. So what’s the rationale that caused it to be so complex?
For some answers, take a look at Szymon Slupik’s personal blog. Szymon is the Chair Mesh Working Group at Bluetooth SIG and his posts give a fascinating insight into the thinking behind the Bluetooth SIG mesh.
“The Bluetooth Mesh requires a higher power consumption than traditional Bluetooth low energy applications, and unlike Bluetooth low energy Advertiser devices, active mesh devices cannot be run off coin-cell batteries for extended periods of time.”
Also, despite all the hype over Bluetooth mesh, TI (the other main SoC provider) don’t have an SDK yet and the Nordic SDK is still alpha:
“This is an experimental release for exploration of the BLE Mesh stack on the nRF5 device family. It is not intended for commercial use”
We have been playing with the Nordic mesh examples and while they work on Nordic’s developer kit hardware we have had ‘alpha’ difficulties getting the mesh working on real beacons. One observation is that the Bluetooth mesh needs more capable SoCs than are found in the majority of our beacons. As previously mentioned, battery life is a concern so USB beacons tend to be the best candidates. Another customer insight is that while it might seem convenient to put sensors into lights, most industrial uses require sensors to be much closer to what’s being sensed. In practice, they will probably not be part of the active mesh and instead sensor beacons will use the friendship feature. We will be providing Bluetooth mesh beacons once the SDK is release quality.
We have also been playing with FruityMesh that’s better suited to battery use and also works on lower spec SoCs. We already have it working on some of our beacons. We have been told by M-Way Solutions that FruityMesh is currently going through a large software update. Once this is completed, we hope to start providing FruityMesh beacons.
Aidoo talks of IoT being a technology searching for a meaningful problem people are willing to pay to solve. The important part is ‘pay’, as many initiatives such as smart cities require a thorough understanding of how these things might be financed. Also, for many IoT technology providers, there’s a tension between providing open, inter-operable systems and wanting to own the stack.
Aidoo provides an upbeat view of beacons. He thinks beacons are simple at the moment because phones/apps are more capable. As beacons become more used as components of IoT systems, there’s an opportunity for them to be more complex.
While Aidoo didn’t mention this, one example of beacons becoming more complex is the use of mesh networking.
Although much of the Beacon related PR at the moment is centred around the availability of the Bluetooth SIG Mesh there are other mesh solutions some of which were referenced in our previous post.
Two other mesh solutions that are catching our eye at the moment are Wirepas and Fruitymesh because they provide more at the application level.
Wirepas provides for remote monitoring and configuration of beacons allowing you to set things such as advertisement interval, transmit power, used channels and the beacon payload. It also allows monitoring of beacon battery levels and firmware update. The mesh supports enhanced beacon security to protect against beacon spoofing and piggybacking.
Fruitymesh is open source software provided by M-Way Solutions GmbH in Germany. It allows you to configure beacon advertising, set up Bluetooth scanning, perform I/O and report beacon status, all via the mesh.
What sets these two solutions apart from the Bluetooth SIG mesh is that they are more optimised for use on battery powered devices.
We hope to be supplying beacons with Bluetooth SIG mesh, Wirepas and Fruitymesh in the near future as no one solution is suitable for all scenarios.
Ericsson, who actively participated in the definition of the architecture and the development of the mesh profile specification, have a new article on Bluetooth mesh networking.
The article explains how the mesh network was designed and architected to provide for reliable throughput when there’s a large number of nodes. They also talk about a building automation usecase that they created to test the implementation.
There are lots of marketing articles saying what will be possible and at the other end of the scale, mesh networking specifications that explain how it works. However, to implement these things, we need something in between marketing and specs that works with real hardware.
As we mentioned in our previous article, Bluetooth LE mesh networks tend to leave the application layer to the developer. This is so that mesh network can be used in many scenarios in many vertical industries. However, what’s particularly interesting with the Nordic SDK is that they have implemented some of the application level:
“We have therefore created a Beacon API as part of the Mesh SDK to do concurrent Beaconing and mesh networking”
Taking a look at the part of the SDK for beacons, there’s an API to define the device as a beacon with an advertising payload and advertising interval. The payload is up to the developer. While this falls short of defining APIs for the iBeacon and Eddystone beacon types, it provides a baseline for manufacturers and 3rd party solution providers such as ourselves to create new beacon products and solutions.
There’s a new research paper by Seyed Mahdi Darroudi and Carles Gomez of Department of Network Engineering, Universitat Politècnica de Catalunya, Castelldefels 08860, Spain on Bluetooth Low Energy Mesh Networks: A Survey (pdf).
It gives a consolidated view of mesh Bluetooth LE networks. It explains how Bluetooth LE was originally designed for a star network topology with limited range. While Bluetooth 5 increases the range, there are still scenarios that require longer range which can be solved by networking devices into a mesh. The paper covers current standard, academic and proprietary mesh networks and discusses the merits of flooding-based vs routing-based solutions.
One omission is FruityMesh that isn’t discussed in the paper. Another omission is discussion of battery/power use. One of the main features of Bluetooth LE is low power. This comes about because devices only transmit for about 1ms every period, where a period is typically 100ms to 1s. Once devices have to talk to each other, the transmission time goes up with a consequent increase of battery power. In practice, battery driven mesh networks end up having high latency and/or very low data throughput in order to conserve power.
Another consideration is what goes on top of Bluetooth LE mesh networks. The application layer is often left to the developer. For example, facilities to manage meshes of iBeacon/Eddystone beacons don’t exist. The application level ends up being proprietary and complex.