iBeacon, Eddystone, Bluetooth, IoT sensor beacons, apps, platforms
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.
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 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:
There are also some interesting articles on:
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™
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.
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.
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.
There’s a research paper by researchers from Taiwan on A practice of BLE RSSI measurement for indoor positioning. The paper looks into received signal strength (RSSI) to distance conversion, the significance of antenna plane (orientation) and measurements in two different situations, a low noise classroom and a more noisy manufacturing site workshop.
Techniques employed included developing a signal propagation model, trilateration, modification coefficients and Kalman filtering.
The hardware used included an Arduino Nano 33 (Bluetooth 5) and Linkit 7697 (Bluetooth 4.2). Over 1.6 million samples were collected generating over 13Mb of data.
“Multiple factors affected the RSSI, such as the device performance, antenna direction and radio wave refraction”
A positional accuracy of 10cm was achieved in ideal conditions dropping to meter level accuracy in more challenging setups and environments. The sensitivity of the (ceramic) antenna was found to fluctuate widely with orientation/topology. The researchers concluded that the key factor for reliable indoor positioning, based on RSSI, is maintaining good signal measurement quality.
We have had enquiries asking whether beacons can advertise while they are connected to. Beacons usually just advertise. However, when you setup via the manufacturer configuration app or in special cases, devices (or apps) fetching beacon values requires a (Bluetooth GATT) connection. During this time, beacons stop advertising. This means that, during this time, other devices, and hence apps, can’t see the beacon and can’t connect.
Beacons are based on standard Systems on a Chip (SoC) provided by one of four manufacturers : Dialog, Nordic, Texas Instruments and NXP. These manufacturers provide standard base software/firmware that is used by the beacon manufacturers. There was a time when the base software didn’t support advertising during connection. More recently, advertising during connection has been become possible but no beacons, we know of, support this yet. Note also that even when beacons do eventually support this, devices, and apps, won’t be able to connect if a connection is already in progress. The advertising will be set as non connectable.
Bluetooth direction finding uses locators that have multiple antennas. The antennas tend to be flat patches on a printed circuit board (PCB).
The antennas receive the same radio signal but at slightly different times based on the incident angle. This causes a phase difference in the received radio signal at each antenna.
Software is needed to process the radio signals from the antennas and calculate the incident angle. The radio signals are measured in terms of in-phase and quadrature components (IQ).
Processing the IQ signals isn’t easy because it requires taking account of the relative position of the antennas on the PCB, delays in switching between the antennas (there is only one radio receiver) and the use of complex-number arithmetic. The result is a power spectrum, the peak of which is the expected azimuth and elevation of the radio signal in two dimensions.
The finding of the peak also isn’t easy because it requires looping over lots of values to find the maximum. This is computationally time consuming especially as this has to be done many times per second for multiple locators.
Our LocationEngine™ is the first independent software to provide scalable IQ to location processing. It provides industry-leading accuracy, performance, security and reliability for Bluetooth® AoA direction finding. It’s currently compatible with the Minew AoA Kit but we are working with other manufacturers to support further hardware.
LocationEngine™ is designed in integrate into 3rd party systems to provide x, y, z and also area where locators cover more than one area. We supply PrecisionRTLS™ that uses this data to plot onto plans/maps, provide alerts and store historical data for later reporting.