iBeacon, Eddystone, Bluetooth, IoT sensor beacons, apps, platforms
The short answer is no, iBeacons cannot directly send users to a website. iBeacons do not have the capability to push content or URLs to devices automatically.
Instead, they rely on apps to detect their presence and take appropriate actions which can include sending the user to a web site. The app has to already be on the smartphone.
There used to be a mechanism in Android that used the Eddystone-URL advertising format but this has since been discontinued by Google.
A new study develops a safety system that uses Bluetooth Low Energy (BLE) beacons to detect when a child boards or leaves a school transport vehicle. Each child carries a small BLE beacon, while the teacher’s smartphone or tablet continuously scans for its signal. The system uses the beacon’s unique address to identify the child and then sends the boarding or alighting status to the parent’s phone through a push notification.
The beacon is used mainly as a proximity sensor rather than for precise positioning. The system measures RSSI, which represents the strength of the Bluetooth signal received by the teacher’s device. A stronger signal generally means the beacon is closer, while a weaker signal suggests it is further away. Because RSSI can fluctuate due to distance, vehicle layout, obstacles and orientation, the researchers do not rely on a single signal-strength threshold. Instead, they analyse ten recent RSSI readings and calculate the average, trend and variance. A lightweight logistic-regression model then decides whether the child has boarded or left the vehicle.
The system was tested in three vehicle sizes. A conventional fixed RSSI threshold worked well within about four metres, but accuracy declined at longer distances. The machine-learning approach improved accuracy from 88% to 94% at 4–5 metres and from 76% to 87% beyond five metres.
Overall, the research shows how simple, low-cost BLE beacons can be used for automatic boarding and alighting detection without modifying the vehicle or requiring the child or teacher to scan or press anything. The main limitation is that Bluetooth signal strength becomes less reliable over longer distances, so vehicle-specific calibration is still required.
We sometimes get asked how many connections an iBeacon can support? The answer is ‘1’ but it’s often the right answer to the wrong intended question! The intended question is usually “How many receivers can see a beacon?”
Beacons don’t usually connect. They just advertise and can be seen by a very large number of receivers that include phones, gateways or single board computers such as the Raspberry Pi. The beacon doesn’t even know the receivers are there.
The receivers only usually connect once, during setup via an app, to set the initial beacon parameters. When connected, the beacon doesn’t advertise which prevents extra receivers from connecting. Once set up, the app disconnects and the beacon starts advertising again.
In some extreme situations, radio congestion can affect how many receivers can see a beacon.
We often get asked the question which beacons are compatible with iOS and Android. All beacons, whether iBeacon, Eddystone or sensor beacons can be used with iOS and Android. The compatibility is achieved through the implementation of common Bluetooth standards on these mobile platforms.
However, there are some caveats:
Rather than beacons being compatible with iOS/Android, we find that there are more problems with particular Android devices not seeing beacons, when in background, due to some manufacturers killing background services.
A new paper, Stochastic and functional modeling of RSSI measurements for accurate distance estimation in Bluetooth Low Energy–based indoor positioning, proposes a more statistically rigorous way of using Bluetooth Low Energy (BLE) signal strength to estimate distance. Its main argument is that Received Signal Strength Indicator (RSSI) measurements should not be treated as independent, random observations. Instead, RSSI errors are temporally correlated, or “coloured noise”, and this correlation needs to be modelled if reliable distances and uncertainty estimates are required.
The authors combine two types of modelling. First, they perform stochastic modelling to describe the behaviour of RSSI noise. Outliers are removed using a median filter, then the autocorrelation function (ACF) and partial autocorrelation function (PACF) are used to examine how successive RSSI observations depend on one another. These analyses indicate that an AR(2), or second-order autoregressive, process provides an appropriate model. The resulting covariance structure is then incorporated into Least Squares Variance Component Estimation (LS-VCE), which estimates realistic variances and measurement weights. Secondly, a functional RSSI–distance model is fitted using Best Linear Unbiased Estimation (BLUE), estimating both the environmental path-loss factor and beacon transmission-power parameter along with their uncertainties.
The experiment used two Tatwah BLE beacons, the IT002 and IT008, with a Samsung Galaxy S22+ as the receiver. RSSI measurements were collected for 20 minutes at 0.5 Hz at fixed separations of 1, 3, 5 and 10 metres. Importantly, the tests were carried out in a controlled outdoor environment rather than a normal indoor environment so that interference and multipath effects could be minimised and the intrinsic RSSI behaviour studied more cleanly.
The results strongly support the authors’ claim that RSSI noise is not white noise. Also, more distant measurements should receive less weight during model calibration.
The paper’s main contribution is not a new positioning algorithm itself, but a better statistical foundation for RSSI-based ranging. Instead of simply smoothing RSSI and fitting a distance equation, it explicitly models temporal correlation, calculates realistic measurement weights and uncertainty, and then estimates the RSSI–distance relationship. The authors conclude that this produces more statistically consistent calibration and more reliable BLE distance estimates.
The paper, Advanced Algorithms for the Three-Dimensional Beacon Placement Problem Based on Constraint Programming, Large Neighborhood Search, and Evolutionary Methods, investigates how Bluetooth Low Energy (BLE) beacons can be positioned efficiently throughout large, multi-storey buildings. The aim is to minimise the number of beacons, and therefore installation and maintenance costs, while ensuring that every relevant indoor position is covered by at least three beacons so that trilateration can be used reliably.
The problem is challenging because beacon signals are affected by the three-dimensional structure of a building, including walls, ceilings, their thicknesses and their materials. The authors therefore use an RSSI-based signal model that represents different levels of signal resistance for open space, drywall, solid walls and glass. Building layouts are discretised into spatial cells, with the model calculating which areas each possible beacon position can cover. The optimisation must achieve triple coverage while also maintaining sufficient separation between beacons and minimising the total number deployed.
The paper compares three main families of optimisation techniques. Constraint Programming formulates beacon placement as a Constraint Optimisation Problem and can theoretically identify globally optimal solutions, but the search space becomes extremely large in three dimensions. Large Neighborhood Search (LNS) instead starts with a feasible placement and repeatedly removes and replaces groups of beacons, attempting to improve the solution. Evolutionary Algorithms maintain populations of placements and use selection, crossover and mutation to progressively favour solutions that require fewer beacons. The authors also develop hybrid approaches in which Constraint Programming and LNS are combined on a floor-by-floor basis.
The paper shows that the best way to solve large three-dimensional BLE beacon placement problems is not to pursue a single globally optimal search. A hybrid approach combining constraint-based optimisation with faster heuristic search can produce near-minimal, fully covering beacon layouts much more reliably and at a scale that is realistic for complex buildings.
We often get asked what’s the best iBeacon? Unfortunately, there is no one best beacon for all scenarios. It depends on your particular project and business requirements. Having said this we have some favourites based on specific characteristics:
Best for Price: KKM K11 – Inexpensive beacon that transmits iBeacon, Eddystone UID, Eddystone URL, Eddystone TLM and battery level:
Best for Features: M52-SA Plus – Large easy replaceable battery, long range, temperature, humidity, accelerometer:
Best for Battery Life: MBM01 – Replaceable lithium (included) battery for a very long battery life of up to 10 years (depends on settings):
Best for Setup App: Minew range – Minew’s latest BeaconPlus range (those supporting both iBeacon and Eddystone) provides the best in class app.
View our complete range.
A new paper presents a low-cost system that uses Bluetooth Low Energy beacons to detect when a child enters, remains in or leaves a playground. Each child carries a Bluetooth beacon, while a single smartphone installed at the playground scans the beacon’s signal strength. Entry and exit events are then sent to a server, which issues push notifications to caregivers and creates daily, weekly and monthly activity records.
Because BLE signal strength can fluctuate due to obstacles, reflections and movement, the system applies Kalman filtering and time-based thresholds rather than reacting to every change in RSSI. This reduces false alerts near the playground boundary, although it introduces a delay of several seconds and can miss very brief exits followed by rapid re-entry.
Field tests across five playgrounds reported an average detection accuracy of about 99.2% and an average response time of roughly 6.5 seconds. A separate test with ten beacons detected 39 of 40 events, giving 97.5% accuracy. The results suggest that BLE beacons are effective for simple presence and entry/exit monitoring, but not for precise positioning. Performance may also vary with weather, site layout, crowds and beacon placement.
Many sensor beacons contain accelerometers that measure movement along the x, y and z axes. These values can be included in the beacon’s advertising data and received by a smartphone, gateway or another Bluetooth-enabled device, such as a single-board computer.
Beacons transmit advertising packets at a predefined interval. Depending on the device and its configuration, this interval is typically between 100 milliseconds and 10 seconds. An important question is what happens to the accelerometer data between these advertising events. Is the data averaged, stored or simply lost?
A key characteristic of battery-powered beacons is that they transmit for only a very short period, typically one or two milliseconds, before returning to sleep to conserve power. They do not normally continue processing or storing accelerometer readings while asleep, as doing so would significantly reduce battery life.
As a result, the x, y and z values included in an advertising packet represent the acceleration measured at, or very close to, the time of transmission. Movement occurring between advertising events is not averaged or retained.
To reduce the likelihood of missing an important movement feature, the shortest available advertising interval should be used, which is often around 100 milliseconds. However, even at this rate, movement events lasting less than 100 milliseconds cannot be detected reliably because they may sometimes occur between two advertising transmissions.
Cisco Spaces uses generic Bluetooth Low Energy (BLE) beacons rather than one proprietary beacon type. It can detect and process beacons from multiple vendors and is broadly protocol-agnostic.
Note that the information on the Cisco Spaces is wrong, confusing and almost certainly written using AI. Bluetooth TAGs, also known as beacons, are a subset of Bluetooth devices, not a separate thing.
We recommend you use beacons with the iBeacon protocol as this is supported in the widest selection of beacons. The Cisco technical area shows how to include the beacons.