AoA/AoD direction finding support in nRF52833 SDK v16.0.0 and SoftDevice s140

RE: AoA/AoD direction finding support in nRF52833 SDK v16.0.0 and SoftDevice s140

bjorn-spockeli — Mon, 20 Apr 2020 10:36:10 GMT

HI Adel,

we will add AoA/AoD support in the nRF Connect SDK. Please contact your local Nordic Regional Sales Manager for our Direction Finding roadmap.

Best regards

Bjørn

RE: AoA/AoD direction finding support in nRF52833 SDK v16.0.0 and SoftDevice s140

adel — Mon, 20 Apr 2020 08:59:46 GMT

Hello,

Are there any updates w.r.t. ETA for AoA/AoD support in SoftDevice?

Regards,

Adel

RE: AoA/AoD direction finding support in nRF52833 SDK v16.0.0 and SoftDevice s140

adel — Thu, 20 Feb 2020 14:14:08 GMT

We are still working on it. The idea we are trying to use is essentially similar to what Gazell does: hop between predefined BLE channels on the transmitter's side and do the same on the receiver's size. The main challenge is the synchronization as in our case there is no time synchronization between the two.

Unfortunately I cannot provide more information as I am under NDA.

RE: AoA/AoD direction finding support in nRF52833 SDK v16.0.0 and SoftDevice s140

bjorn-spockeli — Thu, 20 Feb 2020 08:25:31 GMT

Hi Gaurang,

I do not have any update on our Direction Finding evaluation kit. Please contact your local Nordic Regional Sales Manager for our Direction Finding roadmap.

Best regards

Bjørn

RE: AoA/AoD direction finding support in nRF52833 SDK v16.0.0 and SoftDevice s140

Gaurang — Thu, 20 Feb 2020 07:55:57 GMT

bjorn-spockeli,

[quote userid="7571" url="~/f/nordic-q-a/55474/aoa-aod-direction-finding-support-in-nrf52833-sdk-v16-0-0-and-softdevice-s140/224850"]sometime in Q1 2020 should be within reach.[/quote]

so what's the update regarding this I'm working on similar kind of thing thought let's ask for your help here. What about you

adel ?

did developed anything for finding AoA/AoD ? if yes than you mind helping us out.. will be much thankful to you.

Thanks and best regards :)

RE: AoA/AoD direction finding support in nRF52833 SDK v16.0.0 and SoftDevice s140

bjorn-spockeli — Thu, 12 Dec 2019 13:24:15 GMT

Hi Adel,

[quote user="adel"]On the other hand, it would be very handy to utilize some sort of a frequency hopping technique, which would allow nRF52833 FW not to stick to a single BLE channel, but instead utilize many BLE channels in some sequential or random order. Even better, if there would be a mechanism to monitor the collision rate at each BLE channel, so that the busy channels would be utilize less or not utilize at all.[/quote]

The latest SoftDevices har a Quality of Service feature that allows you to monitor the energy level of the BLE channels, i.e. the noise level, see sd_ble_gap_qos_channel_survey_start. So you can use these measurements to determine which channels to avoid when using the RADIO in a SoftDevice Timeslot.

In terms of channel hopping, I think that the the SoftDevice does not clear the RADIO registers when releasing control to a custom application in a timeslot. So I was thinking that you could just use the same channel as the previous BLE event, that way you would always change channel. However, this requires that you're able to do the same on the peer side. If its a Nordic device in both ends, then it shouldnt be a problem.

[quote user="adel"]Are there any examples, white papers, pointers etc. which would help us with the BLE channel hopping & monitoring feature implementation.[/quote]

We do have a proprietary protocol Gazelle that performs channel hopping, you could take a look at that an use it as a reference. See Gazell and Gazell Link Layer User Guide.

Best regards

Bjørn

RE: AoA/AoD direction finding support in nRF52833 SDK v16.0.0 and SoftDevice s140

adel — Thu, 12 Dec 2019 07:15:50 GMT

Apparently the Timeslot feature should probably allow us to implement a co-existance of our custom AoA/AoD protocol with SoftDevice.

In our custom AoA/AoD protocol the simplest would be to use one BLE channel to transmit/receive AoA/AoD packets with CTE extensions and then change the BLE channel by an explicit external configuration request coming from outside of nRF52833 chip.

On the other hand, it would be very handy to utilize some sort of a frequency hopping technique, which would allow nRF52833 FW not to stick to a single BLE channel, but instead utilize many BLE channels in some sequential or random order. Even better, if there would be a mechanism to monitor the collision rate at each BLE channel, so that the busy channels would be utilize less or not utilize at all.

Are there any examples, white papers, pointers etc. which would help us with the BLE channel hopping & monitoring feature implementation.

I see there should be at least the BLE channel utilization mask available from SoftDevice as per devzone.nordicsemi.com/.../how-to-obtained-ble-frequency-hopping-table-from-softdevice

RE: AoA/AoD direction finding support in nRF52833 SDK v16.0.0 and SoftDevice s140

bjorn-spockeli — Wed, 11 Dec 2019 07:45:55 GMT

Hi Adel,

[quote user=""]1. Is AoA/AoD direction finding supported at SDK and/or SoftDevice API level? Could you please pinpoint the relevant sections, if it does.[/quote]

We do not currently have any AoA/AoD support in our SoftDevices. Subsequently we do not have any examples in our nRF5 SKD v16.0.0

[quote user=""]2. If AoA/AoD direction finding is not supported, does it mean that I can still use SoftDevice along with directly programming AoA/AoD related registers in BLE radio.[/quote]

Yes, it is possible to use the SoftDevice Timeslot feature to directly write to the AoA/AoD specific registers of the RADIO peripheral. The Registers are in the Direction finding section of the NRF52833 Product Specification.

We are working on a HW( antenna array that may be interfaced with Nordic DKs) and SW( IQ sampling and direction finding algorithm) implementation for AoA/AoD. I do not have any specific ETA, but sometime in Q1 2020 should be within reach.

Best regards

Bjørn