How to Implement BLE-Based Localization with nRF52832 Without CTE?

[anpiri]

Hello all,

I'm working on a localization system using the nRF52832 chip and Bluetooth Low Energy (BLE), but I'm running into challenges due to how BLE transmits signals. I need advice on the best approach to achieve accurate localization. Currently I am using example code of a 'Beacon' device from the NRF connect 2.9 library.

Background:

The goal is initially achieving 2D localization and potentially expanding to 3D localization in the future. The system will operate in a complex medium such as the human body, where signal propagation is highly variable. The object to be localized will be a small PCB constantly emitting a BLE signal, currently experiments will be done with the NRF52DK but eventually a personalized PCB and antenna will be created. 

I plan to use an antenna array surrounding the BLE emitting device with 5-8 antennas designed in-house, which will pick up BLE signals emitted from the nRF52832 beacon. For now, I'm considering using an FPGA board to process the data from the antenna array to perform the localization calculations.

What I Know So Far:

1. BLE Transmissions Use Chirps, Not Continuous Waves:

   • BLE typically uses Gaussian Frequency-Shift Keying (GFSK) modulation, meaning it transmits short packets with frequency hopping.
   • This makes it hard to measure phase shifts directly because there’s no continuous sine wave like in traditional RF localization methods.

2. CTE (Constant Tone Extension) Is Not Available on nRF52832:

   • I know that BLE 5.1 introduced Angle of Arrival (AoA) and Angle of Departure (AoD) techniques, which require CTE (Constant Tone Extension) to add a continuous signal for phase-based localization.
   • However, nRF52832 does NOT support CTE—only nRF52833, nRF52840, and nRF52811 do.
   • Without CTE, I cannot use standard BLE phase-based localization.

3. Alternative BLE Localization Techniques Exist:

   • RSSI-based localization (measuring signal strength) is possible, but it's often inaccurate due to multipath interference and signal fading.
   • Time of Flight (ToF) and RTT (Round Trip Time) are other approaches, but nRF52832 lacks built-in support for these.

My Questions:

1. What is the best localization method for the nRF52832 using BLE? Ideally in the cm range of accuracy, as the operational space to localize this BLE emitting pcb is within a 0.5x0.5x1m area. Most literature online describes localization performed in large rooms, giving higher acceptable margins of error.

   • Should I rely on RSSI-based fingerprinting or another technique?
   • Are there any better ways to get phase-related data from standard BLE packets?

2. Is there a way to generate a "continuous tone" or workaround the lack of CTE on nRF52832?

   • Could I modify the BLE firmware to transmit a pseudo-continuous tone (e.g., by sending custom packets at a fixed frequency)?
   • Would forcing a device into a continuous advertising state help with phase-based methods?

3. Has anyone successfully implemented high-accuracy BLE localization on nRF52832?

   • Any real-world insights, libraries, or firmware modifications that worked?

Any advice, references, or alternative approaches would be greatly appreciated.

Thanks! 

[Elfving]

Hi,

BLE Transmissions Use Chirps, Not Continuous Waves:

BLE uses GFSK, but I am not sure it would be correct to say chirps. Don't mistake it for CSS.

CTE (Constant Tone Extension) Is Not Available on nRF52832

Correct.

Alternative BLE Localization Techniques Exist:

Direction finding, the tools in NDT, and Channel Sounding are your three options here.

I would recommend you to have a look at this webinar we had on the Nordic Distance Toolbox, which explains a bit about the underlying technology, the accuracy, etc. Note the performance section and standard deviation of the different methods mentioned there. 

Direction finding and Channel Sounding operate using CTEs, and NDT is our propriatery solution for this. The accuracy you get with DF and CS depends to a large degree on the algorithm you implement to calculate the angles based on the CTE (this is not something we provide), so it is hard to say something about the accuracy there. The NDT calculate the distance using multiple methods at the same time, so that you can for instance take advantage of RSSI when close, and RTT when further away. I think you also can use the IQ data directly (what you get from the CTE) for your own algorithm if you prefer that. 

The system will operate in a complex medium such as the human body, where signal propagation is highly variable.

Inside a human body? There are a few things like human bodies and water that don't work too well with 2.4GHz signal propagation. People walking around in the warehouse can be enough to make things difficult for you, inside a human body sounds worse. 

What is the best localization method for the nRF52832 using BLE? Ideally in the cm range of accuracy, as the operational space to localize this BLE emitting pcb is within a 0.5x0.5x1m area. Most literature online describes localization performed in large rooms, giving higher acceptable margins of error.

The best method to measure the distance might be a complex combination of direction finding and channel sounding, but it still might be hard to get the accuracy you need. And if you are forced to use the nRF52832 you are a bit limited. NDT is supported on nRF52832 though, have a look at our sample for it. 

So RSSI is surprisingly often used, but is not something I recommend, and is definitely not something that will give you the results you need.

Is there a way to generate a "continuous tone" or workaround the lack of CTE on nRF52832?

The NDT takes advantage of some ways. You could make propriatery solutions for this, but that is not something we "support", as in "help you doing".

Has anyone successfully implemented high-accuracy BLE localization on nRF52832?

I don't have an public overview over this unfortunately. There are a few mentioned here, but not everyone wants to be public. 

I think using the NDT is your best bet, though with the accuracy requirements you mentioned you might also want to look into UWB.

Regards,

Elfving