Author: Support

Bluetooth AoA Direction Finding in the Cloud

We have had many enquiries from ISVs regarding the possibility of using AoA in the cloud. The idea is to use a location engine instance to allow their multiple customers to access AoA direction finding as a service.

Bluetooth AoA Direction finding works by having multiple locators that communicate with an on-site gateway that connects to the location engine. This is radio data so there’s lots of information sent very often. For large sites, there are multiple edge gateways. In most systems with more than a few assets, the gateway throughput becomes limited by the gateway hardware and the location engine processing input is limited mainly by the CPU capability.

The location engine has to do a lot of work. It implements computationally intensive radiogoniometry and anti-interference algorithms using data from multiple gateways.

In most cases, with large numbers of assets, the gateways and location engine are working near full capacity with the latency of the whole system being balanced against the number of assets.

While such a system can work in the cloud, the bandwidth and latency of the connection to the cloud means that it usually isn’t technically and financially viable. Sharing such a system across customers is even less viable. Instead, standalone systems have to be set up on-site to provide optimum performance.

Be aware that some ‘toy’ evaluation, as opposed to production, AoA systems perform the radiogoniometry and anti-interference algorithms at the gateway. While might work for a few assets, the gateway usually doesn’t have the processing power to scale to a production environment. Also, the gateway is only processing the radiogoniometry and anti-interference algorithms using data it has seen. Production grade radiogoniometry and anti-interference algorithms need to consider data from multiple gateways.

Read about PrecisionRTLS™

Match Use of Beacons to Organisations’ Goals

As we have previously mentioned, we believe too many companies chase the beacon retail marketing bandwagon when there are more compelling uses for beacons. These other uses also often have much less commercial competition. Think outside the current common usecases. Instead, invent new uses that better match organisations’ goals.

One such example is mentioned in the article Can Big Data Make for Better Exhibitions? Unlike the run of the mill, “let’s tag items and show information on them”, The Art Institute of Chicago used beacons to create heat maps, travel paths and derive dwell times to determine which parts of the museum people really want to see. The museum uses beacons for analytics. Promoting popular parts of the museum brought them an uplift in paid attendance from $14.8 million to $19.9 million. This success is based on concentrating on the museum’s real need of more income.

Start with your needs rather than the technology. Think in terms of your current challenges and work out how IT, in general, might be used to quantify the problem. Analytics will help you narrow in on specific areas that, in turn, can be improved and hence better achieve the organisation’s goals.

South Western Railway Trials Beacon App for Partially Sighted Passengers

South Western Railway in Southern England is using the myEyes app to guide partially sighted users to assistance boarding points at stations. The app provides audio directions to guide passengers from the station entrance to Assisted Boarding Points on platforms.

A confusing article on the South Western Railway site attempts to explain how it works. It says “the myEyes app uses Near Field Technology to guide customers with sight loss around stations”. This isn’t true because Near Field Technology (NFC) isn’t used. It uses a smartphone’s GPS to know the passenger has reached a station and then Bluetooth beacons within the station. The article says “Bluetooth beacons installed across the station track the device in question”. This also isn’t true because it’s the wrong way around. The smartphone detects the beacons to know a passenger’s location.

A video is available showing the app being used.

New F1 Beacon in Stock

We have the new, small KKM F1 beacon in stock. This beacon is different because it’s rechargeable, offering 4-6 months use per charge, based on 1 sec advertising.

It’s also waterproof to IP67 and has a button that can be used for SOS to send out different advertising. This beacon also has an accelerometer for motion triggered broadcasting.

It’s charged using a USB cable with a magnetic connector.

View all beacons

MQTT vs HTTP for Bluetooth WiFi Gateways?

Bluetooth WiFi gateways offer MQTT and/or HTTP for sending data to servers/cloud services. We are often asked which should be used. HTTP is what’s used by your web browser to fetch and send data to web servers. In very high level terms, MQTT accomplishes a similar thing but is better optimised for mobile devices and the Internet of Things.

HTTP is very ‘chatty’ which means it’s more complex, code wise, to implement at the sending end and wastes a lot of data and processing power getting information from sender to receiver. You can think of HTTP as wrapping the data within lots other data that gets sent backwards and forwards. MQ Telemetry Transport Protocol (MQTT) came out of IBM, is now an ISO standard and uses lightweight publish/subscribe messaging. It requires a smaller code footprint at the sender and uses less network bandwidth. This matters most when you are trying to get the maximum transactions per second or are being billed for data use.

Bluetooth WiFi gateways are powered via USB and have reasonably powerful microcontrollers so MQTT’s efficient processing doesn’t matter that much. The more efficient processing is more applicable to apps running on mobile devices. For example, Facebook uses MQTT which saves battery life.

