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

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

Zihao — Thu, 06 Jun 2024 11:28:16 GMT

OK, thanks！

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

Simonr — Thu, 06 Jun 2024 05:33:24 GMT

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

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

Zihao — Wed, 05 Jun 2024 23:55:09 GMT

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.

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

Simonr — Mon, 03 Jun 2024 07:32:55 GMT

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

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

Zihao — Sat, 01 Jun 2024 14:46:50 GMT

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?

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

Zihao — Sat, 01 Jun 2024 02:19:46 GMT

Hello Simonr,
Today, I encountered another problem related to prj.conf. Can I place the prj.conf configuration in the main.c? For example, if I want to set:

CONFIG_BT_CTLR_DF_ANT_SWITCH_TX=n
CONFIG_BT_CTLR_DF_ADV_CTE_TX=n

I will set in main.c like:

#define CONFIG_BT_CTLR_DF_ANT_SWITCH_TX=n
#define CONFIG_BT_CTLR_DF_ADV_CTE_TX=n

Is this different from using prj.conf?
Just to confirm, we developed the project this way but did not get the expected results. I don't know if this is the problem.
The reason for this is that we need to change the prj.conf settings for different code segments within the same project , so we thought it would be convenient if these could be changed directly in the main.c.
Or, may I ask if there is a more official way to change the settings in prj.conf more flexibly?

Thanks!

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

Zihao — Wed, 24 Apr 2024 13:44:02 GMT

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

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

Simonr — Wed, 24 Apr 2024 13:29:27 GMT

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

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

Zihao — Wed, 24 Apr 2024 05:16:25 GMT

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?

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

Zihao — Tue, 23 Apr 2024 00:27:35 GMT

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

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

Simonr — Mon, 22 Apr 2024 09:17:44 GMT

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

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

Zihao — Sat, 20 Apr 2024 14:19:38 GMT

Hi Simon,

Firstly, thank you for your patient response, and I apologize for the continued disturbance.

I added CONFIG_BT_LL_SW_SPLIT=y to prj.conf, and then prj.conf stopped showing errors or warnings, whether it was in connection samples or connectionless samples. This allowed me to successfully build the official samples without modifying any SDK files.

However, after flashing to my nRF52833DK, I still encountered issues with the official samples, both in connection and connectionless samples. During runtime, all these issues seem to be related to CTE configuration, resulting in err - 134.

connection center log:

[DEVICE]: 78:11:DC:C2:89:2F (public), AD evt type 0, AD data len 24, RSSI -90
[AD]: 1 data_len 1
[AD]: 22 data_len 19
[DEVICE]: E5:2F:FC:5A:F2:67 (random), AD evt type 0, AD data len 8, RSSI -90
[AD]: 1 data_len 1
[AD]: 39 data_len 3
Connected: E5:2F:FC:5A:F2:67 (random)
Enable receiving of CTE...
[00:00:27.216,369] <wrn> bt_df: bt_df_set_conn_cte_rx_enable: Receiving Constant Tone Extensions is not supported
failed (err -134)
Disconnected: E5:2F:FC:5A:F2:67 (random) (reason 0x3e)
Scanning successfully started
[DEVICE]: 32:68:CB:2F:B7:CC (random), AD evt type 3, AD data len 31, RSSI -68
[DEVICE]: 2B:ED:54:17:9C:5B (random), AD evt type 3, AD data len 31, RSSI -74
[DEVICE]: 7C:27:BC:D1:9D:2E (public), AD evt type 3, AD data len 19, RSSI -76
[DEVICE]: 78:11:DC:C2:89:2F (public), AD evt type 0, AD data len 24, RSSI -90
[AD]: 1 data_len 1
[AD]: 22 data_len 19
[DEVICE]: 78:11:DC:C2:89:2F (public), AD evt type 4, AD data len 28, RSSI -89
[DEVICE]: 59:D4:15:36:74:8F (random), AD evt type 0, AD data len 31, RSSI -86

