Support – BeaconZone Blog

The Affects of USA Tariffs on Bluetooth Beacons

The recent changes to U.S. tariff policy have significantly affected the import of Bluetooth beacons into the USA. One of the major shifts is the removal of the de minimis rule, meaning that even low-value imports from China, under $800, are now subject to tariffs. In addition, a general 10% tariff now applies to most foreign goods, with some electronics facing duties as high as 145%, particularly if they originate from China.

As almost all Bluetooth beacons are produced in China due to its cost-effective and advanced manufacturing ecosystem, the tariffs directly impact this market. Even sourcing these devices through third countries like the UK does not avoid the tariffs, since duties are based on where goods are made, not where they are shipped from. As the U.S. lacks a mature domestic beacon manufacturing industry, to our knowledge, there are no cost-effective local alternatives. Even if there are a few we have missed, they probably won’t provide the range of models/capability needed for different types of project.

This has made larger-scale beacon deployments in the U.S. economically impractical. It is not viable for a company in the USA to begin manufacturing Bluetooth beacons, as the unit cost would be prohibitively high. This is primarily due to significantly higher production costs in the United States compared to China, including labour, components and facility expenses.

On a broader scale, these tariffs are expected to raise prices and create similar problems across a very large number of other goods types. Although many see the tariffs as a political manoeuvre that could be temporary, their current impact on both technology adoption and the wider economy is a concern. Uncertainty creates instability for businesses trying to plan investments, manage supply and remain competitive.

Using Bluetooth Beacons for In-Place Ageing

A new study describes an indoor‑positioning system built around Bluetooth Low Energy. Each room receives a mains‑powered beacon that houses an ESP32 micro‑controller running BLE in advertising mode, together with motion, ultrasonic, light and temperature sensors. Older adults wear a low‑cost tag or smartwatch that periodically transmits its identifier. Beacon modules report the relative signal strength indicator of the tag they detect to a central Raspberry Pi hub via ESP‑NOW, allowing the hub to decide where the wearer is without relying on a floor plan.

Bluetooth was selected because it works reliably at room scale, consumes little power on the wearable, and is already present in commercial tags and watches. Although the latest specification is 5.3, the authors chose the mature 4.0 stack for stability and documentation. Its 30 m nominal range comfortably covers a domestic room while avoiding the battery drain seen with Wi‑Fi.

During installation the wearer simply walks around each room for twenty seconds. The hub records baseline RSSI distributions from at least three nearby beacons, then uses an exponential filter (optimised at a 0.2 weighting) to smooth radio‑frequency noise before applying a calibration‑based lookup and, when needed, trilateration. This self‑calibration lets the system adapt to furniture, walls and other sources of multipath without professional setup.

Static tests at 1, 2.5, 5 and 10 m showed raw RSSI fluctuating by several decibels because of indoor interference; filtering reduced variance to about 1.7 dB at ten metres, making distance bands for different rooms distinct. In two typical UK‑style houses the system identified the correct room in roughly 96 % of more than 600 ground‑truth checks. Median transition recognition between adjacent rooms was under two seconds and remained below eight seconds even when rooms were far apart.

Adding the passive‑infra‑red and ultrasonic sensors improved confidence when RSSI values from neighbouring rooms overlapped, taking overall presence‑detection accuracy to 93 % with motion sensing alone. All BLE and sensor data stay on the hub and, if the resident allows an Internet link, are only mirrored transiently to Firebase for remote monitoring. The authors argue that this low‑cost, plug‑and‑play BLE architecture is particularly suited to large‑scale ageing‑in‑place studies and could equally track clinical equipment in hospitals.

Beacon Waterproofing Insight

Some of the beacons we offer are fully waterproof, which many people tend to associate solely with protection from direct exposure to water, such as rain, splashes, or even full submersion. While these are of course important scenarios to consider, waterproofing can also play a crucial role in situations where exposure to moisture isn’t as obvious or dramatic.

Take vehicle installations, for example. At first glance, the inside of a car, van or lorry may appear completely dry, and it might seem like a waterproof beacon wouldn’t be necessary. However, vehicles can experience long periods of elevated humidity, particularly when temperatures fluctuate or when the vehicle is parked in damp environments. Over time, this persistent humidity can lead to condensation forming inside the beacon housing.

This kind of moisture buildup may not be immediately visible, but it can be highly damaging. Internal condensation can lead to corrosion of metal components, including the battery contacts or internal circuitry. Eventually, this corrosion can cause the beacon to malfunction or stop working entirely. Waterproof beacons are designed not only to prevent ingress from visible water but also to seal out ambient moisture, making them far more resistant to these kinds of subtle, long-term risks.

