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?

[Zihao]

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.

[Zihao]

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

[Simonr]

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

[Zihao]

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

[Simonr]

Hi

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