For the direction finding connectionless tx, it also reported failed (err -134) After copying a fresh one of the official sample and trying in different NCS environments, I still encountered the same error, while the connection tx seems to be working fine.

Of course, currently our team leans more towards using the connectionless sample. The logs for connectionless tx and rx are as follows: (Note that both logs are from the official sample without any modifications, except for adding CONFIG_BT_LL_SW_SPLIT=y in the prj.conf of the connectionless rx sample.)

--------------------------------------------------------------------

connectionless tx building log:
Building direction_finding_connectionless_tx_2
C:\Windows\system32\cmd.exe /d /s /c "west build --build-dir d:/AoAoD3/direction_finding_connectionless_tx_2/build d:/AoAoD3/direction_finding_connectionless_tx_2 --pristine --board nrf52833dk_nrf52833 --no-sysbuild -- -DNCS_TOOLCHAIN_VERSION=NONE -DCONF_FILE=d:/AoAoD3/direction_finding_connectionless_tx_2/prj.conf -DEXTRA_CONF_FILE=overlay-aoa.conf -DBOARD_ROOT=d:/aoaod3/direction_finding_connectionless_tx_2"

-- west build: generating a build system
Loading Zephyr default modules (Zephyr base).
-- Application: D:/AoAoD3/direction_finding_connectionless_tx_2
-- CMake version: 3.21.0
-- Found Python3: D:/ncs/toolchains/cf2149caf2/opt/bin/python.exe (found suitable version "3.9.13", minimum required is "3.8") found components: Interpreter
-- Cache files will be written to: C:/ncs/v2.5.1/zephyr/.cache
-- Zephyr version: 3.4.99 (C:/ncs/v2.5.1/zephyr)
-- Found west (found suitable version "1.2.0", minimum required is "0.14.0")
-- Board: nrf52833dk_nrf52833
-- Found host-tools: zephyr 0.16.5 (D:/ncs/toolchains/cf2149caf2/opt/zephyr-sdk)
-- Found toolchain: zephyr 0.16.5 (D:/ncs/toolchains/cf2149caf2/opt/zephyr-sdk)
-- Found Dtc: D:/ncs/toolchains/cf2149caf2/opt/bin/dtc.exe (found suitable version "1.4.7", minimum required is "1.4.6")
-- Found BOARD.dts: C:/ncs/v2.5.1/zephyr/boards/arm/nrf52833dk_nrf52833/nrf52833dk_nrf52833.dts
-- Found devicetree overlay: D:/AoAoD3/direction_finding_connectionless_tx_2/boards/nrf52833dk_nrf52833.overlay
-- Generated zephyr.dts: D:/AoAoD3/direction_finding_connectionless_tx_2/build/zephyr/zephyr.dts
-- Generated devicetree_generated.h: D:/AoAoD3/direction_finding_connectionless_tx_2/build/zephyr/include/generated/devicetree_generated.h
-- Including generated dts.cmake file: D:/AoAoD3/direction_finding_connectionless_tx_2/build/zephyr/dts.cmake

warning: Experimental symbol BT_DF is enabled.

