Connect procedure and the disconnect reason 0x3E (BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED)

[Adrian Eggenberger]

Hi

Over the last years working with Nordic I struggled from time to time over the disconnect reason 0x3E (BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED) on our devices with Central role support. I didn't get to deep into this as it occurred only rarely. In the last months the appearance of this behavior increased and we analyzed the topic a little more.

Our understanding is that the softdevice changes into a "connected, not proven" state after the connect request has been sent in response of a received advertising. On the API the CONNECTED event is triggered to allow the application to start using the connection. If the case occurs that the connect request that is sent on the advertising channel is not received by the peripheral (caused by other advertisings or disturbances) the peripheral will not change in the connected state. After the 6th PDU is not answered by the peripheral the softdevice terminates the not proven connection with reason BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED and sends a DISCONNECTED event over the API to the application with the corresponding reason. Is this understanding correct?

Is it possible for the application to detect the switch of the "Connected, not proven" state to the "Connected and proven" state (after the first answered PDU)?
This would allow us to wait for a proven connection before starting the communication procedure.

Any answers, additions and thoughts to this topic are welcome… :-)

Regards Adrian

[Susheel Nuguru]

You understanding is correct  The app gets notified just after the connection request packet is sent. 

You are also correct that if the peer does not respond within a given time then we get a disconnected event with the BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED  reason.  This is according to the Spec . See Vol 6, Part B, Section 4.5.4

Is it possible for the application to detect the switch of the "Connected, not proven" state to the "Connected and proven" state (after the first answered PDU)?

No, this is not possible now, 

[Adrian Eggenberger]

Thank you for confirming my description.

Regarding the transition to a proven connection. I guess I can get around this by sending a simple request immediatly after the connect. Normally this will be answered in the second connection event. What would be angood reqest that could be sent for a „test“ of the connection?

[Susheel Nuguru]

I do not think it will be that straight forward.

Normally applications pull the events from the softdevice when other priority contexts in your application allow SWI interrupt to run. If your application has higher priority activity ongoing or if there is radio activity, then your SWI could be masked for varied amount of period.

But if your connection interval is big then we can safely assume that the SWI event interrupt will not be masked that long. 

Maybe you can ask to get an RSSI sample from the incoming connected packet. If you get NRF_SUCCESS then it will be an established connection, if you get NRF_ERROR_NOT_FOUND, then that means that no valid packets has been received from peer yet, so this could be interpreted as not established. I have not tried this myself, but might work.

[Adrian Eggenberger]

Thanks for sharing your thoughts about the detection of the proofed connection. I'll probably give this a try.It was most important for me to understand what happens at the connect procedure.