BLE AoA with Active Scanning on nRF5340dk

RE: BLE AoA with Active Scanning on nRF5340dk

PaKa — Tue, 23 Apr 2024 10:50:40 GMT

Production specifications don't get updated with newer parts when they arrive, this is why the nRF5340 is not in the nRF52840 documentation.

For Bluetooth versions, almost all features are optional so the number itself says nothing about what is actually support in the parts. The only mandatory features are the erratas. That means you can qualify a Bluetooth 4.0 HW for Bluetooth 5.4 without adding any Bluetooth 5.4 features except all the Bluetooth 4.1/4.2/5.0/51/5.2/5.3/5.4 erratas.

So recommendation is to use the version number as a minimum gate. if you have version 5.0 you know it won't support direction finding. For version 5.1 you MAY have support and you then need to check the documentation if it is actually supported. This will be true for all Bluetooth features.

RE: BLE AoA with Active Scanning on nRF5340dk

Elfving — Tue, 23 Apr 2024 09:26:02 GMT

[quote user="Harikesh"]

Can I get some clarification on this difference?

[/quote]

Hmm I think the product spec isn't necessarily updated with the newest information about what the SoC can be used for. I see it also says here that it is compatible with multiple of our older SoCs, but the nRF5340 is for instance not mentioned, even though it is obviously compatible with that as well.

[quote user="Harikesh"]Also, does the Bluetooth version signify whether AoA is implemented or not?[/quote]

The nRF52840 is missing the HW features needed to make a Bluetooth compliant Direction finding solution, there is no way to transmit or receive the CTE on this device in a compliant way. The nRF5340, 52833, 52820 and 52811 has this HW. Though due to other limitation eg. RAM I think you can only use the nRF52820 and nRF52811 as a tag.

I think it might also be possible to use nRF52840 for CTEs if you add the CTE to other standard BLE packets, though this isn't BLE compliant and will be something that is hard for us to support for you. It will be up to you to do all this. Though the necessary information on how to do so is in the product spec.

Regards,

Elfving

RE: BLE AoA with Active Scanning on nRF5340dk

Harikesh — Mon, 22 Apr 2024 17:47:32 GMT

Thank you very much for the response!
I see here that in the specifications for nRF52833 the radio peripheral allows for direction finding/AoA/CTE packets, but similarly the nRF52840 specification does not.
I will try testing the packet sniffing with an nRF52833dk and see if that works.
I did have a question regarding nRF52840dk vs nRF52833. I believe nRF52833 implements Bluetooth 5.1 which allows for AoA implementation, and nRF52840dk implements Bluetooth 5.0 from the specification document. However I noticed a mismatch for the Bluetooth version implemented in nRF52840dk:

But in the product specification for nRF52840dk it mentions:

Can I get some clarification on this difference?

Also, does the Bluetooth version signify whether AoA is implemented or not?

RE: BLE AoA with Active Scanning on nRF5340dk

Elfving — Mon, 22 Apr 2024 11:20:18 GMT

[quote user="Harikesh"]

To start with, I'm working with an off-the-shelf AoA system, and I'm trying to emulate the system in my own nrf5340dks.

[/quote]

The default sample we have for AoA in NCS should by default give you a solution that is according to the BLE Spec.

Though there are other products on the market that might not necessarily follow this. One reason for this could be that they are making something propriatary (not defined as BLE) that they only need to work with their own products. I've heard of customers that want to attach CTEs to other packets than they are meant to be on, which should be possible, but probably a lot of work.

So emulating something you've found on the market might not necessarily be that straight forward, or advised.

[quote user="Harikesh"]

While using the nordic BLE Packet sniffer, I noticed the Tag which I assumed to be the one that would send out advertisements is instead sending out only SCAN_REQ packets when receiving Advertisements

[/quote]

It might be that this system is using a connection. We have samples for that as well. Another thing is that it might be using AoD and not AoA. For more info on direction finding in general I would recommend having a look at our WP on it.

[quote user="Harikesh"]This brings me to my next question which is, is the Nordic BLE Packet sniffer capable of sniffing CTE Requests/Responses?[/quote]

Im not sure, though I am finding some sources here claiming that it should work on nRF52833 for instance, though not with the nRF52840, which is what I assume you are using. Looking for ADV_EXT_IND (connectionless) or LL_CTE_REQ & LL_CTE_RSP (connected) might be the best way to find CTE's.

Regards,

Elfving

RE: BLE AoA with Active Scanning on nRF5340dk

Harikesh — Thu, 18 Apr 2024 15:40:45 GMT

Thank you for the quick response!

I think I was a little confused since I'm not familiar with the distinction you are making.

To start with, I'm working with an off-the-shelf AoA system, and I'm trying to emulate the system in my own nrf5340dks.

This seems to suggest that the AoA tag is working as the Scanner and not the Advertiser.

With regards to the advertisement this is an example of a packet that triggers the tag to respond with a SCAN_REQ:

I'm not sure if this indicates using CTE or not, but it looks to me like it's a standard Advertisement. However I know for sure that the Anchor side is receiving CTE data from the tag

This brings me to my next question which is, is the Nordic BLE Packet sniffer capable of sniffing CTE Requests/Responses? I'm asking because when I run the off the shelf AoA system, I don't see any CTE packets, similarly I don't see any packets in the air after running nordic's central/peripheral direction finding samples after connection.

If it is the case that CTE data doesn't get sniffed on the nordic packet sniffer, then it's likely that my off the shelf system is communicating AoA data in a different way and the SCAN_REQ SCAN_RSP is for general advertisements from other devices.

Sorry for introducing this confusion, and thank you in advance!

RE: BLE AoA with Active Scanning on nRF5340dk

Elfving — Thu, 18 Apr 2024 12:24:32 GMT

Hello,

[quote user=""]

1. Is it possible to have a connection based direction_finding_central sample to respond to advertisements with SCAN_REQ instead of CONNECT_IND? And if so where could I find the API for this?

[/quote]

This won't be a BLE compliant solution. Are you sure you want to make something proprietary? I would recommend using the default Bluetooth compliant solution.

For this reason I assume there is no easy go-to API that would make this straight forward for you. Though of course anything is possible.

[quote user=""]

2. If it's not possible, is there another sample I could look into to enable responding to advertisements with a SCAN_REQ?

[/quote]

Are you referring to any advertisement here, even without CTE? I am not sure if I understand.

Regards,

Elfving