Parsing C:/ncs/v2.5.1/zephyr/Kconfig
Loaded configuration 'C:/ncs/v2.5.1/zephyr/boards/arm/nrf52833dk_nrf52833/nrf52833dk_nrf52833_defconfig'
Merged configuration 'd:/AoAoD3/direction_finding_connectionless_tx_2/prj.conf'
Merged configuration 'D:/AoAoD3/direction_finding_connectionless_tx_2/overlay-aoa.conf'
Configuration saved to 'D:/AoAoD3/direction_finding_connectionless_tx_2/build/zephyr/.config'
Kconfig header saved to 'D:/AoAoD3/direction_finding_connectionless_tx_2/build/zephyr/include/generated/autoconf.h'
-- Found GnuLd: d:/ncs/toolchains/cf2149caf2/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd.exe (found version "2.38")
-- The C compiler identification is GNU 12.2.0
-- The CXX compiler identification is GNU 12.2.0
-- The ASM compiler identification is GNU
-- Found assembler: D:/ncs/toolchains/cf2149caf2/opt/zephyr-sdk/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc.exe
-- Configuring done
-- Generating done
-- Build files have been written to: D:/AoAoD3/direction_finding_connectionless_tx_2/build
-- west build: building application
[2/172] Generating include/generated/version.h
-- Zephyr version: 3.4.99 (C:/ncs/v2.5.1/zephyr), build: v3.4.99-ncs1-1
[172/172] Linking C executable zephyr\zephyr.elf
Memory region Used Size Region Size %age Used
FLASH: 102944 B 512 KB 19.64%
RAM: 19872 B 128 KB 15.16%
IDT_LIST: 0 GB 2 KB 0.00%
* Terminal will be reused by tasks, press any key to close it.

connectionless rx building log:
Building direction_finding_connectionless_rx
C:\Windows\system32\cmd.exe /d /s /c "west build --build-dir d:/AoAoD3/direction_finding_connectionless_rx/build d:/AoAoD3/direction_finding_connectionless_rx --pristine --board nrf52833dk_nrf52833 --no-sysbuild -- -DNCS_TOOLCHAIN_VERSION=NONE -DBOARD_ROOT=d:/aoaod3/direction_finding_connectionless_tx_2;d:/aoaod3/direction_finding_connectionless_rx;d:/aoaod3/direction_finding_connectionless_tx_1;d:/aoaod3/direction_finding_central;d:/aoaod3/direction_finding_peripheral;d:/aoaod3/direction_finding_connectionless_tx -DCACHED_CONF_FILE=d:/AoAoD3/direction_finding_connectionless_rx/prj.conf -DDTC_OVERLAY_FILE=d:/AoAoD3/direction_finding_connectionless_rx/boards/nrf52833dk_nrf52833.overlay"

-- west build: generating a build system
Loading Zephyr default modules (Zephyr base).
-- Application: D:/AoAoD3/direction_finding_connectionless_rx
-- CMake version: 3.21.0
-- Found Python3: D:/ncs/toolchains/cf2149caf2/opt/bin/python.exe (found suitable version "3.9.13", minimum required is "3.8") found components: Interpreter
-- Cache files will be written to: C:/ncs/v2.5.1/zephyr/.cache
-- Zephyr version: 3.4.99 (C:/ncs/v2.5.1/zephyr)
-- Found west (found suitable version "1.2.0", minimum required is "0.14.0")
-- Board: nrf52833dk_nrf52833
-- Found host-tools: zephyr 0.16.5 (D:/ncs/toolchains/cf2149caf2/opt/zephyr-sdk)
-- Found toolchain: zephyr 0.16.5 (D:/ncs/toolchains/cf2149caf2/opt/zephyr-sdk)
-- Found Dtc: D:/ncs/toolchains/cf2149caf2/opt/bin/dtc.exe (found suitable version "1.4.7", minimum required is "1.4.6")
-- Found BOARD.dts: C:/ncs/v2.5.1/zephyr/boards/arm/nrf52833dk_nrf52833/nrf52833dk_nrf52833.dts
-- Found devicetree overlay: d:/AoAoD3/direction_finding_connectionless_rx/boards/nrf52833dk_nrf52833.overlay
-- Generated zephyr.dts: D:/AoAoD3/direction_finding_connectionless_rx/build/zephyr/zephyr.dts
-- Generated devicetree_generated.h: D:/AoAoD3/direction_finding_connectionless_rx/build/zephyr/include/generated/devicetree_generated.h
-- Including generated dts.cmake file: D:/AoAoD3/direction_finding_connectionless_rx/build/zephyr/dts.cmake

warning: Experimental symbol BT_DF is enabled.

warning: Experimental symbol BT_LL_SW_SPLIT is enabled.