So, when you’re specifying a beacon for your application, it’s worth thinking beyond direct water exposure. Consider the full environmental conditions it will face over time, including humidity. In some cases, waterproofing isn’t just about protecting against rain, it’s about ensuring long-term reliability in conditions that might not appear problematic at first glance.

BeaconZone Help Desk

We operate a help desk and ticketing system to manage pre and post sales support queries efficiently. This approach allows us to provide a consistent and coordinated service across our team, while also preserving the full history of each conversation. This is particularly helpful when an issue takes longer to resolve or when follow-up is needed weeks or even months later. Please note that our telephone line is intended for administrative queries only and cannot provide technical or in-depth support.

The support system also includes a searchable knowledge base, where you can find answers to frequently asked questions. Each time someone raises a new query that hasn’t been covered, we add it to the system so that others can benefit from the answers in future. As you type into the search bar, the system will suggest possible answers based on your input. If your question isn’t addressed there, you can easily submit a support ticket without registering. We aim to respond within 24 working hours, though in most cases you’ll hear from us much sooner.

Using Beacons for AR Synchronisation

New research presents a framework for synchronising multi-user augmented reality (AR) sessions across multiple devices in shared environments using beacon-assisted technology. The conventional reliance on vision-based methods for AR synchronisation, such as Apple’s ARKit and Google’s ARCore, often fails in larger spaces or under changes in the visual environment. To overcome this, the study introduces two alternative methods using location beacon technologies: BLE-assist and UWB-assist synchronisation.

The BLE-assist method uses iBeacon broadcasts to determine the user’s room context and integrates this with existing AR anchoring frameworks. By breaking down large areas into room-sized contexts, this approach allows ARWorldMaps or Cloud Anchors to be managed in a more localised and efficient manner. It achieves high positional accuracy, but its performance drops under significant environmental changes.

On the other hand, the UWB-assist method uses ultra-wideband beacons and the device’s azimuth reading to create a fixed spatial reference. This allows persistent anchoring across sessions, with consistent resolution success even in varied physical surroundings. Although this method does not offer the same fine-grained accuracy as BLE, it maintains consistent performance with a near-constant average synchronisation latency of 25 seconds. However, it is more technically involved, requiring the initial ranging process to stabilise and potentially longer localisation times if many devices are present.

In comparative evaluations, UWB performed better in terms of reliability and robustness to environmental changes, while BLE was more accurate in anchor placement. UWB’s reference pose calculations demonstrated a mean error of 0.04 metres in position and 0.11 radians in orientation, which, while less precise than BLE, remains within an acceptable range for most applications.

The study also evaluates power consumption, scalability, and cost. BLE beacons (ESP32) consume more power than UWB beacons (DWM3001CDK), but the latter are more expensive to deploy. In terms of scalability, BLE is limited by map-saving conflicts and anchor lifespan, while UWB faces challenges in concurrent device ranging, although improvements in beacon hardware could address this.

In conclusion, the BLE-assist approach is better suited to short-term, high-precision AR experiences in relatively stable environments. UWB-assist is preferable for larger, more dynamic settings where consistent synchronisation is critical, even at the expense of slight positional inaccuracy and higher delay. The source code for this work is publicly accessible for further development.

Our take on this:

One point worth noting is that using the ESP32 as a beacon platform is not optimal in terms of power consumption. Employing dedicated hardware beacons designed specifically for this purpose would significantly reduce power usage. Moreover, such specialised hardware would offer a more compact and efficient form factor, with antenna configurations that are better suited for precise positioning and signal stability. This project shares similarities with our consultancy for Royal Museums Greenwich on the Cutty Sark.

Bluetooth Sensor Tags

Bluetooth sensor tags and sensor beacons are essentially the same, with the difference in terminology largely depending on how they are used. When these devices are fixed in place, they are typically referred to as beacons. When they are attached to assets or people, they are more commonly called tags, as they are being used to ‘tag’ items or individuals. Despite these naming conventions, the terms are interchangeable and can be used regardless of the specific application.

The use of the term tags also comes from the use in RFID, barcode and UWB devices that can also be used to uniquely identify devices.

Bluetooth sensors can be used in two ways, either via connection-less advertising or having another Bluetooth device connect and examine values. This is explained further in our article on Using Bluetooth Wireless Sensors.

Tagging implies locating. However unlike other technologies, devices can do a lot more than just locating and can detect movement (accelerometer), temperature, humidity, air pressure, light and magnetism (hall effect), proximity, heart rate and fall detection.

Beacon Proximity and Sensing for the Internet of Things (IoT)

City of Luxembourg is Using iBeacons

The City of Luxembourg’s Municipal Office is using Bluetooth beacons to send push notifications through its free smartphone app, cityapp – VDL, alerting users when their bus is about to depart.