However, being lightweight, MQTT offers faster response times and lower data use than HTTP that, while not necessarily being of much of an advantantage for the BLE WiFi gateway, benefits the communications medium and server side. The communications medium, that can sometimes be cellular or be data constrained, uses (and possibly bills) less data. More crucially, the server can process more requests in less time. MQTT tends to be better when connectivity is intermittent, bandwidth is at a premium and throughput is critical.

In summary, MQTT has lower latency and is more efficient. Whether these are required advantages depends on your actual project. If you need more help, consider our development services.

Nordic Wireless Q Magazine

Nordic Semiconductor, the manufacturer of the System on a Chip (SoC) in many beacons, has published the latest online issue of Wireless Quarter Magazine. It showcases the many uses of Nordic SoCs.

The latest issue of the magazine highlights the use of the SoC in the following Bluetooth solutions:

  • A smart animal tracking and management system.
  • A handheld device used by students to answer test questions, record their attendance, answer surveys and provide class feedback.

There are also some interesting articles on:

  • How Bluetooth IoT sensors are enabling insurers to manage risks and mitigate claims by advancing accident prediction and prevention.
  • An explanation of the global chip shortage, manufacturing challenges and mitigations.
  • How IoT data can be used with AI machine learning to improve decision-making.

Read Nordic Semiconductor Wireless Quarter

Implementing Bluetooth AoA Using Software Defined Radio (SDR)

There’s new research from Poznan University of Technology, Poland on Angle of arrival estimation in a multi-antenna software defined radio system: impact of hardware and radio environment.

The researchers implemented Software Defined Radio (SDR), on an inexpensive USRP B210, using the Root Multiple Signal Classification (Root-MUSIC) algorithm to provide Bluetooth AoA. Consideration was given to errors caused by the hardware and the radio environment.

Hardware errors were mainly synchronization errors. The accuracy of the AoA was affected by the degree of multipath propagation and filtering was found to improved accuracy. An implementation with two antennas and the Root-MUSIC AoA algorithm was able to achieve less than 10m estimation error in most environments.

Read about PrecisionRTLS™

Using Bluetooth LE with React Native

There’s a useful new article at Stormotion on how to use Bluetooth LE with React Native. The article explains the difference between Bluetooth LE and Classic Bluetooth and details the differences between the two main libraries when integrating Bluetooth LE into React Native apps.

The article also provides information on what apps to use to test Bluetooth LE and has insights on how to avoid the common problems.

Detecting Malicious Bluetooth Trackers

There’s new research from University of Washington on BLE-Doubt: Smartphone-Based Detection of Malicious Bluetooth Trackers University of Washington (PDF).

Stalkers can hide Bluetooth beacons on targets’ clothing or in vehicles so as to monitor their locations. The researchers created an open-source method of detecting maliciously deployed Bluetooth beacons.

The algorithm detects malicious devices within a few minutes. The software scans for Bluetooth advertisements and stores a history so that an alert can be created if a beacon is following the same route as the user.

iBeacon, Altbeacon, Eddystone, Tile, Chipolo, Spot, and AirTag are all detected with AirTags the greatest challenge due to rotation of their MAC addresses between every two hours and once a day and their erratic and unpredictable advertising.

The app doing the scanning causes heavy smartphone battery use. The smartphone lost between 5% and 10% of its battery per hour during active scanning.

View Tracker Beacons

The Problems of Using Bluetooth RSSI

There’s some older but nevertheless useful research from Chung-Ang University, Seoul, Republic of Korea on A Measurement Study of BLE iBeacon and Geometric Adjustment Scheme for Indoor Location-Based Mobile Applications.

The research looks into detecting beacons on smartphones and using the received signal level (RSSI) to infer distance. The aim was to understand the nuances of the variation of signal to be able to create an automatic attendance checker system.

The researchers looked into the differences between iOS and Android phones, the affect of device placement height, differences between iBeacons from different manufacturers, the affect of reducing to minimum transmit (Tx) power, indoors versus outdoors and the affect of obstacles and WiFi.

iOS showed notably shorter maximum distances of 85 meters and the difference between the maximum distances of iOS and Android turned out to be very large. RSSI readings on Android phone decreased more gradually with distance while iOS showed a sudden drop in RSSI after 10 meters. RSSI readings on the Android platform had more temporal (stability) variation than iOS.

The researchers found it difficult to create a model that could take into account all the variations of RSSI. They said:

We believe that our work provides evidence on the challenges for designing an indoor localization system using commercial-off-the-shelf (COTS) iBeacons devices.

The researchers were trying to create a very accurate RSSI-based system that could use any smartphone and any beacon manufacturer. This isn’t possible. Instead, accuracy has to be compromised, hardware restricted or a different technique used.

Most RSSI systems such as these use gateways rather than smartphones to perform Bluetooth scanning. This removes the smartphone model variability. Using only one beacon model reduces variability.

Newer Bluetooth Direction Finding provides a newer way than RSSI to obtain much better accuracy.