Parsing C:/ncs/v2.5.1/zephyr/Kconfig
Loaded configuration 'C:/ncs/v2.5.1/zephyr/boards/arm/nrf52833dk_nrf52833/nrf52833dk_nrf52833_defconfig'
Merged configuration 'd:/AoAoD3/direction_finding_connectionless_rx/prj.conf'
Configuration saved to 'D:/AoAoD3/direction_finding_connectionless_rx/build/zephyr/.config'
Kconfig header saved to 'D:/AoAoD3/direction_finding_connectionless_rx/build/zephyr/include/generated/autoconf.h'
-- Found GnuLd: d:/ncs/toolchains/cf2149caf2/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd.exe (found version "2.38")
-- The C compiler identification is GNU 12.2.0
-- The CXX compiler identification is GNU 12.2.0
-- The ASM compiler identification is GNU
-- Found assembler: D:/ncs/toolchains/cf2149caf2/opt/zephyr-sdk/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc.exe
-- Configuring done
-- Generating done
-- Build files have been written to: D:/AoAoD3/direction_finding_connectionless_rx/build
-- west build: building application
[2/193] Generating include/generated/version.h
-- Zephyr version: 3.4.99 (C:/ncs/v2.5.1/zephyr), build: v3.4.99-ncs1-1
[193/193] Linking C executable zephyr\zephyr.elf
Memory region Used Size Region Size %age Used
FLASH: 78352 B 512 KB 14.94%
RAM: 21448 B 128 KB 16.36%
IDT_LIST: 0 GB 2 KB 0.00%
* Terminal will be reused by tasks, press any key to close it.

--------------------------------------------------------------------------

(I'm sorry, I'm not sure why, but I couldn't successfully use "insert code" to insert my log, so I just pasted it here directly...)

There are several cases on DevZone regarding err-134, but the latest one is from two years ago which is too old, and I haven't found any helpful solutions. I've checked the build logs for both, but at my level of knowledge, I haven't identified any significant issues.

Is there anything unusual in the logs that you can see?

About AoD:

Yes indeed, AoD requires the beacon to have an antenna array. However, when we run AoD, the center becomes the beacon, and vice versa. This is indeed a bit niche since we do not do localization. Thank you for your concern!

Yours,

Zihao

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

Simonr — Fri, 19 Apr 2024 09:00:57 GMT

2. Hi, what Bluetooth stack have you set the application to use here? Seems like you're trying to use some Zephyr specific configs on the Nordic SoftDevice link layer. Can you upload the full build log again and try setting https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/kconfig/index.html#CONFIG_BT_LL_SW_SPLIT to ensure you enable the Zephyr stack? Please upload the full build log so we can get a better look.

3. For AoD to work, the beacon will also need to have an antenna array, if not only AoA will be possible to use since the AoD (Angle of Departure) would all come from the same exact antenna...

Best regards,

Simon

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

Zihao — Thu, 18 Apr 2024 12:39:37 GMT

Hi again,

2. I noticed the missing dependencies earlier, so I added the following code to prj.conf:

CONFIG_BT_HCI=y
CONFIG_BT_CTLR=y
CONFIG_BT_CTLR_DF_CTE_RX_SUPPORT=y
CONFIG_BT_HCI_HOST=y
CONFIG_BT_RPC_STACK=y

However, it showed me the following error:

CONFIG_BT_CTLR_DF_CTE_RX_SUPPORT was assigned the value y, but got the value n. Missing dependencies:
BT_HCI

Symbol CONFIG_BT_HCI_HOST cannot be set (has no prompt)

Today I tried creating a new overlay, but the result was the same as adding these codes directly into the prj.conf, and it didn't work.

Yes, I agree that shouldn't be it for just a sample project. All I want to do is successfully run this sample and obtain the IQ. I built this sample today on another PC with Mac OS, but the errors encountered during the build process are the same as in this case on Windows10.

3. Yes, haha, our requirement is a little bit uncommon because we only need AoA and AoD and we don't do direction finding. We only need the central device to have an antenna array because we only need AoA from the central device and AoD from the tag.

Thanks for your relpy!

Yours,

Zihao

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

Simonr — Thu, 18 Apr 2024 09:11:12 GMT

2. Check out the documentation page for CONFIG_BT_DF_CONNECTIONLESS_CTE_RX and make sure all the dependencies for it is in place, as it depends on some other configs to be enabled correctly. Also, it could be overwritten in a .overlay file on your end, but that shouldn't be it for just a sample project.

3. Okay, what do you mean by that you need both the AoA and AoD values for your application? Direction Finding is usually based on either AoA or AoD, as it depends on whether the central or beacon should have the antenna array. If you want to implement both, then both devices will need an antenna array. But I don't see the use case for that to be honest.

Best regards,

Simon

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

Zihao — Wed, 17 Apr 2024 04:04:04 GMT

hi,

Thank you for your reply.

1) I understand that I will not update other cases about BLE DF samples.

