BLE AoA with Active Scanning on nRF5340dk

[Harikesh]

I've been working on setting up a direction finding tag with the nrf5340dk. I have an AoA locator set up that advertises with ADV_IND packets, and I'd like to setup my tag to respond with SCAN_REQ packets and then have the locator respond again with a SCAN_RSP. To do this, I used the direction_finding_central sample from the SDK to start with. I have a BLE Packet sniffer setup and i noticed that I never see the SCAN_REQ packets despite having Active Scanning enabled, instead I only see CONNECT_IND in response to an advertisement. I realize that this is because this is a connection based direction finding sample, so my question is two part.

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?

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

Thank you in advance.

[Elfving]

Hello,

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?

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.

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

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

Regards,

Elfving

[Harikesh]

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.

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

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!

[Elfving]

Harikesh said:

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.

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.

Harikesh said:

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

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.

Harikesh said:

This brings me to my next question which is, is the Nordic BLE Packet sniffer capable of sniffing CTE Requests/Responses?

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

[Harikesh]

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?

[Elfving]

Harikesh said:

Can I get some clarification on this difference? 

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. 

 

Harikesh said:

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

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