Bluetooth Mesh Solution Choices

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.

Read more about Bluetooth mesh on our web site.

New Bluetooth LE Python Module

One of the difficulties of developing Beacon applications on (usually Linux) single single board computers (SBCs) is the difficulty in programming Bluetooth LE. We previously gave a few pointers.

To make things much easier, there’s a new pure Python module python-hcipy written using only the Python standard library for interacting with the Bluetooth HCI.

“The primary benefit of using this module is the lack of having any dependency on: PyBluez Python & C based module, the bluetoothd service or D-Bus; this module just uses the standard Python socket API.”

It currently supports BLE Adapter controller and querying, advertising, GATT Client (Central role),GATT Server (Peripheral role) and scanning.

Bluetooth Mesh Design and Implementation

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.

Read more about Bluetooth mesh on our web site.

Analysing the Bluetooth LE 2.4GHz Spectrum

In most cases you can place your beacons and they ‘just work’. However, what if you suspect things aren’t working due to other devices using the same 2.4GHz radio spectrum? It’s possible to use specialist test equipment and spectrum analysers but these are very expensive.

A new, recent article by Mark Hughes describes Troubleshooting Tools for Your Next Bluetooth LE Project: Ubertooth and the Nordic nRF Sniffer.

It shows how to use inexpensive dongles on Mac, Linux, and Windows to intercept and analyse Bluetooth LE packets.

Nordic Beacons and the Bluetooth SIG Mesh

The same day we posted about the research paper on Bluetooth Mesh networks, the Bluetooth SIG happened to announce the public availability of their Bluetooth Mesh.

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.

Today, there’s a new article on the Nordic InfoCenter blog that explains, in simpler terms, how the Bluetooth mesh works and introduces the Nordic SDK.

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:

For beacons:

“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.

A Survey of Bluetooth Low Energy Mesh Networks

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.