Connection error with Bluetooth 5.3 (nRF52833)

[TakashiM]

After changing to a new computer, my Bluetooth connection started failing.
The new computer has Bluetooth 5.3(HCI 12.13944 / LMP 12.13944).
"Our Observations" and "The workaround we adopted" are shown below.
I would appreciate your comments and if you could give me a better solution I would be very grateful.

[SDK And Soft Device]
Nordic SDK：nRF5_SDK_17.1.0　(Soft Device：S113)

[Details of the phenomenon]
・After starting the PC, the first Bluetooth connection will always be successful.
　If you disconnect the Bluetooth connection, subsequent Bluetooth connection attempts will fail.
　(※ Connections may occasionally succeed. The success rate is about 10%)

・The error that occurs when the connection fails is "LMP Error Transaction Collision/LL Procedure Collision."
(Bluetooth status code is "#define BLE_HCI_STATUS_CODE_LMP_ERROR_TRANSACTION_COLLISION 0x23".)

・If you disable and then enable a Bluetooth device in Device Manager, the first Bluetooth connection will always be successful.

・Even if I turn the Bluetooth function off and then on in my computer's settings, the Bluetooth connection fails.

・If you use a Bluetooth 5.3(HCI 12.56518 / LMP 12.45992) dongle, there will be no issues.
　This issue only occurs when using the computer's built-in Bluetooth function.

[Our Observations]
The nRF52833 errata has "The PHYEND event is generated 16 μs too late when compared to the actual end of frame on air.".
infocenter.nordicsemi.com/index.jsp
We believe that the timing of the collision is avoided because the connection process takes time the first time.
We believe that the reason for the improvement by using the dongle is either the difference in the HCI LMP version or that the timing of the collision is avoided by using the dongle.

[The workaround we adopted]
Changed "rx_phys" and "tx_phys" of "ble_gap_phys_t" to "BLE_GAP_PHY_1MBPS".
In our environment, this workaround resolved the issue of Bluetooth connection failures.

[Susheel Nuguru]

[The workaround we adopted]
Changed "rx_phys" and "tx_phys" of "ble_gap_phys_t" to "BLE_GAP_PHY_1MBPS".
In our environment, this workaround resolved the issue of Bluetooth connection failures.

What was the phy you were using prior to this workaround? 

The nRF52833 errata has "The PHYEND event is generated 16 μs too late when compared to the actual end of frame on air.".
infocenter.nordicsemi.com/index.jsp

How did you narrow it down to this issue? Did you run some tests that gave you some confidence that the issue is most likely related to this? Based on the above description, I am not able to connect the issue you are seeing with the errata you mentioned. And why did you conclude that changing the phy would help here?

Can you attach the BLe air sniffer trace of the connection that was failing so that we can see the timings of the packet transfer?

[TakashiM]

Thank you for your reply.

> What was the phy you were using prior to this workaround?
I was using BLE_GAP_PHY_AUTO.
Using BLE_GAP_PHY_2MBPS did not improve the problem.

> How did you narrow it down to this issue?
> Did you run some tests that gave you some confidence that the issue is most likely related to this?
Immediately after connecting, "BLE_GAP_EVT_DISCONNECTED" occurred and communication was disconnected.
By checking the contents of the event handler arguments in a debug environment, we found that the cause of the disconnection was "LMP Error Transaction Collision/LL Procedure Collision."
We confirmed that no problems occurred with the nRF52832.
Therefore, we concluded that it was a phenomenon specific to the nRF52833.
We then searched for anything that might be the cause of the "Collision" in the nRF52833 errata.

> And why did you conclude that changing the phy would help here?
I checked by changing the settings as much as I could.
By chance, when I changed it to BLE_GAP_PHY_1MBPS, the problem was resolved.

> Can you attach the BLe air sniffer trace of the connection that was failing so that we can see the timings of the packet transfer?
I have a question about "sniffer trace".
Am I correct in thinking that by using "nRF Sniffer for Bluetooth LE" you can obtain the "sniffer trace" that you are expecting?
nRF Sniffer for Bluetooth LE - nordicsemi.com
Also, am I correct in understanding that the "nRF52833 DK" is required for this?

[Susheel Nuguru]

Takashi-san,

TakashiM said:

Am I correct in thinking that by using "nRF Sniffer for Bluetooth LE" you can obtain the "sniffer trace" that you are expecting?
nRF Sniffer for Bluetooth LE - nordicsemi.com

Yes, you are correct. You have the userguide for this here.

TakashiM said:

Also, am I correct in understanding that the "nRF52833 DK" is required for this?

Any of the below can be used as a sniffer device, 

nRF52840 Dongle
nRF52840 DK
nRF52833 DK
nRF52 DK

One of the above needs to be in addition to the nRF device you are testing.

[TakashiM]

Resolved.

We are very sorry.
The cause was a bug in the source code we wrote.
The requirements document for the product we were developing included a description of the communication speed during Bluetooth connection, so we added “sd_ble_gap_phy_update” to the processing when the “BLE_GAP_EVT_CONNECTED” event occurs.
On the PC where the problem occurred, “BLE_GAP_EVT_PHY_UPDATE_REQUEST” was executed at the time of Bluetooth connection, and “sd_ble_gap_phy_update” was executed twice, causing the Bluetooth connection to fail.

Our apologies.

[Susheel Nuguru]

Takashi-san,

Thank you for coming back and writing the details that solved the issue. This will help fellow users who stumble upon similar issues.