Some platform providers claim beacons can transmit multimedia data which isn’t strictly true. A beacon sends a small amount of data that typically contains a unique id. When an app sees an id it shows information, such as an image, that is typically obtained from a server.
But what about beacons actually transmitting images? Chong Shao, Shahriar Nirjon, Jan-Michael Frahm or the Department of Computer Science, University of North Carolina has a paper on “Years-Long Binary Image Broadcast using Bluetooth Low Energy Beacons” (pdf). Again, don’t be misled, they don’t mean it takes years to send an image but instead that a beacon might transmit for a long time (which most do).
The researchers have found that with suitable compression schemes, a set of 2–3 beacons is capable of broadcasting high-quality images (75%–90% structurally similar to original images). The image quality improves when more beacons are used.
How might you get the data into a beacon? Well, some beacons such as the M52 Plus and iB003N allow arbitrary data to be set in the advertising data.
The images are necessarily very simple but nevertheless this provides a great example of what can be achieved when you attempt the seemingly impossible.
BLE applications can be found in a wide range of domains, e.g., smart home, smart cities, smart health, smart agriculture, or Industry 4.0. BLE is enabling the interaction between humans and smart objects, as well as between smart objects themselves. BLE has also been leveraged for innovative location-based applications, opportunistic data collection and crowd-sensing.
All the papers are available free of charge under open access:
The signal level and interference vary change depending on the position of the sender and receiver. They also vary depending on the surrounding environment. The signal level (RSS) is affected by reflection, shielding, and diffraction by surrounding objects, walls and the ground. Instead, testing requires known signal level and interference values.
The paper describes a software-implemented BLE controller, BluMoon, that calculates the received signal strength for each frame and imitates radio interference. The emulator replaces the controller with the HCI as the boundary.
BluMoon performs BLE communication emulation frame by frame and is implemented on Linux using the BlueZ Bluetooth stack.
In most cases, it’s possible to use beacons without knowing the exact data format of the advertising. It’s usually possible to specify only a few values such as iBeacon UUID, major and minor and the devices and listening apps work together. In some instances it’s necessary to know Bluetooth LE packets formats, for example, to implement your own code.
The Bluetooth packet formats are defined by the Bluetooth specifications but specifications aren’t always the fastest and easiest to understand. There’s a new presentation on SlideShare on Bluetooth Low Energy (BLE) Packet formats.
Winfred Lu from STMicroelectronics describes Link layer, advertising, data channel and physical channel packets.
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.
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.
Of the 40 channels defined for use by Bluetooth Low Energy (LE), 37 of these channels are available for use during connected communication.
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.