iBeacon, Eddystone, Bluetooth, IoT sensor beacons, apps, platforms
We now sell Minew’s MBT01 and MVS01 Asset Tracking Beacons.
The MBT01 differs from most beacons in that it has a switch at the back that can be used to detect if the beacon has been removed from a surface. It advertises ‘normal’ (every 5 secs) or ‘tamper alarm’ (every 1 sec) depending on the status.
The MVS01 is unique in that it has a vibration sensor with five configurable sensitivity levels. It sends extra advertising when moved.
We now stock the Minew MBM01.
The MBM01 is special because it has a very long range of up to 600m. It also has a long battery life of up to 10 years provided by the included lithium battery. This beacon is also waterproof to IP67.
Moko, one of our manufacturers, has a new video showing two beacons being assembled in their factory.
Moko is one of the more innovative companies being the only one to have mixed Bluetooth and LoRWAN. Their LW003-B Bluetooth LoRaWAN Probe scans for beacons and reports detected beacons via LoRa.
This allows beacons to be detected in remote places, such as farm fields, where there’s no WiFi or Ethernet connectivity.
We now stock the Minew MBM02.
The MBM02 is special because it has a very long battery life of up to 10 years provided by the included 4000mAh lithium battery. This beacon is also waterproof to IP67 and has a very long range of up to 150m.
When a Bluetooth WiFi Gateway sends data to a server via HTTP, the gateway has to connect to the server to start a connection and then use that connection to send the data. The connection part starts a new TCP connection with handshaking. Starting a new connection every time data needs to be sent to the server uses network data and creates work for the server.
Some gateways such as the IGS01s have a ‘keep-alive’ setting that allows the connection to be re-used across HTTP requests. This reduces the amount of data used on metered networks such as cellular, reduces possibly metered data throughput at the server and also reduces server loading thus improving performance.
Having said all this, you should consider MQTT if you are really concerned about efficiency and performance.
As Bluetooth and WiFi both use the 2.4GHz band, is it possible that they can interfere with one another? John-Paul Little has a old post on Can iBeacon deployments cause WI-FI interference. The conclusion is no, it won’t, as there’s negligible overlap between the WiFi and Beacon frequencies:
The 2.4GHz band is split into smaller frequencies, called channels, such that more than one technology can share the same band.
Also, at the practical level, we have used WiFi and (many) Beacons together on many projects and we have never experienced a problem. Although still rare, it’s more likely that multiple Bluetooth devices can interfere.
INGICS, supplier of Bluetooth WiFi gateways and sensor beacons, has a new open source example. The BeaconLair code is implemented using Docker to simplify setup. Internally it uses Golang, Eclipse Mosquitto, InfluxDB and Grafana. The platform receives data from INGICS iGS03 BLE gateways and data from iBS sensor beacons.
The dashboard, using Grafana, provides gateways remote control, viewing of beacons and beacon sensor values.
It can be used to remotely control gateways including device OTA upgrade, changing of the RSSI filters and provides configuration using all supported telnet commands.
Most of the time, beacons transmit and the receiving software such as apps on iOS and Android or applications on single board computers (SBC) only read the advertising data. There’s no connection to the beacon. However, for programmatic setup of beacon parameters or accessing some sensor data, applications might need to connect via what’s known as Bluetooth GATT.
There’s an article on How to Work Properly With BT LE On Android. It provides some useful pointers such as not performing scanning and GATT connection simultaneously, avoiding auto-connect and not blocking GATT callbacks.
GATT can be unreliable on Android. While scanning for advertising data usually works very well, we have found that GATT connections fail all the time on about 5% of devices. This is due to poorly implemented OS Bluetooth software. This means beacon manufacturer-supplied configuration apps sometimes can’t connect. The only solution is to use a different phone (or the iOS version of the app on iPhone).
The primary consideration when siting beacons is the location. Beacons work best when there’s a line of sight. If the beacons are static and received by devices such as smartphones then the best position is higher up where they won’t be blocked. If the beacons are moving, the receiver, for example a gateway, is best placed overhead. When thinking about the location of static beacons, also consider camouflaging them or placing them out of reach so that they don’t become victim to theft.
Think about how you will attach the beacons. Many beacons come with a strong double sided 3M-branded tape. While this can work, the glue or underlying surface can fail in the long term due to the affects of heat and moisture. Also, it can be difficult to remove or replace a beacon in the shorter term without damaging the surface decoration.
Tidier methods include screwing to the surface or plastic tie fixing that can be more suitable for attaching to some types of structure.
Although batteries can last years, think about how how battery levels will be measured and the physical and IT processes needed to replace a beacon.
The ease of physical maintenance is also related to beacon location and how they have been attached.
Since the Covid pandemic, when many organisations needed to determine room occupancy, it has become more acceptable to use beacons for tracking people. For example, health is just one industry where tracking remains vital, for example tracking vulnerable patients and determining the location of care providers.
There’s an increasingly number of scenarios where beacons are being worn. In order to facilitate this we have a wearable category and also stock lanyards.