iBeacon, Eddystone, Bluetooth, IoT sensor beacons, apps, platforms
We now have Minew AoA Direction Finding Kit and beacons in stock. The AoA kit consists of a G2 gateway, 4 locators, 3 beacons and interconnecting cables. It covers an area of 400m². Multiple kits can be used to cover larger areas.
The gateway outputs antenna IQ data that’s sent to your server or BeaconZone’s LocationEngine™ for generation of angles.
Read about PrecisionRTLS™
Bluetooth direction finding promises sub-meter accuracy. In practice, the accuracy varies depending on factors such as the locator hardware quality, radio signal noise, surfaces causing radio reflections, the accuracy of locator placement and beacon orientation. The sophistication of the location engine software in mitigating some of the aforementioned factors can improve the accuracy.
As a guideline, our Location Engine with the Minew G2/AR1 tends to find beacons with a maximum angular error range between 6° to 10°, depending on the above factors. The error in position due to an error in angle gets magnified with distance from the locator. Hence, the accuracy also depends on the distance between the locator and the beacon.
Here are graphs of error vs distance for 6° error and 10° error:
The above accuracies are for hardware such as the Minew G2/AR1 with PCB antennas 50mm apart. It’s expected that greater accuracies might be achieved with hardware having greater inter-antenna distances.
It can be seen that the sub-meter promise has caveats. We have some tips to help reduce angular errors. Averaging data, over time, also reduces angular error with the trade-off of increased latency of detecting location changes. As with all locating technologies, headline performance claims need to be carefully examined and are only achievable in particular situations.
Read about PrecisionRTLS™
If you work in IT you will be almost certainly aware of the very recent Log4Shell vulnerability indexed as CVE-2021-44228. The Log4j is used by many popular applications, services and Java components. This vulnerably demands particular attention because it’s implicitly included in lots of software and allows an attacker to execute arbitrary code on affected systems.
We have completed a thorough analysis of our own systems and the software we supply to customers and can declare we have no services, products, or applications that are at risk. We don’t use Java at all and none of the components we use are using it behind the scenes.
Even though Beaconzone systems are not affected, there is the possibility that your other services might be impacted. You should communicate with your IT department to identify and mitigate this vulnerability. The NCSC has released a very large list of known affected software and the steps you can take.
One of the issues with using Bluetooth beacons is that it’s not easy to predict how long batteries are going to last. Battery life depends not just on the battery capacity but also the transmitted power, advertising interval, beacon processor chip type and whether the beacon has timed transmission. Also, beacons vary from model to model, sometimes even between revisions of the same model. In some scenarios it’s essential to know which beacon models are the most power efficient and how long batteries will last.
Over the years we have spent a considerable amount of time investigating actual battery use. It’s not as simple as you might think. You can’t use an ammeter because it can’t see the short pulses in peak power. The majority of the power is expended in very short, few millisecond (ms) transmit pulses, in between which the beacon goes into low power sleep.
Nordic Bluetooth Advertising Power Use
Testing needs to integrate the current used over multiple advertising periods. The test equipment needs to capture this data at sub 1ms precision in order to catch the pulses. The testing also needs to be flexible enough to work for advertising periods from 100ms to 10 sec.
We have custom in-house designed test equipment capable of real-time battery current testing. This enables us to compare different manufacturers’ beacons having the same configured settings and provide our consultancy clients with beacon battery use data based on their exact configuration settings.
As an example, an interesting test we did was was to compare the Sensoro AA transmitting just iBeacon vs iBeacon at the same time as the 3x Eddystone advertising packets. With only ibeacon @ 760ms, 0dBm advertising, 4 typical alkaline batteries would last 7.7 years. Transmitting all 4 iBeacon and Eddystone frames reduces the battery life to 2.9 years.
Another interesting observation has been that the beacons that have the strongest signals aren’t necessarily the ones using the most battery power. Design of aspects, such as the antenna, contribute to power efficiency.
We also offer ad-hoc beacon battery use testing.
Bluetooth Angle of Arrival (AoA) uses the phase difference of the radio signal hitting multiple antenna to calculate the elevation and azimuth angles to the beacon.
The accuracy is affected by physical aspects and the way the signals are processed. It varies from the order of a few centimetres to about a metre.
Here are some tips to maximise AoA accuracy:
Read about PrecisionRTLS™
There’s new research from the Department of Electrical Engineering, University of North Texas, USA on Measurement and Analysis of RSS Using Bluetooth Mesh Network for Localization Applications. The paper explains how received signal strength (RSSI) based solutions have accuracy limitations in radio multipath (radio reflective) environments. It describes a solution that improves accuracy using Bluetooth mesh and Bluetooth channel-based processing.
A system was created that exploits the space, time, and frequency diversities in measurements. Different Bluetooth channels have different fading effects.
Advertising was modified to make it Bluetooth channel-aware to be able to differentiate the fading effects. It was possible to reduce the residual fitting errors in the path loss models by using a space-time-frequency diversity combining scheme.
The system was demonstrated using ESP32 BLE modules.
The system significantly reduced the residual linear regression fitting errors in path loss models. It was able to more accurately use RSSI to measure the distance between the transmitter and receiver. The researchers demonstrated it’s possible to implement the proposed multi-receiver configuration and the diversity combining scheme using commercial off-the-shelf standard BLE devices.
In the post on Bluetooth (BLE) vs Ultra-Wideband (UWB) for Locating we mentioned how Bluetooth 5.1 direction finding solutions have been slow to come to the market and how the products that so far appeared all had shortcomings such we weren’t able to recommend them to our customers.
We spent a considerable amount of time (and cost) evaluating AoA solutions and were disappointed with what we found. While the hardware is generally good, the accompanying location engine software was very poor. This was perhaps understandable because software is not necessarily within a hardware manufacturer’s competence.
A location engine converts radio signals from multi-antenna hardware into x, y z location. There are many ways to implement a location engine using different radiogoniometry algorithms of different accuracy and computational complexity. The location engine also needs to filter the incoming data to mitigate the affects of multi-path reception, polarization, signal spread delays, jitter, and noise. It needs to be flexible to using just one locator or multiple locators for more accuracy. It needs to be performant to support the maximum throughput and hence the maximum number of beacons.
In our evaluations, the location engine wasn’t included in some solutions and where it did exist, it didn’t meet the above requirements. We found evaluation kits to be expensive and in some cases were ‘toys’ that demonstrated the principles but weren’t suitable for production. Most systems had vague performance specifications and it wasn’t clear how well they would scale. Most solutions used dongles for copy protection and some had resource limits linked to payment. Documentation tended to be poor, incomplete and require NDA for something that wasn’t at all commercially sensitive. APIs to access the location engine data tended to be incomplete. Systems were inflexible to beacon input rates and assume everyone needs 100ms updates that kills beacon battery life and severely limits the maximum number of tracked assets. Some only supported 2D rather than 3D locating. Some systems relied on applications polling rather than more efficient streaming the output data. The provenance of the software was unknown and whether it was secure, reliable and free of malware.
The above limitations caused too many uncertainties such that there was no way we could specify, demonstrate and supply to clients. It’s for this reason we created our own location engine that’s performant, flexible, accurate, reliable, secure and documented.
The location engine can be used on its own or as part of PrecisionRTLS™ for plotting onto floorplans, alerts and access to historical data.
The quick answer is no.
The longer answer is that beacons don’t know if anyone is near because they are not doing the listening. They just send out information. It’s possible to have a smartphone app see the beacon and the phone make a sound.
We also have special tracker type beacons to which an app can connect rather than just detect. Once connected, the app can cause the beacon to ring. However, only one app user can connect at a time.
If you are an owner or manager considering implementing a RTLS you might need to justify the return on investment (ROI). In some cases this is easy but in others a quantitative assessment of ROI can be tricky.
The simpler usecases where RTLS is used to automate manually finding items can be easily assessed. For example, workers might be spending a lot of time finding the right pallet in a warehouse or a nurse might be spending too long looking for a shared piece of expensive equipment. Not knowing where things are is increasingly becoming unacceptable for businesses. Times and salaries can be measured, totalled and estimated RIOs calculated to prove ROI.
However, say for example, an RTLS is used to monitor hospital medicines to ensure they in refrigerators and don’t exceed a measured temperature. What are the costs of not doing this? Apart from the cost of the medicines themselves how do you assess the cost of someone dying because the medicines weren’t kept cold? Still in the hospital, how do you assess the gain in being able to find wheelchairs in a hospital? How do you put a price on customer satisfaction?
Things can also get more complicated when, as it usually the case, a RTLS system starts being used for more than one purpose. For example, a recent education client purchased a system for tracking room occupancy but subsequently extended it for lone worker SOS. It’s often the case that just initial usecase justifies the initial investment and follow-on uses are a bonus.
Follow on benefits usually come through reporting and subsequent process improvement. Questions typically revolve around ‘Where has my asset been?’ or ‘What’s happened at particular location?’. The answers, in the form of data, provide insights that drive improvements in processes that can’t always be easily measured or quantified.
Focussing on ROI on its own can be misleading and it’s instead necessary to take a wider view of the qualitative benefits and opportunities.
We sometimes get asked if it’s possible to use a smartphone as a gateway to scan for Bluetooth devices. The thinking is usually that workers or users already have devices so why not make use of them?
While it is possible, there are many reasons why you might not want to do this:
The best scenarios are those where you can dictate the phone type, it can be mains (PSU) powered and the phone isn’t owned by a user (i.e. it’s just used as a gateway). It’s almost always better to use a dedicated gateway.