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]

For example, the Rx side is set to CONFIG_BT_DF_CONNECTION_CTE_RX=y by default.

However, if I add CONFIG_BT_DF_CONNECTION_CTE_TX=y to the Rx side without changing other code, will it affect the functionality of this sample?

I mean the prj.conf of the Rx side will be like:

CONFIG_BT_DF_CONNECTION_CTE_RX=y 

CONFIG_BT_DF_CONNECTION_CTE_TX=y 

Both RX and TX are set to 'y'. (Yes, I admit, my requirement is somewhat niche, haha. We need a device that can both transmit CTE and receive CTE.)

In other words, by adding this setting, does it merely make the program bulkier by enabling certain functionalities, while actually using these functionalities is something that needs to be done in the main.c file? 

[Simonr]

No, these configs should be set in the prj.conf of the project in Zephyr project. As there are a few things that are run before the main.c in Zephyr projects.

I would rather create multiple builds of similar projects that has separate .conf files instead of trying to do this in main. 

Best regards,

Simon

[Zihao]

OK, thank you for the reply.

I simply wrote the configs in overlay files for AoA and AoD into the main.c and merged the prj.conf files for the RX and TX. The experiments show that I can correctly get both AoA and AoD. I wonder if you are interested in my new case? It's here: Central and Peripheral Integration.

[Simonr]

Glad to hear you were able to get it up and running. Terje is assigned to your new case and will be handling it. You are in good hands. Can we close this case then?

Best regards,

Simon

[Zihao]

OK, thanks！