Direction Finding Project: Central and Peripheral Integration

RE: Direction Finding Project: Central and Peripheral Integration

tesc — Wed, 26 Jun 2024 14:21:46 GMT

Hi,

We support the entire Bluetooth part of the puzzle, with the SoC and the Bluetooth Controller and Host fully implemented.

We do not provide antenna array and corresponding algorithm. Building on top of our solutions, these are the current options for completing the picture:

Make your own antenna array and algorithms
Buy an existing antenna array design, such as the ISP 1907-AOA-DK, and build your own algorithms
Buy a package with both antenna array and algorithms, such as the offerings from u-Blox

Regards,
Terje

RE: Direction Finding Project: Central and Peripheral Integration

Darsh — Wed, 19 Jun 2024 14:29:10 GMT

Hello, Thank you for providing the links, I also noticed that Nordic does not produce their own antenna arrays, so I want to make a cutsom antenna array board and want to know how the firmware is actually implemented for the positioning using multiple boards.

I am relatively new to bluetooth development and AoA/AoD so just looking to learn more.

Thanks once again,
Darsh.

RE: Direction Finding Project: Central and Peripheral Integration

Zihao — Wed, 19 Jun 2024 14:16:23 GMT

By the ways, are you interested in Central and Peripheral Integration?

I think this is a relatively niche operation, as I mentioned in this case. So, could you share what project you are working on that led you to this case? I'm just curious, but it's perfectly fine if you'd rather not share.

RE: Direction Finding Project: Central and Peripheral Integration

Zihao — Wed, 19 Jun 2024 14:06:45 GMT

Hello, the antenna array I am using is designed by Nordic, which you can find here: https://www.youtube.com/watch?v=AtS6HsrUgZQ&t=1s.

However, it seems that Nordic does not produce their own designed antenna arrays and only uses them as a basis for their DF demos. I think it would be a good idea to try purchasing an AoA kit like InsightSiP. Alternatively, you can print an array board yourself using acrylic sheets and connect antennas with RF switches as shown in the YouTube video. Overall, it's relatively simple hardware, and customizing it yourself won't take too much time.

I have a strong interest in AoA and AoD, and I welcome any related questions or discussions.

Yours,

Zihao

RE: Direction Finding Project: Central and Peripheral Integration

Darsh — Wed, 19 Jun 2024 11:26:18 GMT

I am just curious about for the antenna array you are using? Can you provide the reference link or something? I have nrf52833dk which i am using as a tag and I am confused about which antenna array I should use. It would be really helpful.

Thanks

RE: Direction Finding Project: Central and Peripheral Integration

Zihao — Thu, 13 Jun 2024 10:19:43 GMT

Thank you for your reply! I have resolved the issue!

RE: Direction Finding Project: Central and Peripheral Integration

Zihao — Wed, 12 Jun 2024 23:36:55 GMT

Thanks for the reply,

It seems these operations are really quite decoupled and convenient: advertising, scanning, connecting, disconnecting, etc. I was able to resolve error -120 and error -22.

However, I still face an issue when my two devices switch roles for the first time. One device keeps advertising and the other keeps scanning, but they just won't establish a connection. Everything looks good. There is no error, no failed, no warnning.

I believe my implementation is quite straightforward: start advertising, connecting, disconnecting, disable advertising, start scanning. The other device performs the opposite operations. Is there anything specific I need to pay attention to during this process?

RE: Direction Finding Project: Central and Peripheral Integration

tesc — Tue, 11 Jun 2024 13:13:29 GMT

Hi,

[quote user="Zihao"]But I don't know the 'CONFIG_BT_CTLR_SDC_PERIPHERAL_COUNT', 'CONFIG_BT_CTLR_SDC_CENTRAL_COUNT ' and 'CONFIG_BT_MAX_CONN', which do not appear in the default direction finding samples.[/quote]

Most configs get default values, or get values based on other configs. You can check all resulting configs for a build in the .config file, which is generated among the outputs. Find it under "Output files" in VS Code.

[quote user="Zihao"]When the RX complete the CTE collection and ready to switch to TX, I call the bt_le_scan_stop() then it report an error: Scanning failed to stop (err -120). I don't know why I can't stop the scan.[/quote]

