The official demo of AoA/AoD shows an error about cte_report_cb

[Zihao]

I got an error while building the direction finding demo In nRF Connect:

../src/main.c:254:10: error: 'const struct bt_conn_cb' has no member named 'cte_report_cb'
254 | .cte_report_cb = cte_recv_cb,
| ^~~~~~~~~~~~~
../src/main.c:254:26: warning: initialization of '_Bool (*)(struct bt_conn *, struct bt_le_conn_param *)' from incompatible pointer type 'void (*)(struct bt_conn *, const struct bt_df_conn_iq_samples_report *)' [-Wincompatible-pointer-types]
254 | .cte_report_cb = cte_recv_cb,
| ^~~~~~~~~~~
../src/main.c:254:26: note: (near initialization for 'bt_conn_cb_conn_callbacks.le_param_req')
[27/118] Building C object zephyr/subsys/bluetooth/host/CMakeFiles/subsys__bluetooth__host.dir/hci_core.c.obj
ninja: build stopped: subcommand failed.
FATAL ERROR: command exited with status 1: 'C:\ncs\toolchains\c57af46cb7\opt\bin\cmake.EXE' --build 'd:\AoAAoD\direction_finding_central\build'

* The terminal process terminated with exit code: 1.
* Terminal will be reused by tasks, press any key to close it.

In VSCode:

I found two similar problems in Nordic DevZone, but it doesn't seem to be solved:

Direction_finding_central test

Problems building Direction_finding_central sample

Other than that, I didn't find any helpful posts using Google.

I am a beginner in BLE and just finished the basic Bluetooth course in Nordic a few days ago. So, I don't think I had any problems with my environment, In that I was able to run all the demos In Bluetooth Low Energy Fundamentals.

I directly built the demo named direction finding central without any modification, because I did not see any information in the document that necessary to be changed to build successfully. Note that I just built it, it doesn't involve flash, so I don't think it's hardware related.

In contrast, the associated demo called direction finding peripheral was build successfully without any modification.

My operating system is Windows 10.
My nRF Connect SDK is v2.5.1.in VSCode.
My Zephyr version: 3.4.99
I don't know if this is an official Sample Bug, because I'm just getting started with embedded development. Is there any information that can help me?

[Simonr]

Hi again

Today I got some feedback from the experts internally on Direction Finding that should be helpful.

Please note that for the Direction Finding receive function (RX sample and Central sample) the only certified solution is on NCS 2.2.0, and newer versions of this sample are not certified nor guaranteed to work. Please only use the samples in the nRF folder of NCS, and not the ones in the Zephyr folder. The nRF folder samples have been build tested and should work as expected if no changes have been made to the SDK files.

Regarding your latest issue. The error you're seeing here points to CTE RX not being supported. Hav you by chance added the overlay-aod.conf to your sample when building it? This will disable the AoA feature and thus also the chance to do antenna switching in RX mode.

Best regards,

Simon

[Zihao]

Hi,

1） Sadly, even with the ncs 2.2.0, I still haven't been able to successfully build the official connectionless tx sample and connectionless rx sample without any modification...
Without any modification, the tx sample can't find bt_df_set_adv_cte_tx_param, while at the same time, the rx sample can't find bt_df_per_adv_sync_cte_rx_enable.
2） No, I didn't add overlay-aod.conf to my sample. I believe the problem still related to 1), which causes these two projects to report err-134 during runtime. Despite editing the SDK or adding CONFIG_BT_DF_CONNECTIONLESS_CTE_RX = y to the prj.conf to allow these projects to be built and flashed to the board successfully, there are still some configurations related to bt_df_set_adv_cte_tx_param and bt_df_per_adv_sync_cte_rx_enable that I haven't set properly, I think. The errors seem to correspond to these two functions:
Update CTE params...failed (err -134) ----> bt_df_set_adv_cte_tx_param
Enable receiving of CTE...failed (err -134) ----> bt_df_per_adv_sync_cte_rx_enable

I trust that ncs 2.2.0 is reliable. Therefore, I wonder if there's an issue with where or how I downloaded the SDK?
First, I downloaded nRF Connect SDK for Desktop v4.3.0 on my Windows 10. Then, I installed Toolchain Manager v1.3.0.

Next, I opened Toolchain Manager, found nRF Connect SDK v2.2.0, and installed it.

Afterwards, I opened VSCode with nRF Connect for VS Code Extension Pack v2023.11.3 installed. (Would the version of this Extension Pack have any adverse effects?) On the Welcome box, I set the toolchain and SDK to v2.2.0.

Then, I clicked "Create a new application" and searched for "direction finding" to find the two connectionless samples in nrf:

With that, the creation of the official projects was complete. Then I attempted to build them. I chose nRF52833dk_nrf52833 Nordic boards as the board and prj.conf as the configuration. Additionally, before building the tx sample, I added overlay-aoa.conf to the Kconfig fragments.

However, neither of them were successfully built...

Meanwhile, in the rx sample, CONFIG_BT_DF_CTE_RX_AOA doesn't seem to have been set successfully, as ant_patterns is grayed out in the main.c.

Did I do anything wrong? (Sorry, even though I've been stuck on this issue for half a month, I still feel I'm new to BLE COTS devices...)
Looking forward to your reply! Thanks!

Yours,
Zihao

[Zihao]

Hi,

Today I ran this sample successfully! Here's the thing: the nrf52833dk_nrf52833.conf in the board seems to be correct, but I don't know why it didn't work as expected. So, I copied all the code from nrf52833dk_nrf52833.conf into prj.conf. Subsequently, both the build and flash processes went smoothly, and CTE seemed fine too. Finally, I can start my project development.

At the same time, I'd like to ask, will this solution have any other adverse effects?

[Simonr]

Hi

I got some details on why this didn't work for you and the other similar cases today from our developer:

In the build command, -DCONF_FILE=<file> was used, which prevents auto-discovery of a board specific Kconfig file in /boards. If that option is used, all the Kconfig files also must be provided in this option. Just running west build -b nrf52833dk_nrf52833 is a simpler way of doing it. That way the prj.conf is used by default, and the board specific Kconfig discovery will happen. 

Your method shouldn't have any unwanted effects either for that matter.

Best regards,

Simon

[Zihao]

Great! Thank you for disturbing you for more than half a month. I'm about to start the development of my project!