We have had people ask how social distancing beacons such as distance bands differ to ordinary beacons. Normally, beacons send out (called advertising) Bluetooth signals that are received (called scanning) by apps on smartphones or Bluetooth gateways:
There’s no actual connection taking place. One side is repeatedly sending while the other is listening.
For social distancing, the beacons advertise AND scan:
Each beacon is repeatedly sending out an id and listening for others. Again, no connection takes place. When beacon receives scan data, it also sees the signal strength which can be used to infer the distance and hence whether the remote beacon is within the social distancing distance.
Beacons can store the id, signal strength and time. This can be extracted later via connection from another device such as a smartphone or gateway.
Nordic, the manufacturer of the System on a Chip (SoC) in many beacons, has published the latest issue of Wireless Quarter Magazine. It showcases the many uses of Nordic SoCs.
In the magazine you can find lots of new products using the same technology found in Bluetooth beacons:
Citizen Watch’s solar powered watch
Sphero RVR programmable robot
F5 Sports smart baseball
A wearable canine activity tracker that monitors pet exercise
An equine monitoring solution helping farmers monitor horses’ health
OmnIoT SoftHub is a way of creating IoT edge applications quickly without any programming. It runs on Raspberry Pi hardware (2, 3, 4, or Zero/W) and detects iBeacon, AltBeacon, and EddyStone beacons ‘out of the box’. The authors have told us they are interested in integrating other Bluetooth sensor types.
The platform allows sending of data to many 3rd party MQTT brokers. It logs data to internal or attached storage and can also decode data into a variety of data formats. Thresholds can be created to cause events, for example, sending alarm emails or SMS messages direct from the platform itself.
It’s free for personal use and one-off company projects. It only needs to be licensed if you are going to re-sell it as part of a solution.
Around the World, governments are advocating social distancing. Companies such as ourselves are offering tech-based solutions to warn about close contacts, as they happen. However, what is a safe distance?
Governments seem to recommend arbitrary distances, for example, China (1m), France (1m), Singapore (1m) through Australia (1.5m), Germany (1.5m), Greece (1.5m), Netherlands (1.5m) up to the United Kingdom (2m), Spain (2m) and Canada (2m). Countries are providing inconsistent guidelines. What do the various distances actually imply in terms of reducing the risk?
The risk of being infected is estimated to be 13% at less than 1m. Every extra metre of distance reduces the risk by half. 1m provides for a large reduction in infection but 2m is a much safer distance. 1.5m is a pragmatic option especially if other factors can be combined such as limiting the length of exposure, using of face protection or other contextual considerations. Neither distance, reducing length of exposure nor face masks provide complete protection from infection.
For tech based solutions it’s important to be able to fine tune the distance to governments’ advice and contextual considerations. It’s also important to be able to measure the length of exposure and filter out exposures that are so short as to pose negligible risk.
We now have the M52-ST social distancing beacon in stock.
The beacon led flashes when two people wearing this beacon come close to one another. Each beacon stores up to 34,304 close contacts that can be extracted using the supplied iOS and Android app.
The app also allows setting of the time two people have to be together, the alarm type (led and/or sound) and a whitelist of up to 45 devices. The transmit power and signal strength trigger value can also be changed to fine tune the trigger distance for different physical situations.
PunchThrough has a comprehensive new guide about using Bluetooth on Android. It explains the basics of Bluetooth, introduces the Android Bluetooth API and provides a guide how to scan for devices and connect to them using Bluetooth GATT.
It also covers bonding, thread-safety, queuing requests, background services and 3rd party libraries.
If you are developing using Node, there’s a Node.js module, node-beacon-scanner, that allows you to scan Bluetooth beacon packets and parse the packet data.
While Node tends to be associated with Linux, servers and hence web sites, Node can also be used on small single board computers such as the Raspberry Pi. Hence, this module provides an easy way to scan for Beacons and other Bluetooth devices.
The module supports iBeacon and Eddystone and outputs the MAC address, local name, transmit power level, RSSI and the iBeacon/Eddystone specific attributes.
A new version of Nordic Semiconductor’s Android BLE library has been released. Nordic is the manufacturer of the system on a chip (SoC) inside some Bluetooth devices. Connecting to these devices, as opposed to just scanning for their advertising data, can be very tricky and there are lots of different ways of doing things depending on the Android version and workarounds based on specific situations. Nordic’s Android library aims to solve these problems and claims it “makes working with Bluetooth LE on Android a pleasure”. The library uses standard Bluetooth and hence works for all Android Bluetooth development, not just Nordic’s devices.
The new Android BLE Library v2.2.0 adds GATT server support and tidies up the callback mechanism. GATT server is where the Android device itself can be connected to from another device as opposed to Android initiating the connection. Note that this library is all about Bluetooth GATT connections. Connections are rare in the BLE World as most information is obtained through non-connected scanning for Bluetooth advertising. Connections tend to be used for settings or where you need higher or larger throughput than advertising can provide.
Note that the library doesn’t include scanning which is required before you can connect. Nordic provides a separate scanning library.
Also be aware that these libraries are relatively large. When we used them they took us over the Android 64K method limit thus complicating development slightly. Also, the later versions have dependencies on AndroidX. Finally, while the libraries hide the complications of Android development, this can be good and bad. When problems happen, as they always do with Bluetooth GATT, if you didn’t write the workarounds in the first place, debugging and fixing can be difficult.
In a previous post we explained how the Received Signal Strength Indication (RSSI) can be used to infer distance. Contract tracing apps provided by governments and workplace social distancing solutions use the RSSI to detect close contact. This post explores some factors that affect how well such systems work.
With Bluetooth LE the sender repeatedly sends out a small amount of data, called advertising, that takes of the order of 1ms to send. The repeat time, called the advertising period, is typically every 100 milliseconds to 10 seconds depending on the application.
Battery power use over time showing the 1ms spikes
A 1ms transmission uses a lot of battery power so there’s a tradeoff between the advertising period and battery life.
The receiver listens, called scanning, for Bluetooth advertising. Again this is battery intensive so scanning devices typically only do so for a few seconds. If they need to listen for a long time then there’s a gap of a few seconds between successive scans.
It can be seen that because the sender isn’t always sending and the receiver isn’t always listening the two might not align to cause detection. The advertising period, the scanning time and the time between scans all combine to cause a tradeoff between battery life and the responsiveness of the detection. In extreme cases detection can take a very long time or not at all.
Applying this to iOS and Android, the mobile OS manufacturers have exercised some control over what’s possible with apps so as to protect battery life. iOS is the strictest and doesn’t allow apps to advertise unless they are in the foreground and shown on the screen. There is a trick to cause advertising to wake up an iOS app to advertise for a very short time. However, it leads to poor triggering performance and can affect battery life.
Android is more capable and up until recent versions of Android, apps could advertise and scan in foreground and background. More recently, Google has restricted background activity such that Bluetooth is only advertised for a short time after the app has closed. There’s an even larger limitation on Android in that some manufacturers kill apps that work in background.
All this isn’t good for contact tracing apps. As previously mentioned , Google and Apple have implemented a new API to allow contact tracing apps to work well on iOS and Android. Some Governments, such as ours in the UK, have currently gone their own way with apps that use existing APIs. Such aforementioned restrictions stop smartphones seeing each other thus severely reducing their effectiveness. The apps won’t work properly and will provide very limited benefit. It has even been suggested the system might even be dangerous as it might be provide a false sense of security. There is a report that early trials of the UK tracing app and privacy concerns have caused the UK government to re-think their approach and are investing in research into a second Google/Apple centric app in case there’s a need to quickly change direction.
For our workplace social distancing solution we avoided use of apps for close-contact advertising and scanning. Instead we use smartband-like devices so that we are in full control of how and when the devices advertise and scan.
While wearable beacons only usually advertise, our custom firmware in social distancing wristbands performs both advertising and scanning so that devices can mutually detect one another. The heavy battery use means we still have to make a compromise between the responsiveness of triggering and battery use but at least it’s under our control rather than dictated by Google and Apple.
Bluetooth LE can be used to infer distance as is being used in contact tracing and social distancing apps. This is performed from the receiving end using what’s called the Received Signal Strength Indication (RSSI). This is a number, in dBm units produced by the receiving Bluetooth hardware that gives the wireless signal strength.
[dBm stands for Decibel-milliwatt, a unit used to measure radio frequency (RF) power level. dB (without the ‘m’) measures the power of a signal as a function of its ratio to another standardized value and the m in ‘dBm’ indicates we are comparing relative to 1 mW of power.]
RSSI is a negative value where the more negative it is, the further away the Bluetooth device. Close devices are usually in the range -10 dBm to -30 dBm while devices at the limit of detection give values less than -90 dBm.
Our post on Testing if a Beacon is Working shows how to use the nRF Connect app to measure the RSSI of a Bluetooth device.
The relationship between RSSI and distance isn’t linear and also depends on electrical, physical and environmental factors. It also varies slightly, as ‘noise’, over time, even when things don’t move. The largest electrical factor is the transmission power. Physical factors include blocking and reflection.
Some Bluetooth advertising such as iBeacon includes a value, the measured power, in the advertising that can be used to take account of the fact that different beacons have different transmission power and hence different RSSI at the same distance. The measured power is usually the value of the power at 1m from the transmitter.
While there are equations and libraries that attempt to derive distance from RSSI, often the most accurate method is to measure the actual RSSI at various distances and use this calibration data with interpolation to get estimated distances.
