This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

BLE connection times out on Central and Peripheral, both sides.

Central info
SDK: 15.3
nRF52840

Peripheral info
SDK: 13.1
nRF52832

Connection Param
MIN_CONN_INTERVAL MSEC_TO_UNITS 40
MAX_CONN_INTERVAL MSEC_TO_UNITS 52
SLAVE_LATENCY 3
CONN_SUP_TIMEOUT 1500


BLE connection times out on Central and Peripheral, both sides.
BLE dissconnect reason(0x8: BLE_HCI_CONNECTION_TIMEOUT).

The following threads describe Central and Peripheral, and the causes of timeouts on both sides.
devzone.nordicsemi.com/.../error-8-0x8-gatt-conn-timeout

>> Packet loss on air due to low RSSI or much noise or interference.
>> This can be handled by increasing the number of retransmissions,
>> which is achieved by increasing the supervision timeout (making it larger relative to the connection interval).
Is the set monitoring timeout time (15000ms) insufficient?

>> You should also avoid slave latency, or at least ensure that you still have a good margin if it is used.
Is it better to increase the slave latency value (3) that has been set?

>> Note that the central decides the connection parameters, so what you have configured may not be what is actually used.
>> Do you have a sniffer trace that shows the actual connection parameters of the link?
The sniffer confirms that the value is actually reflected.

>> Clock drift between the peers, making the event windows non-overlapping.
>> This should not happen as the clock accuracy is exchanged when the connection is established, and it is accounted for.
>> However, you sometimes see connections issues if the nRF has a bad clock source.
>> This could typically be a crystal with wrong load capacitor values,
>> or using the internal RC oscillator but configuring the SoftDevice to indicate a high accuracy.
I didn't know what to check.


The cause of a timeout is unknown and cannot be proceeded.
The timeout does not occur frequently and occurs about twice a day.
I want you to help me.

Parents
  • Hi,

    A supervision timeout of 15000 ms should be more than enough. I would guess you might have issue with the 32kHz source, or that you are testing in an environment with some really bad interference.

    What HW are you testing on? And what is the usecase for this device, i.e. in what kind of environment is the device located when the link is lost?

    I assume you are checking to make sure you do not have any unintentional resets on either device?

Reply
  • Hi,

    A supervision timeout of 15000 ms should be more than enough. I would guess you might have issue with the 32kHz source, or that you are testing in an environment with some really bad interference.

    What HW are you testing on? And what is the usecase for this device, i.e. in what kind of environment is the device located when the link is lost?

    I assume you are checking to make sure you do not have any unintentional resets on either device?

Children
Related