You get -120 EALREADY if the scan has already been stopped. If for instance you were scanning for a connection, and you get the connection set up, scan is automatically stopped. Therefore there is no need to stop the scan after this has happened. In many situations, this error value can be treated equal to a return code of 0 (success), since it basically means that what you called for is already effectuated.

[quote user="Zihao"]Disable the request CTE from peer device... failed (err -22).
The function I called is bt_df_conn_cte_req_disable().[/quote]

This can only be called if in a connection. It looks like this is automatically disabled on disconnection. Similar as with -120 from bt_le_scan_stop(), an error code of -22 here basically means what you attempt to do is already done.

[quote user="Zihao"]I want to call bt_enable() multiple times because I need to switch between TX and RX on one device. I just thought that initializing it again and again might be an easy way to achieve the switching. If I'm wrong, I apologize.[/quote]

There is no need to reinitialize BLE for switching between BLE roles. Just use the APIs for connectable advertising, scanning, connecting, disconnecting, etc. appropriately for what you want to do, and in the order you want to do it.

Regards,
Terje

RE: Direction Finding Project: Central and Peripheral Integration

Zihao — Tue, 11 Jun 2024 03:26:24 GMT

I want to correct something.

Although TX seems to have started normally because no error was reported when calling this function:

static void bt_ready(void)
{
	int err;

	err = bt_le_adv_start(BT_LE_ADV_CONN_NAME, ad, ARRAY_SIZE(ad), NULL, 0);
	if (err) {
		printk("Advertising failed to start (err %d)\n", err);
		return;
	}

	printk("Advertising successfully started\n");
}

However, when I use the nRF Connect APP to check the device, I didn't find it. Therefore, even though bt_le_adv_start() did not return an error, it seems it did not actually start advertising packets successfully. I don'tunderstand why this is happening.

Before bt_le_adv_start() , I called disable_cte_reqest(), bt_conn_disconnect(). And the bt_le_scan_stop() has been called in eir_found() when the target device is found. So everything seems fine but it does not advertise packets...

 Hello, this is the Antenna Array Side!!

Bluetooth initialized
Now I am going into the Switch Loop...

-----------------------------------------------------------------------LOOP START

Now I am using the AoA Setting.
First, calculate the AoA.
 Now I am waiting for a connection and becoming a RX.
Scanning successfully started
[DEVICE]: 05:11:54:C3:FA:10 (random), AD evt type 3, AD data len 31, RSSI -52
[DEVICE]: 15:14:A7:6D:1F:25 (random), AD evt type 3, AD data len 31, RSSI -84
[DEVICE]: 2B:46:3A:94:AD:5B (random), AD evt type 3, AD data len 31, RSSI -84
[DEVICE]: 56:F2:B2:D7:E2:90 (random), AD evt type 3, AD data len 31, RSSI -80
[DEVICE]: FC:01:50:FD:5F:53 (random), AD evt type 0, AD data len 8, RSSI -42
[AD]: 1 data_len 1
[AD]: 39 data_len 3
Connected as a CENTRAL: FC:01:50:FD:5F:53 (random)
Enable receiving of CTE...
success. CTE receive enabled.
Request CTE from peer device...
success. CTE request enabled.
CTE[FC:01:50:FD:5F:53 (random)]: samples count 45, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -500
I got the AoA CTE! Now I'm gonna stop the scan!
Disable the request CTE from peer device...
success. CTE request disabled.
Disable receiving of CTE...
success. CTE receive disabled.
Now I'm gonna disconnect!
The RX Disconnected!
From the DISconnected call back function of TX: Disconnected...
The AoA is completed!
Now I am using the AoD Setting.
Second, calculate the AoD.
 Now I am asking a connection and becoming a TX.
Advertising successfully started

RE: Direction Finding Project: Central and Peripheral Integration

Zihao — Mon, 10 Jun 2024 08:30:07 GMT

However, today I discovered that the case where AoA and AoD are obtained simultaneously is not reproducible.

Now, I'm encountering a situation where after my RX switches to TX, it keeps sending packets. Meanwhile, my TX switches to RX and keeps scanning. However, they do not establish a connection. The log appears to be very normal.

Antenna array side:

 Hello, this is the Antenna Array Side!!

Bluetooth initialized
Now I am going into the Switch Loop...

