There’s an informative video presentation on the Bluetooth SIG web site on Simplifying Multi-Vendor Mesh and Sensor Networks. It provides an introduction to Bluetooth mesh and explains the ways in which it can provide for Industrial IoT (IIoT).
To add to this, Bluetooth Mesh is suitable for use on the factory floor where the environment can be electrically noisy. Standard Bluetooth Mesh uses advertising on several channels rather than (GATT) connections so as to provide for more reliable communication in environments with wireless interference.
They have observed that the stability of the received Bluetooth signal strength RSSI depends on which Channel 37, 38 or 39 the signal is being received on. This is because the channels slightly overlap the WiFi channels and there can be other Bluetooth devices also using the same channels.
The method analyses the channels over time and chooses those it thinks has least interference and most stable RSSI. This reduces the positioning error by 0.2m, to 2.2m, at a distance of 3.6m.
The gist of the problem is that the ‘Always’ option for allowing the location-tracking permission has become ‘Allow Once’ with the ‘Always’ option being buried in iOS Settings. People who use location (and beacon) oriented apps, are likely to select the ‘Allow Once’ option and the app will only work correctly once. This will create extra support, customer confusion and general loss of customers. The anti-competitive part comes through Apple’s own in-built apps (currently) not having to live with these restrictions.
To mitigate against the problem we recommend app authors update their apps and online instructions to explain to users to at least initially select ‘Allow While Using App’ and possibly provide more detailed instructions how to set ‘Always’ in Settings.
Although the implementation is similar to SensorMesh™ and BeaconRTLS™ used together, their solution uses a proprietary mesh implementation and a proprietary data protocol. Consequently, their implementation suffers longer response time when used over longer physical distances. Their maximum inter-hop distance of 8 to 10 m also isn’t good due to non-optimal devices and non-optimal device positioning.
Tracker beacons are different from normal beacons in that they are designed to be connected to an app for the majority of the time. Normally beacons just advertise and aren’t connected except for setup or obtaining sensor data in realtime.
The F4 comes with iOS and Android SDKs that provide for bonding/pairing with a password, listening to events such as connecting, connected, disconnected, getting the MAC address and RSSI, ringing the tracker, receiving a button press event, receiving a notification n seconds after disconnect and disconnecting at a given distance (received signal power level, RSSI).
…affects basically all devices that “speak Bluetooth”
This isn’t true. The vulnerability relates to Bluetooth BR/EDR, so called ‘Classic Bluetooth’, and not Bluetooth LE. It isn’t found in beacons or other devices communicating via Bluetooth LE. It also isn’t found in Bluetooth mesh.
Manage beacons, buildings, zones and broadcast messages. The web interface shows staff activity and allows staff to be assigned to tasks. Staff can update task status and provide notes from their smartphones.
Silicon Labs have a useful web site, webinar and slides on “Benchmarking Bluetooth Mesh, Thread, and Zigbee Network Performance”.
The two main measures of performance are throughput, the rate data transfer that can be achieved (in bits per second) and latency, the time taken for data to cross the network.
With a typical implementation of 6+ hops, throughput converges to a similar order of magnitude for all the protocols:
In real use these protocols only support of the order of low thousands of bits (not bytes!) per sec and should therefore only be used for sending small amounts of data that don’t change very often.
For a small payload with 192 nodes, Zigbee has lowest latency and Bluetooth has greatest variation of latency of 20ms to 200ms:
For a larger payload, the Bluetooth latency has a larger range of up to 750ms:
Whether the variation of latency matters depends on your particular solution. Which technology is best depends on what you need to accomplish. For example, in a Bluetooth lighting scenario you might not want some lights to come on immediately and far ones to come on up to a second later. For sensing, the delay usually doesn’t matter.
You also need to consider other factors such as interoperability, scalability, security, reliability and ease of deployment. For example, Zigbee is less scalable and Silicon Labs recommends a maximum of seven hops otherwise the network becomes congested due to re-tries. Bluetooth has especially good interoperability because it is ubiquitous on smartphones and other devices. It also works reliably in industrial situations and has double encryption.
All protocols can be difficult to deploy due to the lack of off-the-shelf general solutions outside specific verticals such as lighting and home automation although our SensorMesh™ is a notable exception.