The Bluetooth SIG, who create the specifications for Bluetooth, have a new Bluetooth Range Estimator that takes into account the environment, transmit power, antenna gain and received gain to provide an estimated range.
The paper explains mesh topologies and routing protocols. It describes Bluetooth:
“BLE is presently raising more and more attention and is becoming one of the leading technologies for both IoT-oriented and industrial scenarios”
The authors provide an in-depth introduction to SIG Bluetooth Mesh. (Note that an excellent higher level overview also very recently became available from InsightSIP). The research paper also mentions other Bluetooth mesh implementations such as the draft IETF Bluetooth Mesh for IPv6.
Applications such as smart city, industrial monitoring and smart agriculture are considered and factors such as interoperability and security are mentioned. Finally, the paper compares other protocols such as Thread, ZigBee and LoRaWAN.
The first question is why you might want to send your own advertising. Using the iBeacon or Eddystone protocol is sufficient in the majority of cases where you just want to a unique id at the Bluetooth LE receiver (usually but not always an app or gateway). The most common case of custom advertising is sensor beacons that need to send their own sensor data.
Nevertheless, some projects use custom advertising that signifies something extra other than a unique id. This is project specific and might, for example, indicate something about location, asset or person. Very few beacons support custom advertising without full re-programming (as opposed to setup). Re-programming involves replacing the SoC firmware and is a significant undertaking. Some of the AnkhMaway beacons support setup of a custom channel that can contain any data.
There’s a new insightful article at IHS Markit on Convergence of Wireless IoT Connectivity where it’s said that it’s unlikely that wireless IoT connectivity will be dominated by a one protocol or standard. While that might seem obvious, what’s less obvious is that, increasingly, multiple protocols are being used for IoT solutions.
The article observes:
“Almost all major chipset vendors such as Qualcomm, Cypress, Texas Instruments and Redpine Signals are offering wireless ICs with multi-protocol wireless connectivity allowing interoperability between wireless protocol and standards”
“It is most likely that these connectivity standards will increasingly work together to complement each other meeting the demands of IoT.”
Our SensorLoRa™ is one such solution, that combines the best of Bluetooth and LoRa.
There’s a growing number of operating systems for microcontrollers on single board computers, most of which can scan for Bluetooth LE devices such as beacons and connect to them via GATT for setup and extraction of data. Zerynth is now one such OS that you can program using Python. Zerynth r2.2.0 update allows use of Bluetooth LE.
Haltian has a useful IoT protocols comparison. It provides a comparison of TE Cat 1, LTE Cat M1, EC-GSM-IoT, NB-Io, Zigbee, SigFox, LoRa, Google Thread, Bluetooth LE and Wirepas Mesh.
Haltian say “It’s is a question of selecting the best-suited option for each use-case at hand”. One thing they don’t say is that the protocols are not mutually exclusive. For example, it’s increasingly the case that more than one protocol is used, one for short on-site distances and another for intra-site communication. WiFi/Ethernet also aren’t mentioned which are often a component of IoT solutions.
Bluetooth LE works at 2.4GHz, the same frequency used for WiFi and microwave ovens! There are two main types of Bluetooth LE transmission: advertising where the device only sends out data and connection-orientated using Generic Attributes (GATT) .
Bluetooth LE uses frequency hopping for increased reliability when there might be noise on a particular channel. When advertising, it uses channels 37, 37 and 39. If subsequently connected, it uses other channels:
When only advertising, the transmission is very short of the order of 1 or 2 milliseconds. In between advertising, there is no transmission which is one of the main reasons why Bluetooth LE has very low power use:
The paper explains how the Bluetooth Mesh Standard came about to address the problem of the variety of BLE meshing solutions that were not interoperable. It includes a great introduction to Bluetooth LE and Mesh with some statistical and experimental insights into mesh performance.
The authors explain how the choice of the use of advertising advertising at 100% duty cycle for lower end-to-end delay has degraded the low energy advantage of BLE advertising thus limiting the usefulness in power (battery) sensitive applications.
The paper contains some useful insights:
The back off mechanism, used to decrease the chance of mesh network collisions, contributes most to the communication delay. However, as they identify, it’s this mechanism that provides reliability and scalability in larger networks. Disabling the backoff mechanism decreases the delay but makes the network less scaleable and robust.
Making the network more dense, has a positive effect on the round trip time (RTT). However too a dense network leads to more collisions.
Increasing the number of hops needed, making the network more sparse, has a negative effect on the RTT.
“It is clear that there are a lot of factors inﬂuencing the communication ﬂows within a Bluetooth Mesh network, requiring more advanced management mechanism for optimizing the performance of the mesh network.”
However, the research had some limitations. Noise was simulated by introducing non-mesh beacons advertising every 20ms. This wasn’t very realistic given that most beacons advertise in the range 100ms to 1000ms. Re-transmit time was considered that complicated calculations – especially as re-transmit is application specific. It wasn’t mentioned that in many mesh sensing applications, unacknowledged messages are acceptable such that there’s no re-transmit. Also, the affect of other mesh network traffic, on the round trip time, wasn’t considered – only one mesh transmission at a time was considered.