2) Yes, This CONFIG_BT_DF_CONNECTIONLESS_CTE_RX should be set in the .conf file, not the driver/ library.c files.
But as I mentioned before, if I set CONFIG_BT_DF_CONNECTIONLESS_CTE_RX = y directly in .conf, VSCode will prompt "in build: n ", which will result in the project not even being built successfully. I don't know how to successfully set this option, so I try modifying it directly in .c files so that it can at least be built. As a result, the transmitter successfully sends AOA CTE. However, during reception, the receiver reports 'Enable receiving of CTE... failed (err-134).

[DEVICE]: 29:13:AC:D3:F4:DD (random), AD evt type 3, Tx Pwr: 127, RSSI -53  C:0 S:0 D:0 SR:0 E:0 Prim: LE 1M, Secn: No packets, Interval: 0x0000 (0 ms), SID: 255
[DEVICE]: 2E:A1:15:C5:BB:B7 (random), AD evt type 3, Tx Pwr: 127, RSSI -91  C:0 S:0 D:0 SR:0 E:0 Prim: LE 1M, Secn: No packets, Interval: 0x0000 (0 ms), SID: 255
PER_ADV_SYNC[0]: [DEVICE]: 07:55:BF:A2:37:85 (random) synced, Interval 0x0780 (2400 ms), PHY LE 2M
PER_ADV_SYNC[0]: [DEVICE]: 07:55:BF:A2:37:85 (random) sync terminated
success. Periodic sync established.
Enable receiving of CTE...
failed (err -134)
Scan disable...Success.
Waiting for periodic sync lost...
Periodic sync lost.
Start scanning...success
Waiting for periodic advertising...
[DEVICE]: 7E:DD:2C:61:3A:00 (random), AD evt type 2, Tx Pwr: 127, RSSI -65  C:0 S:1 D:0 SR:0 E:0 Prim: LE 1M, Secn: No packets, Interval: 0x0000 (0 ms), SID: 255

I knew it was wrong, but I was just trying.

3) I have discussed our project again with our team, and it is not necessary to do it on connected DF samples. we find that using the connectionless DF samples is acceptable. We just need the AoA values of a center with an array and the AoD values of a becon.
However, considering that connectionless samples seem simpler to implement and further develop, we are currently leaning towards connectionless samples.

Thanks again!

Best regards,
Zihao

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

Simonr — Tue, 16 Apr 2024 08:15:47 GMT

Hi again

Sorry about the late reply, but I had some other pressing issues to tend to. Thank you for your patience

This CONFIG_BT_DF_CONNECTIONLESS_CTE_RX should be set in your .conf file, not the driver/library .c files. Also, I would please ask you to stop updating every other Direction Finding case you can find, as it is more disruptive to our workflow than helpful to you I think. We will handle this issue in this case, and it will be easier to have an overview if we stick to it here rather than on multiple older cases.

