Two bugs or problems report with Direction Finding

[Marcous]

Hello,

In the latest SDK version v1.8.0, I have developed my own project based on direction_finding_connectionless_rx demo. Here are two problems I countered.

1. the RSSI attribute of variable report in the cte_recv_cb function always return the value of -1270. Meanwhile, the RSSI in the recv_cb always returns -127. 

as showed below:

2. In the prj.conf file, if I set variable CONFIG_BT_PER_ADV_SYNC_MAX to 8, the build process goes well. However, it is 10, the error occuried with following log information:

FAILED: zephyr/zephyr_prebuilt.elf zephyr/zephyr_prebuilt.map 
cmd.exe /C "cd . && C:\Users\Marcous\ncs\v1.8.0\toolchain\opt\bin\arm-none-eabi-gcc.exe   zephyr/CMakeFiles/zephyr_prebuilt.dir/misc/empty_file.c.obj -o zephyr\zephyr_prebuilt.elf  -Wl,-T  zephyr/linker_zephyr_prebuilt.cmd  -Wl,-Map=E:/nordic_demo/multi_sync_demo/build/zephyr/zephyr_prebuilt.map  -Wl,--whole-archive  app/libapp.a  zephyr/libzephyr.a  zephyr/arch/common/libarch__common.a  zephyr/arch/arch/arm/core/aarch32/libarch__arm__core__aarch32.a  zephyr/arch/arch/arm/core/aarch32/cortex_m/libarch__arm__core__aarch32__cortex_m.a  zephyr/arch/arch/arm/core/aarch32/mpu/libarch__arm__core__aarch32__mpu.a  zephyr/lib/libc/minimal/liblib__libc__minimal.a  zephyr/lib/posix/liblib__posix.a  zephyr/soc/arm/common/cortex_m/libsoc__arm__common__cortex_m.a  zephyr/soc/arm/nordic_nrf/nrf52/libsoc__arm__nordic_nrf__nrf52.a  zephyr/subsys/bluetooth/common/libsubsys__bluetooth__common.a  zephyr/subsys/bluetooth/host/libsubsys__bluetooth__host.a  zephyr/subsys/bluetooth/controller/libsubsys__bluetooth__controller.a  zephyr/subsys/net/libsubsys__net.a  zephyr/subsys/random/libsubsys__random.a  zephyr/drivers/clock_control/libdrivers__clock_control.a  zephyr/drivers/console/libdrivers__console.a  zephyr/drivers/gpio/libdrivers__gpio.a  zephyr/drivers/serial/libdrivers__serial.a  zephyr/drivers/entropy/libdrivers__entropy.a  zephyr/drivers/timer/libdrivers__timer.a  modules/nrf/lib/fatal_error/lib..__nrf__lib__fatal_error.a  modules/hal_nordic/nrfx/libmodules__hal_nordic__nrfx.a  modules/segger/libmodules__segger.a  -Wl,--no-whole-archive  zephyr/kernel/libkernel.a  zephyr/CMakeFiles/offsets.dir/./arch/arm/core/offsets/offsets.c.obj  -L"c:/users/marcous/ncs/v1.8.0/toolchain/opt/bin/../lib/gcc/arm-none-eabi/9.2.1/thumb/v7e-m/nofp"  -LE:/nordic_demo/multi_sync_demo/build/zephyr  -lgcc  zephyr/arch/common/libisr_tables.a  -mcpu=cortex-m4  -mthumb  -mabi=aapcs  -mfp16-format=ieee  -Wl,--gc-sections  -Wl,--build-id=none  -Wl,--sort-common=descending  -Wl,--sort-section=alignment  -Wl,-u,_OffsetAbsSyms  -Wl,-u,_ConfigAbsSyms  -nostdlib  -static  -no-pie  -Wl,-X  -Wl,-N  -Wl,--orphan-handling=warn && cmd.exe /C "cd /D E:\nordic_demo\multi_sync_demo\build\zephyr && C:\Users\Marcous\ncs\v1.8.0\toolchain\opt\bin\cmake.exe -E echo ""
c:/users/marcous/ncs/v1.8.0/toolchain/opt/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld.exe: zephyr\zephyr_prebuilt.elf section `bss' will not fit in region `SRAM'
c:/users/marcous/ncs/v1.8.0/toolchain/opt/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld.exe: region `SRAM' overflowed by 23801 bytes
collect2.exe: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
FATAL ERROR: command exited with status 1: 'c:\Users\Marcous\ncs\v1.8.0\toolchain\opt\bin\cmake.EXE' --build 'e:\nordic_demo\multi_sync_demo\build'

It seemed somehow the SRAM is overflowed, but I cant figure out how to fix this. Since I set the same variable to 10 with SDK version v1.6.0, and it goes well.

Following is the code I added to the prj.conf file

# prj.conf

CONFIG_BT=y
CONFIG_BT_DEVICE_NAME="DF Connectionless Locator App"

CONFIG_BT_EXT_ADV=y
CONFIG_BT_PER_ADV_SYNC=y
CONFIG_BT_OBSERVER=y

# Enable Direction Finding Feature including AoA and AoD
CONFIG_BT_DF=y
CONFIG_BT_DF_CONNECTIONLESS_CTE_RX=y

CONFIG_BT_CTLR_ADV_EXT=y
CONFIG_BT_CTLR_SYNC_PERIODIC=y
# Enable Direction Finding Feature including AoA and AoD
CONFIG_BT_CTLR_DF=y
CONFIG_BT_CTLR_DF_ANT_SWITCH_TX=n

CONFIG_BT_PER_ADV_SYNC_MAX=10

CONFIG_UART_ASYNC_API=y
CONFIG_NRFX_UARTE0=y
CONFIG_SERIAL=y
CONFIG_CONSOLE=y
CONFIG_UART_CONSOLE=y
CONFIG_HEAP_MEM_POOL_SIZE=2048

and here is the code in file overlay-aod.conf

# Disable AoD Feature (antenna switching) in Tx mode
CONFIG_BT_CTLR_DF_ANT_SWITCH_RX=n
CONFIG_HEAP_MEM_POOL_SIZE=2048

By the way, I also tink a little bit with the zephyr/subsys/bluetooth/controller/hci/hci.c and zephyr/subsys/bluetooth/controller/ll_sw/ull.c following the github zephyr upstream main branch Bluetooth: controller: ULL: fix dequeue of IQ samples reports. 

[Saleh]

Hi

Before giving any answer, please note nRF SDK is based on a replica of Zephyr project and necessarily the last updates of Zephyr are NOT reflected in this replica. In other side, Direction_Finding is a new feature and is under continues development, so my personal advice is to use main upstream of Zephyr instead of nRF SDK to test this feature.

Here is the direction finding example of nRF SDK repo (I think you are using this):

https://github.com/nrfconnect/sdk-zephyr/tree/main/samples/bluetooth/direction_finding_connectionless_rx

And this is the example directly coming from Zephyr repo:

https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/bluetooth/direction_finding_connectionless_rx

---

Now lwt's back to your question:

1- This problem has been solved in the latest version of Zephyr, by switching to the main upstream it will be solved.

2- CONFIG_BT_PER_ADV_SYNC_MAX is used to configure the maximum number of transmitter devices that a receiver can receive data from them simultaneously. There is a memory reserved in order to store received data from these transmitter, so by increasing this number, capacity of the required memory increases. In addition to this config, there is another one called "CONFIG_BT_CTLR_DF_PER_SCAN_CTE_NUM_MAX" which also affect on required memory.

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/kconfig/CONFIG_BT_CTLR_DF_PER_SCAN_CTE_NUM_MAX.html

https://docs.zephyrproject.org/latest/reference/kconfig/CONFIG_BT_CTLR_DF_PER_SCAN_CTE_NUM_MAX.html

Change these two configuration to see how they affect on the memory.

Regards,

Saleh

[Marcous]

Thanks, Saleh.

I am now concentrate on problem 2, and I do as you suggested that add a sentence CONFIG_BT_CTLR_DF_PER_SCAN_CTE_NUM_MAX = 16 to the prj.conf file. Sadly I saw no improvement.

And as I mentioned, when CONFIG_BT_PER_ADV_SYNC_MAX is set to be 8, then build memory result is like this:

When it is 4, the result is like:

When it is set to be 1(default value), the result is like:

It is weird because the memory SRAM required increases dramatically with the increase of variable BT_PER_ADV_SYNC_MAX, since I havn't change any other code. And with the change of CONFIG_BT_CTLR_DF_PER_SCAN_CTE_NUM_MAX from 1 to 16, there is no significant good effect. 

I need to create synchronization with about 10 devices simultaneously. Set the variable to 8 will cause some assertion fail while running, herhaps due to the limited SRAM remained. So I am running it with CONFIG_BT_PER_ADV_SYNC_MAX = 5

[Saleh]

Here you can see how CONFIG_BT_PER_ADV_SYNC_MAX affect on the memory usage:

https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/bluetooth/controller/ll_sw/ull_df_types.h#L31

it is multiplied by CONFIG_BT_CTLR_DF_PER_SCAN_CTE_NUM_MAX and "2". If you have not enabled "CTE chain signals", then you can set CONFIG_BT_CTLR_DF_PER_SCAN_CTE_NUM_MAX to "1" in order to increase the CONFIG_BT_PER_ADV_SYNC_MAX value.

To send only one CTE per each periodic interval, set "cte_count" variable of "bt_df_adv_cte_tx_param" to 1 at transmitter side, then you can set CONFIG_BT_CTLR_DF_PER_SCAN_CTE_NUM_MAX to 1 at receiver side.

[Marcous]

It works well!  Thank you so much! 

I forgot to set the CONFIG_BT_CTLR_DF_PER_SCAN_CTE_NUM_MAX in the nrf52833dk_nrf52833.conf, just set it to be 1 in the prj.conf. And maybe the conflict value make it to be the default value, which is 16. So previously it is not working.

I now set CONFIG_BT_CTLR_DF_PER_SCAN_CTE_NUM_MAX to be 1 and with the CONFIG_BT_PER_ADV_SYNC_MAX = 10, it only consume 25.68% SRAM, better now!