The app, available in English, French and German, has several features across different tabs. The “Explore” tab highlights nearby attractions and upcoming events tailored to your preferences, such as parks, playgrounds, museums and sports facilities. The “Transport” tab offers comprehensive travel information, including real-time bus and tram departures, car park availability, cycling infrastructure, taxi ranks and service disruptions. The “Services” tab gives quick access to practical information, such as city department contacts, public toilets, water fountains, the latest city news, your waste collection schedule and forms for reporting issues or making suggestions.

New MobileBeaconer Android App

IdeaSave Software has released a new Android app, MobileBeaconer, designed to easily detect Bluetooth Low Energy (BLE) beacons using iBeacon™, Eddystone URL, Eddystone UID or AltBeacon formats. The app allows users to save selected beacons and receive notifications when those beacons are nearby.

To ensure the scan continues without keeping the screen on, the app uses a foreground service, indicated by a “Scanning for managed beacons” notification. Users can also set the proximity range for notifications to immediate, near or far.

Testing if a Beacon is Working

It’s often the case you need to know if a beacon is working and advertising the correct information. It’s also sometimes necessary to differentiate between beacons, based on their signal strength, so you know you are setting up the correct beacon. Other times, you might want to know a beacon’s MAC address.

The best scanning app is Nordic nRF Connect that’s written by the manufacturer of the System on a Chip (SoC) in most beacons. Nordic nRF Connect detects all beacons and indeed all Bluetooth LE devices, irrespective of the SoC manufacturer because it just looks for standard Bluetooth advertising. nRF Connect is intelligent in that it works out the kind of beacon and displays the appropriate type of information.

It’s important you use the Android version of nRF Connect. Due to over-zealous efforts by Apple to hide identities, it’s not possible for iOS scanning applications to see advertising iBeacon (UUID, major and minor) information nor the Bluetooth MAC address even though these are openly transmitted by beacons.

Here’s an example scan:

In the above screenshot you can an iBeacon that has been tapped on to show extra information. All devices have the MAC address and a Received Signal Strength Indicator (RSSI). The MAC address uniquely identifies the device.

Devices that scan for beacons will experience a signal strength (RSSI) that varies depending on the distance to the beacon. It’s expressed in dBm and is always negative. A more negative number indicates the beacon is further away. A typical value of -10 to -30 dBm indicates the beacon is close. A typical value of -110 indicates the beacon is near the limit of detection. You can use this to determine which beacons are closest. You usually configure beacons when they are right next to the phone and have a higher, less negative, RSSI.

nRF Connect also shows the advertising period that’s based on how often the app sees the advertising as opposed to what has been set in the beacon. The value is rarely exactly what you have set because Bluetooth requires some randomisation of the advertising period to reduce the possiblity of collisions between devices, in the vicinity, that are set to the same period. Also, being wireless, not all advertising is seen which causes jumps in the shown advertising period. Read more about choosing the advertising period.

There’s also a ‘RSSI at 1m’ which is the beacon’s self-declared value, in the advertising data, of what the RSSI should be at 1m. This can be used by scanning devices, such as apps, as a form of calibration for determining distance. In most cases this value isn’t used and should be ignored. Read more about power and the measured power calibration value.

iBeacon MAC Address on iOS

When working with iBeacons on iOS, people often wonder if they can access the Bluetooth MAC address of nearby devices. The short answer is no. iOS does not provide an API for retrieving the MAC addresses of Bluetooth peripherals, including iBeacons, even though devices openly transmit this information. This restriction aligns with Apple’s strong privacy and security policies, which limit developers to using only the officially provided Beacon identifiers: UUID, major, and minor values.

Despite this limitation, some users may notice that a beacon’s MAC address is displayed in certain contexts, such as being printed on the device itself or visible within a manufacturer’s setup application. This raises the question how these apps access the MAC address when iOS does not allow it.

The answer lies in proprietary or non-standard mechanisms used by some manufacturers. These methods can include embedding the MAC address within extra custom advertising data or requiring an app to establish a connection with the beacon and retrieve custom settings that include the MAC address. However, since these approaches are not part of a Bluetooth standard nor part of Apple’s official APIs for iBeacon detection, they should not be relied upon for application development.

Relying on MAC addresses for identification can lead to issues. Different beacon models and manufacturers use different undocumented techniques, making it difficult to ensure long-term compatibility when second sourcing. Connecting to a beacon to get its MAC address adds an extra step that significantly complicates things and makes slower compared to just reading advertising with no connection.

Mechanisms used to expose MAC addresses are often undocumented. Any firmware update or change for later purchased beacons could change or remove these features without warning, making the approach unreliable for long-term solutions.

Apple’s privacy restrictions mean that app developers should focus on the standard iBeacon identification mechanisms to ensure stability, compatibility and compliance with iOS policies.