Just to confirm, the follow-up you're looking for is to be able to start working on the connected DF samples, correct?

Best regards,

Simon

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

Zihao — Fri, 12 Apr 2024 10:22:50 GMT

Hi,

When I modified direction.c and hci_core.h, although rx was able to build successfully, it would cause problems in tx.
So I add the code when building rx side and remove them when building tx side. It's not a very convenient solution, but at least I can start working on connectionless sample now.
Thanks again, but I'm still looking for a follow-up on this issue.

Yours,

Zihao

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

Zihao — Fri, 12 Apr 2024 09:47:30 GMT

One more thing to add.
I just added one line of direction.c and hci_core.h in Zephyr, and the build is successful.

#define CONFIG_BT_DF_CONNECTIONLESS_CTE_RX

But the connection-based sample is too complex for me to solve with a solution like this. Besides, I don't know if this has any additional effects on my program.

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

Zihao — Fri, 12 Apr 2024 08:58:01 GMT

Hi Simon

Thanks for your reply. But I now think this issue is not related to the version. I have also built this project on my end with the same version as yours(include NCS and Zephyr), but still encountered this issue.

I think I can make this problem clearer. I didn't notice the warning before:

warning: BT_DF_CONNECTION_CTE_RX (defined at C:/ncs/v2.5.1/zephyr/subsys/bluetooth/host/Kconfig:847,
subsys/bluetooth\host/Kconfig:847) was assigned the value 'y' but got the value 'n'. Check these
unsatisfied dependencies: (((!BT_CTLR || BT_CTLR_DF_CTE_RX_SUPPORT) && BT_DF && BT_HCI_HOST &&
BT_RPC_STACK) || ((!BT_CTLR || BT_CTLR_DF_CTE_RX_SUPPORT) && BT_DF && BT_HCI_HOST && BT_HCI && BT))
(=n). See docs.zephyrproject.org/.../kconfig.html and/or
look up BT_DF_CONNECTION_CTE_RX in the menuconfig/guiconfig interface. The Application Development
Primer, Setting Configuration Values, and Kconfig - Tips and Best Practices sections of the manual
might be helpful too.


warning: BT_DF_CONNECTION_CTE_REQ (defined at
C:/ncs/v2.5.1/zephyr/subsys/bluetooth/host/Kconfig:861, subsys/bluetooth\host/Kconfig:861) was
assigned the value 'y' but got the value 'n'. Check these unsatisfied dependencies:
((BT_DF_CONNECTION_CTE_RX && BT_DF && BT_HCI_HOST && BT_RPC_STACK) || (BT_DF_CONNECTION_CTE_RX &&
BT_DF && BT_HCI_HOST && BT_HCI && BT)) (=n). See
docs.zephyrproject.org/.../kconfig.html and/or look up
BT_DF_CONNECTION_CTE_REQ in the menuconfig/guiconfig interface. The Application Development Primer,
Setting Configuration Values, and Kconfig - Tips and Best Practices sections of the manual might be
helpful too.

I am a beginner in BLE. When I studied the Nordic BLE course, my understanding was:
If I set

CONFIG_BT_DF_CONNECTION_CTE_RX=y
CONFIG_BT_DF_CONNECTION_CTE_REQ=y

in prj.conf,

but didn't set any options in nrf52833dk_nrf52833.conf, then the final settings will be y. Actually, the official sample settings are same as mine(Because I just want to build and flash them without any modification.).

However, in build it's 'n ' instead of 'y'.

The same question is occurred in the direction finding connectionless rx sample on my end.

It's like:

CONFIG_BT_DF_CONNECTIONLESS_CTE_RX=y In build:n

Also, I just tried to build the official sample without any modification.

In Zephyr, the BLE direction finding code is wrapped in:

#if defined(CONFIG_BT_DF_CONNECTIONLESS_CTE_RX)
......
#endif

So these code is not recognized when compiling.

Then the error occureed:

