Support – Page 33 – BeaconZone Blog

How Accurate is Bluetooth Direction Finding?

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™

Log4j Vulnerability

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.

Beacon Battery Use Testing

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.

Practical Bluetooth AoA Direction Finding Tips

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:

Avoid metal objects close to the locators. Try getting better accuracy by adding boxing above locators to move them away from items such as metal beams.
Try to arrange that you have locators on all sides of a beacon. You ideally need locators all around the beacon. Accuracy is poor when the angle between beacon and locator is very large. This includes outside the perimeter of the locators where the angles get progressively larger.
The best, of the order of centimetres, accuracy is obtained when the beacon is close to a locator. If accuracy is particularly important, consider dropping the locators down with tall ceilings. Don’t drop too far as remember, from the last tip, accuracy is poor when the angle between beacon and locator is very large.
For an x, y z location, the worst accuracy is on up-down z axis. This is because all the locators are usually placed at the same height.
Accuracy is best when there’s line of sight between the beacon and locator. This favours the placing of locators on the ceiling/roof and beacons on top of items such as pallet loads.
While the physical room usually can’t be changed, be aware when testing that an enclosed space such as an office has more reflections and hence less accuracy than, for example, a warehouse.
For most systems, adding more locators in the same area produces more location angles that can be used to calculate a more accurate beacon position. Also try to stagger the locators so they are not in line. More data also means systems can also average the data to mitigate radio noise. However, more data means the location engine supports fewer beacons.
Another way to average more data, without stressing the location engine, is to filter over time. However, this increases the latency when receiving location updates.
Accuracy varies depending on the beacon orientation. The orientation that gives the best accuracy for one direction, say x, isn’t necessarily the best for y. While there’s usually nothing you can do about this, in some controlled scenarios you can arrange fix the beacon orientation to improve accuracy in a particular direction.
Too many beacons, in the same area, advertising too regularly causes Bluetooth packet collisions and loss of radio signal reaching locators. Large beacon populations require a longer beacon Bluetooth periodic advertising period that also has the affect of allowing the system to support a larger maximum number of beacons.
Accurate site and anchor measurement is important. Inaccurate initial measurement is a common cause of poor system accuracy. Use a laser measure. If you finding it difficult to measure the x, y location of a locator high up, fix a plumb bob line and measure the location at floor level.

Read about PrecisionRTLS™

Using Bluetooth Mesh and Space, Time, Frequency Diversity to Improve Locating Accuracy

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.

Why We Created Our Own Bluetooth Engine

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.

Analysis of location angles for a 12 antenna locator
The peak shows the most likely location

The location engine can be used on its own or as part of PrecisionRTLS™ for plotting onto floorplans, alerts and access to historical data.

Do You Have a Beacon That Makes a Sound When You Are Near?

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.

Real Time Location System (RTLS) ROI

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.

Is it Possible to Continuously Scan for Bluetooth Devices on iOS and Android?

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:

On iOS, Apple hide Bluetooth MAC addresses and for some APIs hide the iBeacon ids making unique identification more difficult.
You will find it very difficult to get a continuously scanning app through Apple app store review. You will need strong justifications.
Scanning continuously uses lots of battery power, even when advertising with periodic ‘off’ and ‘on’ periods.
Capabilities of devices vary meaning you will almost certainly get some end user devices where your implementation won’t work. For example, some manufacturers stop long running processes.
Some users will play with their phones and end up purposely or inadvertently disabling your application.

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.

Measuring Crowded Museums Using Bluetooth Beacons

There’s recent research on Managing Crowded Museums: Visitors Flow Measurement, Analysis, Mode l ling, and Optimization.

The aim of the research was to provide suggestions to a museum’s curators to better manage visitors flows to increase visitor comfort and improve safety. The museum for the case study was Galleria Borghese museum in Rome, Italy that has no obligatory exhibition path and has frequent congestion in some rooms such that those containing Caravaggio’s paintings.

Beacons set to advertise iBeacon at +4dB power were carried by visitors. RaspberryPi 3B+ (RPi) were used in rooms to detect beacons. Data from the RPi was stored in a SQL database. The project captured over a million records for 900 visitors’ trajectories during 13 2 hour long visits.

The researchers used Lagrangian field measurements and statistical analyses to analyse the data. A sliding window-based statistical method and a MLP neural network were compared.

It was possible to accurately reconstruct visitor trajectories and analyse visitors’ paths to get behavioural insights.

The system was suitable for the museum being economically viable and accepted by visitors. An issue was Bluetooth signal noise that was mitigated using data processing. The sliding window approach was better at measuring room transitions while the machine learning approach performed better at estimating the time spent in rooms.

The researchers identified issues with the museum design and suggested rearrangement of the artworks and implementing of a new ticketing strategy to let 100 people enter every 30 minutes while eliminating a 2 hour time limit.