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.
Nordic Semiconductor, the manufacturer of the System on a Chip (SoC) in many beacons, has published the latest online issue of Wireless Quarter Magazine. It showcases the many uses of Nordic SoCs.
The latest issue of the magazine highlights the increasing use of IoT. Nordic Semiconductor has been known for enabling Bluetooth and cellular solutions and with their recent acquisition of Imagination Technologies this now extends to WiFi.
The magazine covers many usecases including:
Bluetooth connected prosthetics
CHIP smart home
Smart health
There’s also an informative article exploring the usefulness of patents.
There’s a new informative paper by Martin Woolley of the Bluetooth SIG on How Bluetooth® Technology Makes Wireless Communication Reliable. It describes in detail how radio collisions, multi-path propagation, time-dispersion, transmitter-receiver synchronisation, signal strength, receiver sensitivity and buffer overflow can collude to make radio communications unreliable.
The paper explains how Bluetooth modulation schemes, CRC checks, multiple channels, coded PHY, adaptive frequency hopping, flow control and the ATT protocol work to make Bluetooth LE reliable.
The paper also takes a look how Bluetooth Mesh has been designed to achieve reliable communication.
Bluetooth devices such as beacons periodically advertise data according to a pre-defined format such as iBeacon or Eddystone. The advertising is very short, of the order of 1ms. Listening devices such as apps or gateways scan for a defined time, the scan window, periodically every scan interval. The scanning scan window is usually less than the scan interval to conserve power because scanning is power intensive.
While scanning nearly always sees a nearby device, there can be times when it isn’t seen due to physical and technical reasons. Radio signals can get blocked and reflected in ways that cause them not to be received. Also, if two Bluetooth devices happen to advertise at the same time then the received radio signal is corrupted. It’s also possible that because scans stop and start, the advertising happens when the scan isn’t running.
In practice the chance of non-detection happening is small. The chances of it happening again, the next scan, are very unlikely. If a beacon isn’t seen on the first scan it’s usually seen on the second (or third) attempt.
Bluetooth has some mitigations to help reduce the occurrence of the above mentioned situations. The advertising and scanning happens on multiple channels (frequencies) 37, 38 and 39 to reduce the affect of interference from other devices. Also, the advertising interval isn’t fixed and varies by a random amount, the advertising delay, for up to 10ms, to prevent two (or more) devices’ advertising continually colliding.
The consequence of scanning possibly not seeing beacons (the first time) is that solutions using apps or gateways must not rely on only one scan to make decisions on the absence of a beacon.
Martin Woolley of the Bluetooth SIG was a recent speaker at Droidcon EMEA where he spoke about Advanced Bluetooth for Android Developers (slides).
Martin covered scanning, GATT, how to maximise data rates, speed vs reliability and using different PHY for enhanced range or data rates. The second part of the talk covers Bluetooth Mesh and proxy nodes.
One thing not mentioned in the slides, to be careful of, is that connection via a proxy node is relatively slow because it’s limited by the GATT connection. Proxy nodes are good for controlling (sending small amounts of data into) a Bluetooth Mesh but poor if you want to use the connected Android device as a gateway for all outgoing data.
Martin also has a blog where you can also learn about his past talks and he will be part of the new Bluetooth Developer Meetup.