D:/AoAoD2/direction_finding_connectionless_rx/src/main.c:249: undefined reference to `bt_df_per_adv_sync_cte_rx_enable'
D:/AoAAoD/direction_finding_central/src/main.c:254:10: error:  'const struct bt_conn_cb' has no member named 'cte_report_cb'

VSCode tells me about Missing dependencies which led to this error:

CONFIG_BT_DF_CONNECTIONLESS_CTE_RX was assigned the value y, but got the value n. Missing dependencies:
((!BT_CTLR || BT_CTLR_DF_CTE_RX_SUPPORT) && BT_DF && BT_HCI_HOST && BT_RPC_STACK) || ((!BT_CTLR || BT_CTLR_DF_CTE_RX_SUPPORT) && BT_DF && BT_HCI_HOST && BT_HCI && BT)
Support for receive of CTE in connectionless mode

Type: bool

Value: n

Enable support for reception and sampling of Constant Tone Extension in connectionless mode.

Enable support for reception and sampling of Constant Tone Extension in connectionless mode.

I have tried to add them in prj.conf like:

CONFIG_BT_HCI=y
CONFIG_BT_CTLR=y
CONFIG_BT_CTLR_DF_CTE_RX_SUPPORT=y
CONFIG_BT_HCI_HOST=y
CONFIG_BT_RPC_STACK=y

Then it show me that:

CONFIG_BT_CTLR_DF_CTE_RX_SUPPORT was assigned the value y, but got the value n. Missing dependencies:
BT_HCI

Symbol CONFIG_BT_HCI_HOST cannot be set (has no prompt)

So now I'm confused and don't know how to solve the missing dependencies problem.

Any useful information would be appreciated, thanks!

Yours,

Zihao

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

Simonr — Thu, 11 Apr 2024 11:53:55 GMT

I have contacted the DF developers now, and will see if they have some input on this, as I can't think of what it would be either then. On my end I'm able to build it for both NCS 2.5.1 and 2.6.0 with the Zephyr versions 3.4.99 and 3.5.99, so I don't see why it would be a Zephyr configuration issue either...

I'll let you know when I hear from them. Thank you for being patient and thorough on your end!

Best regards,

Simon

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

Zihao — Wed, 10 Apr 2024 12:06:25 GMT

hello, could you please provide your nRF Connect SDK version and Zephyr version? Because you said you successfully built this project on your end.I think this is probably due to the API related to BLE direction finding in Zephyr.

Thank you very much.

Yours,

Zihao

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

Zihao — Wed, 10 Apr 2024 11:41:53 GMT

I strongly believe that this issue is related to the version or configuration of Zephyr. Is there anything specific I should know about configuring Zephyr?

My Zephyr installation was automated by the Toolchain during the installation of the nRF Connect SDK, and it is currently at version 3.5.99. I wrote 3.4.99 in this post, but as I later tried to update to nRF Connect SDK v2.6.0, it was changed to 3.5.99.

I would greatly appreciate any possible clues you could provide. Thank you!

Yours,

Zihao

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

Zihao — Wed, 10 Apr 2024 07:59:13 GMT

Hi,
I once tried to copy this project to the same disk, but it didn't work [sad].
Actually, when I was learning the Nordic Bluetooth course, all the new projects on the D disk were built very well.

So I still think there is something wrong (at least something not very universal) in this sample.

Now I'm testing the connectionless sample which can be built properly at least. But since it doesn't meet all my needs, I'm still following this error on the connection-based example.
I hope this problem can attract the attention of your direction finding engineers. There are three people have already encountered this problem as I mentioned earlier, but none of them have been solved yet.

Best regards,

Zihao

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

Simonr — Wed, 10 Apr 2024 07:31:10 GMT

Can you try moving the project to the C: disk (the same as where NCS is located on your computer, as I think the fact that you're trying to build the sample on a different disk than where you have NCS stored might be what is causing this. The west build is not great at jumping between disks to find functions/references if I recall correctly.

Best regards,

Simon