-----------------------------------------------------------------------LOOP START

Now I am using the AoA Setting.
First, calculate the AoA.
 Now I am waiting for a connection and becoming a RX.
Scanning successfully started
[00:00:00.267,364] <inf> bt_hci_core: hci_vs_in[DEVICE]: 12:89:A5:62:96:36 (random), AD evt type 3, AD data len 31, RSSI -53
[DEVICE]: 7C:27:BC:D1:9D:2E (public), AD evt type 3, AD data len 19, RSSI -87
[DEVICE]: D1:8D:C5:A0:52:24 (random), AD evt type 3, AD data len 8, RSSI -58
it: HW[DEVICE]: 2A:34:53:29:E5:23 (random), AD evt type 3, AD data len 31, RSSI -81
[DEVICE]: 11:8E:BB:9F:5C:D4 (random), AD evt type 3, AD data len 31, RSSI -84
[DEVICE]: 38:71:41:40:89:0F (random), AD evt type 3, AD data len 31, RSSI -81
[DEVICE]: 11:8E:BB:9F:5C:D4 (random), AD evt type 3, AD data len 31, RSSI -85
[DEVICE]: 04:95:9E:85:E4:31 (random), AD evt type 3, AD data len 31, RSSI -76
[DEVICE]: 12:89:A5:62:96:36 (random), AD evt type 3, AD data len 31, RSSI -53
[DEVICE]: 7C:27:BC:D1:9D:2E (public), AD evt type 3, AD data len 19, RSSI -78
[DEVICE]: 4A:3F:F9:A9:00:C2 (random), AD evt type 0, AD data len 17, RSSI -54
[AD]: 1 data_len 1
[AD]: 10 data_len 1
[AD]: 255 data_len 9
[DEVICE]: 4A:3F:F9:A9:00:C2 (random), AD evt type 4, AD data len 0, RSSI -54
[DEVICE]: 0F:ED:AB:B2:EC:75 (random), AD evt type 3, AD data len 31, RSSI -80
[DEVICE]: 04:95:9E:85:E4:31 (random), AD evt type 3, AD data len 31, RSSI -69
[DEVICE]: 2A:34:53:29:E5:23 (random), AD evt type 3, AD data len 31, RSSI -73
[DEVICE]: 12:89:A5:62:96:36 (random), AD evt type 3, AD data len 31, RSSI -50
 Platform: Nordic Semiconductor (0x0002)
[00:00:00.267,395] <inf> bt_hci_core: hci_vs_init: HW Variant: nRF52x (0x0002)
[00:00:00.267,425] <inf> bt_hci_core: hci_vs_init: Firmware: Standard Bluetooth controller (0x00) Version 3.2 Build 99
[00:00:00.268,188] <inf> bt_hci_core: bt_dev_show_info: Identity: E7:8C:85:B4:1[DEVICE]: 4E:2F:34:97:F8:64 (random), AD evt type 3, AD data len 31, RSSI -86
C:E6 (random)
[00:00:00.268,218] <inf> bt_hci_core: bt_dev_show_info: HCI: version 5.3 (0x0c) revision 0x0000, manufacturer 0x05f1
[00:00:00.268,249] <inf> bt_hci_core: bt_dev_show_info: LMP: version 5.3 (0x0c) subver 0xffff
[DEVICE]: 11:8E:BB:9F:5C:D4 (random), AD evt type 3, AD data len 31, RSSI -84
[DEVICE]: 2A:34:53:29:E5:23 (random), AD evt type 3, AD data len 31, RSSI -66
[DEVICE]: FC:01:50:FD:5F:53 (random), AD evt type 0, AD data len 8, RSSI -50
[AD]: 1 data_len 1
[AD]: 39 data_len 3
Connected as a CENTRAL: FC:01:50:FD:5F:53 (random)
Enable receiving of CTE...
success. CTE receive enabled.
Request CTE from peer device...
success. CTE request enabled.
CTE[FC:01:50:FD:5F:53 (random)]: samples count 3, cte type AOA, slot durations: 2 [us], packet status CRC not OK, CTE Info OK, RSSI -570
CTE[FC:01:50:FD:5F:53 (random)]: samples count 3, cte type AOA, slot durations: 2 [us], packet status CRC not OK, CTE Info OK, RSSI -500
CTE[FC:01:50:FD:5F:53 (random)]: samples count 45, cte type AOA, slot durations: 2 [us], packet status CRC OK, RSSI -510
I got the AoA CTE! Now I'm gonna stop the scan!
Now I'm gonna disconnect!
The RX Disconnected!
The AoA is completed!
Now I am using the AoD Setting.
Second, calculate the AoD.
 Now I am asking a connection and becoming a TX.
