How to minimize HCI error 0x3E and 0x22 connection failures of BLE connections?

[DaveBeal]

I am working on a device that contains an nRF52840.  It is a BLE central with up to 20 concurrent peripheral devices.  For user experience, it's important that it be able to reliably and quickly connect to all 20 peripherals.  The peripherals are also 840-based.  The connections usually come up quickly and work well.  However, I sometimes get disconnect events with HCI error codes 0x3E (Connection failed to be established) or 0x22 (LMP transaction collision/LL procedure collision), and have to re-establish the connection.  Is there anything I can do in my software to minimize the frequency of these types of connection failures?

Also, why does an HCI error 0x22 cause the connection to fail?  As I read the BLE 5.0 spec, this should just cause the slave's procedure to be ignored and the master's procedure to be executed.  The spec does not say that the connection should be terminated.  Thank you!

[Sigurd]

Hi,

Before going into potential fixes or ways to mitigate the issue, please answer these questions.

1) Is this a custom board, or the nRF52840-DK ?

If this is a custom board, what revision of the nRF52840 is used?

If this is the DK, what version of the DK is used? (printed on the white-sticker)

2) What SDK version are you using?

3) What SoftDevice version are you using?

[DaveBeal]

Hi Sigurd -

Thanks for your response.  It is a custom board, using SDK 15.2.0 with SoftDevice s140.  How do I determine the 840 revision?

- Dave

[Sigurd]

Hi,

Packet variant and build code can be read from markings on top of the nRF52 IC. See this page

[DaveBeal]

Sigurd, I'm sorry, but I'm not able to access the 840 chip in the prototype device I'm working with.

[Sigurd]

Hi,

You will get the event "Connection failed to be established" when the peripheral has not received the connection request packet and it's detected when the central have not received any packets for 6 connection events after the connection request. If you have a lot of advertisers around, advertising very fast, then this could cause this behavior (too much noise). I would suggest that you try to increase the advertising interval and the connection interval,  and see if that improves the situation.

Regarding the revision, you could also read this out in the FICR INFO.VARIANT register.