What is Bluetooth Direction Finding?

Bluetooth Direction Finding is an exciting new technology introduced with Bluetooth 5.1. Bluetooth Direction Finding technology employs a transmitter that transmits a packet containing a continuous tone extension.

A compatible receiver obtains the information by sampling the in-phase and quadrature components of the radio signal while switching antennas in a defined sequence. The phase difference provides information which is practically used by software to estimate the direction.

An angle is a bearing, not a complete position; multiple measurements, known anchor locations, and coordinate calibration are normally needed to place an asset on a floor plan. Nordic Semiconductor's direction-finding overview explains the two operating models.

Angle of Arrival (AoA):

A relatively simple tag transmits the CTE. A fixed locator receives it through an antenna array and estimates the direction of the tag. AoA usually suits asset-tracking deployments with many battery-powered tags and fewer, more capable fixed locators.

Angle of Departure (AoD):

A fixed transmitter switches among antennas as it sends the CTE. A compatible receiving device estimates its bearing to the transmitter. AoD can suit navigation or device-centric positioning when the receiving hardware and software support that role.

Just because a person’s mobile device performs BLE scanning does not imply the device is capable of transmitting I/Q data for AoD, the user’s needs must be confirmed prior to implementing delivery via mobile device.

These processes are not guaranteed to yield precision results to the centimeter level. The final results may be influenced by antenna design and placement, installation height, metal racks, walls, operators’ movement, and multipath effects.

We define acceptance criteria for the actual building, then measure them in a pilot rather than using a laboratory accuracy figure as a product claim.

Nordic nRF hardware and software choices

For a direction-finding design, we evaluate Nordic's nRF52833 and the nRF5340, both listed by Nordic for Bluetooth Direction Finding. The nRF52833 suits compact tags or locators; the dual-core nRF5340 offers processing headroom. Final selection depends on radio role, power, availability, firmware support, and qualification.

Chip-family names alone are insufficient. The popular nRF52840 is useful in many BLE products, but Nordic does not list it as a direction-finding SoC.

An earlier project using an nRF52840 device thus shows transferable work related to BLE products, as opposed to evidence of nRF52840 device support for AoA/AoD. We check the SoC, PCB, SDK version, controller features, and antenna-switch connections before setting up the BOM.

nRF Connect SDK from Nordic and Zephyr direction-finding examples serve as a practical basis for CTE transmission and reception as well as I/Q data collection.

Production firmware requires configuration data storage, diagnosis, secure updates, power management, and a reliable mechanism for transmitting measurements from each beacon to the position service.

The application must also record antenna-switch patterns and calibration versions; changing either without updating the estimator can quietly corrupt angle results.

Relevant Adequate Infosoft project experience

Smart Watch Development

IoT Smart Watch Development with BLE & Mobile App Integration

The nRF52 smartwatch case study that we published includes information about hardware and low-power BLE software as well as health and fitness features and prototypes developed for production purposes.

These are useful fields when it comes to a wearable RTLS device, such as providing power budget estimation. In our case study, it is clarified that Bluetooth Direction Finding is not used by the smartwatch.

View Case Study

BLE Smart Ring

Wearable BLE Smart IoT Ring Development with Nordic nRF52

The Nordic nRF52 BLE smart ring project describes compact-device firmware, gesture interactions, BLE communication, and EVT hardware work.

It illustrates how much enclosure, energy, and firmware architecture matter when a location tag must be small enough for daily use. It is a wearable firmware reference, not a measured AoA pilot.

View Case Study

BLE Smart Lock

Smart Lock Hardware & Firmware Using nRF52840

Our Nordic nRF52 smart lock and access-control case study associated hardware, smartphone interactivity and cloud control. The ability to provide these integrations is important when location events are to be managed following a particular and defined operational procedure.

View Case Study

End-to-end Bluetooth RTLS development services

Tags and beacons

We design PCB and firmware around enclosure, attachment, battery life, advertising interval, and maintenance. Asset labels and wrist-worn devices have different constraints. An ordinary BLE advertisement by itself cannot provide CTE-based angles.

Integration of AOA locator and antenna

The design of a locator includes more than a Nordic development board. Our offering includes antenna count and layout, RF switching, feed routing, enclosure effects, mounting, power, backhaul, and on-site commissioning.