Bluetooth initialized
Advertising successfully started

Single antenna side:

 Hello, this is the Single Antenna Side!! 

Bluetooth initialized
Now I am going into the Switch Loop... 

-----------------------------------------------------------------------LOOP START 

Now I am using the AoA Setting.
First, calculate the AoA.
 Now I am asking a connection and becoming a TX.
Bluetooth initialized
Advertising successfully started
[00:00:00.268,493] [0m<inf> bt_hci_core: hci_vs_init: HW Platform: Nordic Semiconductor (0x0002)[0m
[00:00:00.268,524] [0m<inf> bt_hci_core: hci_vs_init: HW Variant: nRF52x (0x0002)[0m
[00:00:00.268,554] [0m<inf> bt_hci_core: hci_vs_init: Firmware: Standard Bluetooth controller (0x00) Version 3.2 Build 99[0m
[00:00:00.269,317] [0m<inf> bt_hci_core: bt_dev_show_info: Identity: FC:01:50:FD:5F:53 (random)[0m
[00:00:00.269,348] [0m<inf> bt_hci_core: bt_dev_show_info: HCI: version 5.3 (0x0c) revision 0x0000, manufacturer 0x05f1[0m
[00:00:00.2Connected as a PERIPHERAL
Set CTE transmission params...success.
Set CTE response enable...success.
69,378] [0m<inf> bt_hci_core: bt_dev_show_info: LMP: version 5.3 (0x0c) subver 0xffff[0m
The other side has completed the CTE collection, and want to disconnect...
Disconnected (reason 0x13)
Second, calculate the AoD.
 Now I am waiting for a connection and becoming a RX. 
Now I am using the AoD Setting.
Scanning successfully started
[DEVICE]: 04:95:9E:85:E4:31 (random), AD evt type 3, AD data len 31, RSSI -65
[DEVICE]: 11:8E:BB:9F:5C:D4 (random), AD evt type 3, AD data len 31, RSSI -73
[DEVICE]: 53:92:EB:C2:9D:CE (random), AD evt type 3, AD data len 17, RSSI -48
[DEVICE]: 12:89:A5:62:96:36 (random), AD evt type 3, AD data len 31, RSSI -33
[DEVICE]: 2A:34:53:29:E5:23 (random), AD evt type 3, AD data len 31, RSSI -54
[DEVICE]: 7C:27:BC:D1:9D:2E (public), AD evt type 3, AD data len 19, RSSI -64
[DEVICE]: 12:89:A5:62:96:36 (random), AD evt type 3, AD data len 31, RSSI -43
[DEVICE]: 2A:34:53:29:E5:23 (random), AD evt type 3, AD data len 31, RSSI -59
[DEVICE]: 4E:2F:34:97:F8:64 (random), AD evt type 3, AD data len 31, RSSI -77
[DEVICE]: 0F:ED:AB:B2:EC:75 (random), AD evt type 3, AD data len 31, RSSI -81
[DEVICE]: 78:11:DC:C2:89:2F (public), AD evt type 0, AD data len 24, RSSI -82
[AD]: 1 data_len 1
[AD]: 22 data_len 19
[DEVICE]: 04:95:9E:85:E4:31 (random), AD evt type 3, AD data len 31, RSSI -55
[DEVICE]: 4E:2F:34:97:F8:64 (random), AD evt type 3, AD data len 31, RSSI -79
[DEVICE]: 78:11:DC:C2:89:2F (public), AD evt type 0, AD data len 24, RSSI -83
[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 -82
[DEVICE]: 04:95:9E:85:E4:31 (random), AD evt type 3, AD data len 31, RSSI -66
[DEVICE]: 12:89:A5:62:96:36 (random), AD evt type 3, AD data len 31, RSSI -32
[DEVICE]: 78:11:DC:C2:89:2F (public), AD evt type 0, AD data len 24, RSSI -79
[AD]: 1 data_len 1
[AD]: 22 data_len 19
[DEVICE]: 7C:27:BC:D1:9D:2E (public), AD evt type 3, AD data len 19, RSSI -65
[DEVICE]: 4A:3F:F9:A9:00:C2 (random), AD evt type 0, AD data len 17, RSSI -51
[AD]: 1 data_len 1
[AD]: 10 data_len 1
[AD]: 255 data_len 9
[DEVICE]: 4A:3F:F9:A9:00:C2 (random), AD evt type 4, AD data len 0, RSSI -49
[DEVICE]: 2A:34:53:29:E5:23 (random), AD evt type 3, AD data len 31, RSSI -52
[DEVICE]: 12:89:A5:62:96:36 (random), AD evt type 3, AD data len 31, RSSI -33
[DEVICE]: 2A:34:53:29:E5:23 (random), AD evt type 3, AD data len 31, RSSI -54
[DEVICE]: 04:95:9E:85:E4:31 (random), AD evt type 3, AD data len 31, RSSI -65
[DEVICE]: 4E:2F:34:97:F8:64 (random), AD evt type 3, AD data len 31, RSSI -73
[DEVICE]: 0F:ED:AB:B2:EC:75 (random), AD evt type 3, AD data len 31, RSSI -72
[DEVICE]: 7C:27:BC:D1:9D:2E (public), AD evt type 3, AD data len 19, RSSI -64
[DEVICE]: 04:95:9E:85:E4:31 (random), AD evt type 3, AD data len 31, RSSI -66
[DEVICE]: 11:8E:BB:9F:5C:D4 (random), AD evt type 3, AD data len 31, RSSI -73
[DEVICE]: 0F:ED:AB:B2:EC:75 (random), AD evt type 3, AD data len 31, RSSI -80
[DEVICE]: 78:11:DC:C2:89:2F (public), AD evt type 0, AD data len 24, RSSI -79
[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 -79
[DEVICE]: 68:E4:78:EA:52:FF (public), AD evt type 0, AD data len 31, RSSI -92
[AD]: 1 data_len 1
[AD]: 9 data_len 8
[AD]: 22 data_len 16
[DEVICE]: 78:11:DC:C2:89:2F (public), AD evt type 0, AD data len 24, RSSI -82
[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 -81
[DEVICE]: 2A:34:53:29:E5:23 (random), AD evt type 3, AD data len 31, RSSI -60
[DEVICE]: 78:11:DC:C2:89:2F (public), AD evt type 0, AD data len 24, RSSI -82
[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 -82
[DEVICE]: 11:8E:BB:9F:5C:D4 (random), AD evt type 3, AD data len 31, RSSI -74
[DEVICE]: 12:89:A5:62:96:36 (random), AD evt type 3, AD data len 31, RSSI -32
[DEVICE]: 4E:2F:34:97:F8:64 (random), AD evt type 3, AD data len 31, RSSI -78
[DEVICE]: 4A:3F:F9:A9:00:C2 (random), AD evt type 0, AD data len 17, RSSI -49
[AD]: 1 data_len 1
[AD]: 10 data_len 1
[AD]: 255 data_len 9
[DEVICE]: 4A:3F:F9:A9:00:C2 (random), AD evt type 4, AD data len 0, RSSI -49
[DEVICE]: 04:95:9E:85:E4:31 (random), AD evt type 3, AD data len 31, RSSI -55
[DEVICE]: 4E:2F:34:97:F8:64 (random), AD evt type 3, AD data len 31, RSSI -79
[DEVICE]: 0F:ED:AB:B2:EC:75 (random), AD evt type 3, AD data len 31, RSSI -66
[DEVICE]: 7C:27:BC:D1:9D:2E (public), AD evt type 3, AD data len 19, RSSI -67
[DEVICE]: 2A:34:53:29:E5:23 (random), AD evt type 3, AD data len 31, RSSI -54
[DEVICE]: 04:95:9E:85:E4:31 (random), AD evt type 3, AD data len 31, RSSI -64
[DEVICE]: 68:E4:78:EA:52:FF (public), AD evt type 0, AD data len 31, RSSI -91
[AD]: 1 data_len 1
[AD]: 9 data_len 8
[AD]: 22 data_len 16
[DEVICE]: 38:71:41:40:89:0F (random), AD evt type 3, AD data len 31, RSSI -63
[DEVICE]: 11:8E:BB:9F:5C:D4 (random), AD evt type 3, AD data len 31, RSSI -74
[DEVICE]: 2A:34:53:29:E5:23 (random), AD evt type 3, AD data len 31, RSSI -64
[DEVICE]: 12:89:A5:62:96:36 (random), AD evt type 3, AD data len 31, RSSI -32
[DEVICE]: 78:11:DC:C2:89:2F (public), AD evt type 0, AD data len 24, RSSI -79
[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 -78
[DEVICE]: F4:B3:B1:AE:33:46 (public), AD evt type 3, AD data len 30, RSSI -67
[DEVICE]: 12:89:A5:62:96:36 (random), AD evt type 3, AD data len 31, RSSI -43
[DEVICE]: 11:8E:BB:9F:5C:D4 (random), AD evt type 3, AD data len 31, RSSI -69
[DEVICE]: 2A:34:53:29:E5:23 (random), AD evt type 3, AD data len 31, RSSI -52
[DEVICE]: 78:11:DC:C2:89:2F (public), AD evt type 0, AD data len 24, RSSI -83
[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 -82
[DEVICE]: 4E:2F:34:97:F8:64 (random), AD evt type 3, AD data len 31, RSSI -73
[DEVICE]: 04:95:9E:85:E4:31 (random), AD evt type 3, AD data len 31, RSSI -65
[DEVICE]: 78:11:DC:C2:89:2F (public), AD evt type 0, AD data len 24, RSSI -83
[AD]: 1 data_len 1
[AD]: 22 data_len 19
[DEVICE]: 0F:ED:AB:B2:EC:75 (random), AD evt type 3, AD data len 31, RSSI -77
[DEVICE]: 7C:27:BC:D1:9D:2E (public), AD evt type 3, AD data len 19, RSSI -63
[DEVICE]: 4E:2F:34:97:F8:64 (random), AD evt type 3, AD data len 31, RSSI -80
[DEVICE]: 78:11:DC:C2:89:2F (public), AD evt type 0, AD data len 24, RSSI -79
[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 -79
[DEVICE]: 4A:3F:F9:A9:00:C2 (random), AD evt type 0, AD data len 17, RSSI -50
[AD]: 1 data_len 1
[AD]: 10 data_len 1
[AD]: 255 data_len 9
[DEVICE]: 4E:2F:34:97:F8:64 (random), AD evt type 3, AD data len 31, RSSI -80
[DEVICE]: 12:89:A5:62:96:36 (random), AD evt type 3, AD data len 31, RSSI -32
[DEVICE]: 11:8E:BB:9F:5C:D4 (random), AD evt type 3, AD data len 31, RSSI -73
[DEVICE]: 04:95:9E:85:E4:31 (random), AD evt type 3, AD data len 31, RSSI -55

RE: Direction Finding Project: Central and Peripheral Integration

Zihao — Wed, 05 Jun 2024 12:14:24 GMT

Hi, thank you for your reply.

1) I just merge the config of the official central and peripheral. So in the final prj.conf I used, I can check that the values of CONFIG_BT_PERIPHERAL and CONFIG_BT_CENTRAL are 'y'. But I don't know the 'CONFIG_BT_CTLR_SDC_PERIPHERAL_COUNT', 'CONFIG_BT_CTLR_SDC_CENTRAL_COUNT ' and 'CONFIG_BT_MAX_CONN', which do not appear in the default direction finding samples.

2) No, I didn't see any error return values. As I said before, the TX seems transmit all the time, while the RX scan all the time. But the connection did not occur. However, see 3).

3) Yes, I added some function like XXX_disable() today and got some progress. I got the AoA and AoD successfully! But only the fisrt loop worked in my project. I still meet something error here. So please help me because I need the loop to run continuously.
a) When the RX complete the CTE collection and ready to switch to TX, I call the bt_le_scan_stop() then it report an error: Scanning failed to stop (err -120). I don't know why I can't stop the scan.
Before that, I have called the disable_cte_reqest() and it seem's execute right. All the functions were called in the disconnected call back function. And the disconnect function (bt_conn_disconnect()) was called in the cte_recv_cb() when it received enough CTE packets.
b) When the TX complete the CTE transmission and ready to switch to RX, the disable_cte_response(conn) should be called. But I don't know where should it be. In my understand, I can determine when the CTE transmission has completed only through the disconnection event. So I call disable_cte_response(conn) in the disconnected call back function. The result is, err -128, which means "Socket is not connected.". I think I can't call it in the disconnected callback function because the connection is over but it is needed by the function (requires parameter 'conn').

c) Disable the request CTE from peer device... failed (err -22).
The function I called is bt_df_conn_cte_req_disable().

My _disable() function:

// both the functions are called in the disconnected call back function.
static void disable_cte_response(struct bt_conn *conn)
{
	int err;
	printk("Set CTE response disable...");
	err = bt_df_conn_cte_rsp_disable(conn);
	if (err) {
		printk("failed (err %d).\n", err);
		return;
	}
	printk("success.\n");
}

static void disable_cte_reqest(void)
{
	int err;

	printk("Disable the request CTE from peer device...\n");
	err = bt_df_conn_cte_req_disable(default_conn);
	if (err) {
		printk("failed (err %d)\n", err);
		return;
	}
	printk("success. CTE request disabled.\n");

	printk("Disable receiving of CTE...\n");
	err = bt_df_conn_cte_rx_disable(default_conn);
	if (err) {
		printk("failed (err %d)\n", err);
		return;
	}
	printk("success. CTE receive disabled.\n");
}

4) I want to call bt_enable() multiple times because I need to switch between TX and RX on one device. I just thought that initializing it again and again might be an easy way to achieve the switching. If I'm wrong, I apologize.

5) I don't know if there is something wrong in my main function. I wrote two while loops with a k_sleep function to control the TX or RX operations like this:

while(true){

	AoA_Setting();
	CENTRAL_Setting();

	MAIN_RX_IS_COMPLETED = false;
	start_scan();
	while(!MAIN_RX_IS_COMPLETED){k_sleep(K_MSEC(100));}

	printk("The AoA is completed!\n");
	
	
	AoD_Setting();
	PERIPHERAL_Setting();

	MAIN_TX_IS_COMPLETED = false;
	bt_ready();
	while(!MAIN_TX_IS_COMPLETED){k_sleep(K_MSEC(100));}

	printk("The AoD is completed!\n");

}

Thanks again!!

RE: Direction Finding Project: Central and Peripheral Integration

tesc — Tue, 04 Jun 2024 11:15:49 GMT

Hi,

[quote user=""]However, when I switch to TX mode, the connection can't be estiblished. The TX(antenna array) just transmit all the time, and the RX(single antenna side) just scan all the time.
So why can't the connection be estiblished?[/quote]

Can you check CONFIG_BT_PERIPHERAL, CONFIG_BT_CTLR_SDC_PERIPHERAL_COUNT, CONFIG_BT_CENTRAL, CONFIG_BT_CTLR_SDC_CENTRAL_COUNT and CONFIG_BT_MAX_CONN?

Are there any error return values, or anything else indicating in what way it fails?

[quote user=""]A) In enable_cte_request(), the functions bt_df_conn_cte_rx_enable() and bt_df_conn_cte_req_enable() set certain settings. So, when I call enable_cte_response(), do I need to drop or cancel the settings made by bt_df_conn_cte_rx_enable() and bt_df_conn_cte_req_enable()?[/quote]

I see that those API calls have ..._disable() variants. Have you tried, after stopping scanning and advertising respectively, disabling the corresponding cte? I.e. create a corresponding disable_cte_request() to enable_cte_request() and a corresponding disable_cte_response() to enable_cte_response(), containing the API calls for disabling what was enabled in the ..._enable() variants.

[quote user=""]B) I know that Bluetooth can only be initialized once in Zephyr. Is there any operation similar to "drop", allowing me to call bt_enable() multiple times?[/quote]

One workaround is to do a soft reset, but of course it depends on what you are trying to achieve. Other workarounds may be applicable, depending on the use case. Why do you want to call bt_enable() multiple times, what are you trying to achieve?

Regards,
Terje