Litum have a new article What is Bluetooth Low Energy (BLE)? How does BLE work? that’s higher level and less technical covering Bluetooth LE device discovery, differences to Classic Bluetooth, how positioning works, Bluetooth range , usecases and industries.
Many gadgets and IoT devices need to connect to the Internet via WiFi. The problem is getting the WiFi credentials to the device when it isn’t connected yet. It’s a ‘chicken and egg‘ situation in that you need to connect to the device in order to set the WiFi settings but you can’t connect because you aren’t WiFi connected.
The usual, but complex, way to solve this is for the device itself to initially act as a WiFi router in ‘station mode’ while the user on a phone, laptop or desktop connects and uses a web interface to set the WiFi settings and then reboot. After rebooting, it’s not in station mode and instead connects to the assigned access point. The assigned local network DHCP IP address isn’t known to the user so they have to examine router settings or use some other contrived method to work out the URL to further administer the device.
None of this is simple for most users so alternative mechanisms are preferable. We previously mentioned Android WiFi Direct via Bluetooth and now there’s a new open standard, Improv, for setting up Wi-Fi via Bluetooth LE.
For Improv, the client (web or mobile) application sends the Wi-Fi credentials to the gadget via a defined Bluetooth LE Service (00467768-6228-2272-4663-277478268000). The device connects to the WiFi and returns a URL on the network that can be used to further administer the device.
How it works
Under the hood, a Bluetooth Characteristic is used to send a RPC Command to set up the Wi-Fi settings.
We now have the INGICS iGS03E Bluetooth to Ethernet gateway in stock. This differs to the iGS02E in that it includes Power over Ethernet (PoE) without having to have an external PoE splitter.
Gateways look for Bluetooth LE devices and sends their advertising on to a server via TCP, HTTP(S) or MQTT including AWS IoT. If you use with sensor beacons, this provides a quick and easy way to provide for IoT sensing.
The iGS03E is one of the first gateways to also support Bluetooth 5 in Long Range mode (LE Coded PHY), although very few advertising devices support this yet.
The Bluetooth SIG has published a new Bluetooth Market Update (pdf) based on new research by ABI Research that assesses how the pandemic has affected the market for Bluetooth devices and provides forecasts for the coming years.
The pandemic has impacted device shipments but future annual device shipments are expected to be greater than before the pandemic. Location based services slowed by 25% compared to pre-pandemic 2020 forecasts due to the difficulty in traveling and installing equipment within facilities. Growth is expected to return to pre-pandemic levels throughout 2021, rising to 550,000 implementations by 2025.
When two or more wireless devices transmit on the same frequency, if the transmissions overlap in time then the signal is corrupted. Bluetooth reduces such collisions by using 40 different frequencies called channels. A technique called adaptive frequency hopping (AFH) allows Bluetooth devices to avoid channels that are noisy or busy.
Bluetooth channels used by two connected devices
Of the 40 channels defined for use by Bluetooth Low Energy (LE), 37 of these channels are available for use during connected communication.
Channels used for advertising and scanning (in green)
Of the 40 channels, 3 are used for (one way) advertising and 37 for (two way) connections. In the case of beacons, they spend most of the time advertising sequentially on channels 37, 38 and 39. Connections and hence AFH are only usually used when setting up the beacons using manufacturers’ apps.
Wake Up Radio (WUR) uses a very low power device that senses a radio signal to switch other devices, in this case a Bluetooth LE transmitter. A AS3930 WUR senses a signal in the range 110-150 kHz and switches a Texas Instruments Bluetooth CC2640R2 LaunchPad board.
The idea is that usually Bluetooth LE advertises every say 100ms to 1000ms and this is wasteful on battery power if the advertising is only needed for short periods of time. The paper assesses the feasibility of using WUR to turn advertising on and off to save battery power. While this is in in the context of wearables, the authors don’t mention much more regarding what might switch the beacons to advertise, other than:
The transmitter of this wake-up signal, which is usually a less restricted device, might be integrated with the communication infrastructure or deployed as an independent system element
The authors later mention healthcare so perhaps wearable beacons might only transmit when needed in particular areas.
It’s also mentioned that WUR can mitigate against the problem of interference when many Bluetooth devices advertise at the same time. This problem is rare and requires a very large number of devices. The authors later mention healthcare but this is unlikely to be a problem. A warehouse with thousands of assets might be a more realistic scenario. In this case, you could envisage wanting a Bluetooth beacon only transmitting when invited to do so.
The paper has some useful charts showing usual Bluetooth power use over time (without WUR):
You can see the periodic advertising which isn’t regular due to the 10ms long pseudo-random delay between advertisements. This is the part of the Bluetooth standard that helps ensure two device that collide usually don’t do so the next time they advertise. In between advertising, the power use a very low 0.3 µW.
The paper shows that energy consumption of the system as a function of the number of wake-ups in a period of time and the maximum application-level latency:
The paper concludes that the WUR approach can be more energy efficient when the desired latency for data delivery is below 2.11s. Even though the consumption of the WUR is low, it unfortunately exceeds the level of a BLE only system sleep mode by almost two orders of magnitude.
In our opinion the researchers are trying to improve on something that is already very low power. In between advertising, power use is extremely low. A CR2477 battery in a Bluetooth wearable can advertise periodically for up to 3 years. Also, for the wearable scenario, it’s more normal to use a low power accelerometer to only have the wearable transmit when moving. This way the battery lasts an extremely long time that’s limited more by the physical lifetime of the battery (5 to 10 years) rather than battery consumption.
The Bluetooth SIG has an infographic that depicts eight location-based usecases where Bluetooth can be used to create better visitor experiences and improve operational efficiency. It explains how smartphones are helping to drive rapid adoption of Bluetooth due to their inherent compatibility.
The usecases demonstrate some of the kinds of solutions we create at Beaconzone.
When connecting to Bluetooth devices such as beacons via GATT, APIs are used to connect to specific Bluetooth Services and Bluetooth Characteristics. Services and Characteristics are identified by 128-bit UUID values written as 00000000-0000-1000-0000-000000000000 where each digit is a hexadecimal number. For example, an app might connect to a Service with id D35B1000-E01C-9FAC-BA8D-7CE20BDBA0C6 and then read and write to a Characteristic with id D35B1001-E01C-9FAC-BA8D-7CE20BDBA0C6.
In practice, an interface usually uses similar UUIDs that only change in the xxxx part of the UUID: D35Bxxxx-E01C-9FAC-BA8D-7CE20BDBA0C6. There’s usually a base UUID such as D35B0000-E01C-9FAC-BA8D-7CE20BDBA0C6 and only 16-bits values are provided in the interface documented description.
Here’s an example from the Meeblue beacon documentation:
The Meeblue base UUID is D35B0000-E01C-9FAC-BA8D-7CE20BDBA0C6. When it’s said the UUID is 0x1000, the actual UUID is D35B1000-E01C-9FAC-BA8D-7CE20BDBA0C6.
Most use of Bluetooth LE and beacons only looks at the transmitted advertising containing identification and sensor information. More advanced use requires connection to the device using GATT to write, read and be notified of changes in values (Bluetooth Service Characteristics). The most common use for connecting is to set configurable settings as in the case of device manufacturer smartphone apps.
Some solutions need to manipulate Bluetooth Service Characteristics programmatically. Barry Byford has a new Pyton library BLE-GATT for Linux based devices. It’s based on the BlueZ D-Bus API, features a small number of dependencies and can be easily installed without sudo privileges.
It provides details on Bluetooth communication options and covers GAP, GATT and advertising. It shows how to work with Bluetooth Service Characteristics and use standard Bluetooth LE Profiles.
