Regarding the behavior of pairing

[tommy]

In the pairing process among 1 Central and 2 Peripherals

Sometimes the Pairing  processing rarely does not work correctly and the following log output:

<err> cis_gateway: ACL connection to 4B:01:AA:9F:C4:2F (random) failed, error 2

 

Please find the attached ppt.

Would it be pssilbe to let us know what cause this problem?

We could confirm this in SDK2.3.0 and improved in SDK2.7.0.

Pairing err.pptx

BR,

[Edvin]

Hello,

Please provide logs either in .txt files or insert->code here in DevZone in the future.

So your connected callback has err = 2 = BT_HCI_ERR_UNKNOWN_CONN_ID. 

From the description of the connected callback, it says:

	 *  @p err can mean either of the following:
	 *  - @ref BT_HCI_ERR_UNKNOWN_CONN_ID Creating the connection started by
	 *    @ref bt_conn_le_create was canceled either by the user through
	 *    @ref bt_conn_disconnect or by the timeout in the host through
	 *    @ref bt_conn_le_create_param timeout parameter, which defaults to
	 *    @kconfig{CONFIG_BT_CREATE_CONN_TIMEOUT} seconds.

Do you see anything in the log of the device you are trying to connect to?

Is the address in the log of the GW the one that you expect it to be? Or is it trying to connect to something else?

Best regards,

Edvin

[tommy]

Thank you for your reply.

 

Do you see anything in the log of the device you are trying to connect to?
⇒The Log shown in <headset_L> of the Failure Log shown previously is output.

 

Is the address in the log of the GW the one that you expect it to be? Or is it trying to connect to something else?
⇒This is the expected one.

[Edvin]

tommy said:

The Log shown in <headset_L> of the Failure Log shown previously is output.

So nothing other than that it starts advertising, then.

I noticed that it tries to connect to 4B:01:AA:9F:C4:2F in the failing <gateway>, while it connects to DE:B2:D1:30:61:78 in the successful log. The other device that the gateway connects to, EE:EC:F3:9F:E0:32, is the same in both cases.

Why does the headse_L have a different address now?

And for the future, please upload logs as .txt or insert->code, so that it is possible to copy from the log. Don't use images.

BR,

Edvin

[tommy]

Edvin,

Here is the answer.

>Why does the headse_L have a different address now?
⇒Because only headset_L was paired.
　In this firmware,
　we have made the following changes to the gateway firmware to verify the behavior of headset_L is pairing while headset_R is linked.
　　[Before change] When the power is turned ON with button 5 pressed, the pairing key of headset_L and headset_R is deleted.
　　[After change] When the power is turned ON with button 5 pressed, only the pairing key of headset_L is deleted.

The board we used is nRF5340AudioDK, and we have modified basic sdk to develop the firmware.

[Edvin]

I see. 

Well, err 2 means BT_HCI_ERR_UNKNOWN_CONN_ID. From the connected-callback's declaration:

	 *  @p err can mean either of the following:
	 *  - @ref BT_HCI_ERR_UNKNOWN_CONN_ID Creating the connection started by
	 *    @ref bt_conn_le_create was canceled either by the user through
	 *    @ref bt_conn_disconnect or by the timeout in the host through
	 *    @ref bt_conn_le_create_param timeout parameter, which defaults to
	 *    @kconfig{CONFIG_BT_CREATE_CONN_TIMEOUT} seconds.

It could be that the peripheral didn't pick up the connection request packet. Can you please try to capture a sniffer trace of the error? You can use the nRF Sniffer for Bluetooth LE.

Best regards,

Edvin