To minimize the risk of investment in custom antenna PCB, it is advisable to use an appropriate array or reference design at the very beginning.

The collection of raw I/Q data allows our team to differentiate between RF and positioning algorithms issues.

Positioning engine

The service converts observations into bearings and coordinates, combines readings from several anchors, filters unstable positions, and applies map constraints where appropriate.

It needs sensible behavior when one locator is blocked, an asset changes floors, or packets are missed. Confidence and last-seen timestamps belong in the API; silently drawing an old coordinate as a live position misleads operators.

Applications and integrations

We create visual representations of the floor layout and facilitate asset search, event location, device set-up, and access rights. Using APIs, all location data can be passed on to the maintenance systems.

Data retention and access settings refer to whether the system is able to track objects equipment-wise or people-person-wise.

Validation and implementation

Our test plan includes both stationary and mobile tags, crowded areas, anchor failures, battery life, and errors on the actual floor plan.

We give feedback about the pilot project and suggest changes to the device distribution before the design is expanded to other rooms or sites.

Where AoA and AoD create useful results

In a warehouse, AoA locators can help staff find returnable containers, shared tools, or mobile equipment. The first useful goal might be reliable zone identification rather than continuously drawing a dot on every shelf.

In a hospital, an equipment-finding application can reduce time spent hunting for pumps or wheelchairs, provided coverage, privacy rules, and cleaning workflows are addressed.

For factories, tagged carts or work-in-progress items can trigger arrival and departure events at stations. Here, false transitions may matter more than median position error.

AoD is the solution for wayfinding equipment that truly carries out the measurements from the receiving side, such as specialized handheld devices. Instead of presuming that all mobile phones use direction finding capabilities, we investigate the fleet of devices actually utilized by the users.

Outdoor GPS navigates by means of satellites, while indoor Bluetooth RTLS navigates via signal from transmitters. A hybrid solution may utilize GNSS for outdoor navigation and Bluetooth Low Energy for indoor navigation, but an indoor AoA setup does not turn into a worldwide device even if both systems provide location information.

How we scope and test your RTLS pilot

We first document the site's floor plans, asset types, expected movement, mounting restrictions, network access, and business events. The acceptance test defines a measurable outcome: for example, whether staff can reliably identify the correct room or find an item within a specified time.

We agree on update intervals, battery targets, and the acceptable fraction of missed or incorrect zone events before selecting hardware.

Next, a pilot captures observations at reference points and along realistic routes. We compare predictions with ground truth, inspect error by area, and repeat tests during normal operation.

If the RF environment makes the target unreliable, we change locator placement, adjust requirements, or consider another technology. After the pilot meets agreed criteria, we specify installation and maintenance procedures.

Frequently asked questions

Is AoA more accurate than RSSI-based BLE proximity?

AoA introduces directional information which can enhance positioning accuracy, but the results depend entirely on the antenna arrays, arrangement, calibration, and environment.

RSSI can be sufficient for general presence detection or room scale events, the pilot has to decide if angle measurement adds enough value to justify buying required hardware.

How many locators are needed?

There is no universal number per square meter. Coverage, mounting geometry, obstructions, floors, and the required confidence determine the count. Multiple useful bearings improve position estimation, while poorly placed locators can produce more data without a better result.

Can an existing nRF52840 beacon become an AoA tag through a firmware update?

Do not assume so. Nordic lists specific direction-finding-capable SoCs, including nRF52833 and nRF5340. We check the exact hardware and controller support; an existing beacon may need redesign.

Can employees utilize their personal phones as AoD receivers?

Only if their phone has the right hardware, operating system, and application interface can they be used for measuring angle.

We check if devices can support AoA or suggest dedicated receivers before pursuing any directions with users.

What should a first engagement deliver?

The feasibility specification should include hardware shortlist, placement design, tagged use cases, assumptions about power consumption, functioning pilot, error and event measurement, rollout plan.

Please send us your house specification and the things that you would like to find out about, and we will help you create an RTLS proof of concept.

Editorial resources

Abhinav Akula
DevOps Engineer and 3× Microsoft Azure Certified professional specializing in Azure cloud solutions, migration, deployment automation, and multi-cloud environments. He holds Microsoft certifications as an Azure Developer Associate and Azure Solutions Architect Expert, with expertise in building scalable, secure, and reliable cloud infrastructure.