BLE AOA CTE on AUX_ADV_IND instead of AUX_SYNC_IND

Hello again,

I am messing around with connectionless BLE AOA CTE transmission using NCS 2.4. My setup includes the Siliconlabs BRD4191A which is a 4x4 BLE AOA/AOD dual polarized direction finding antenna array as the receiver. And an NRF52833 device as the CTE AOA transmitter. The Silabs stack includes two connectionless AOA modes, one being the standard BLE periodic/synchronization method attaching the CTE to AUX_SYNC_IND, and a "Silabs proprietary CTE" which attaches the CTE to the extended AUX_ADV_IND PDU instead. They claim that it allows many more transmitter devices to be read from at once by their antenna array, skipping the synchronization step. This fits my use case better if I can make it work. 

As you know the CTE in connectionless AOA can only be appended to a periodic AUX_SYNC_IND or AUX_CHAIN_IND PDUs as per the BLE spec but I am trying to figure out attaching it to the extended AUX_ADV_IND PDU by modifying the zephyr ll_sw BLE controller. Is this something that can be done?

I've found the code handling the extended header manipulation inside zephyr/subsys/bluetooth/controller/ll_sw/ull_adv*.c files. I have succeeded in setting the CTEinfo bit inside the extended header and appending the 8 bit header extension of CTEinfo data. I am now trying to figure out actually enabling the CTE in the radio. I found cte_info_set() inside ull_df.c and it seems pretty intertwined with the AUX_SYNC_IND stuff. Am i going in the right direction? Anyone else try to do something similar? 

I've found a comment of someone asking a similar question here that didn't go anywhere:  CTE can be only appended in AUX_SYNC_IND, So it will be on secondary advertisement channel? 

Thanks,

Ethan

Parents Reply Children
  • +1 am also interested in more information about this. Synchronization is not an option for us due to the high number of tags in the area at once.

    As mentioned, Silabs and others are already appending the CTE to the regular advertising packet on channel 37, 38, 39 and there is a clear use case for higher-bandwidth (tags per second) applications so it is disappointing to see the lack of support from Nordic.

Related