This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

I am going to use nRF52833 chip with SDK v16.0.0 and SoftDevice s140.

There are couple of questions I would like to clarify:

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

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.

  • Hi Adel,

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

    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

     

    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.

     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

  • 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

  • Hi Adel,

    adel said:
    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.

     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. 

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

     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

  •  bjorn-spockeli,

    sometime in Q1 2020 should be within reach.

    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 :)

  • 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

Related