Possible reasons for disconnect reason 8

[wgeeurickx]

Hi,

I have an application with custom boards using nRF54L15 (running ncs 2.9.1) as the peripheral and currently a modified nRF9160DK (running ncs 2.5.1) as the central, which connects to multiple peripherals at a time. I am noticing quite some disconnects happening in (unattended) field tests, and I would like to understand if there is a way to diagnose/fix these. I already started adding more logging of metrics so I have more context, and this is what I have so far.

# Connection parameters
CONFIG_BT_PERIPHERAL_PREF_MIN_INT=400
CONFIG_BT_PERIPHERAL_PREF_MAX_INT=400
CONFIG_BT_PERIPHERAL_PREF_LATENCY=2
CONFIG_BT_PERIPHERAL_PREF_TIMEOUT=1000

There are no resets happening on the peripheral/central side, and the RSSI is pretty stable, with the 10% quantile for the device that is furthest away at a stable -80dBm. I know this is on the low end, but I assume it should still be high enough for a stable connection. In this case, the central has 4 peripherals connected to it. The disconnects occur for all peripherals, but at widely different (random) intervals.

Could you give me any pointers on what could be going wrong and how I can try to identify it? It's hard for me to get a sniffer trace as this field test is happening unattended at a public site, and the occurence of the disconnects is pretty random and can take some time before they start happening.

Best,

Wout

[Simonr]

Hi

Where do you see the disconnects exactly, do you have any logging information you can upload here? Disconnect reason 0x8 points to a BLE HCI CONNECTION TIMEOUT, and that should only be triggered by a connection supervision timeout, meaning there has been no activity in the BLE connection for the supervision timeout. You set the preferred timeout to 1000 (ms), but in the end it's the central application that decides the connection parameters. Please share the connection parameters from the central application, or potentially a sniffer trace so we can see what's happening on the air. You can use another DK and the nRF Sniffer tool + Wireshark for getting sniffer traces for example: https://www.nordicsemi.com/Products/Development-tools/nRF-Sniffer-for-Bluetooth-LE 

Best regards,

Simon

[wgeeurickx]

Hi Simon,

This is the log (from the central) of the connection parameters once they are negotiated, which is in line with the settings from the peripheral.

Best,

Wout

[Simonr]

Hi

Can you upload the full log of the connection process, the connection itself and the disconnect as a .txt file so we can review it? One line just shows us that it's at one point set as expected. It doesn't mean it will stay like this. Also, how long after this connection parameter update does the disconnection occur? If there is nothing else occurring for 10 seconds here the connection supervision timeout will trig and disconnect the devices.

Best regards,

Simon

[wgeeurickx]

Hi Simon,

There's nothing concretely being logged once the connection is set up. The peripheral just sends sensor data (around 100 byte payload) every second. The disconnections occur randomly, sometimes within a minute, sometimes only after 24+ hours.

Here is a log from the connection process (with a peripheral that was just started up, hence the reset reason).

Fullscreen connection_flow.txt Download

[00:00:11.579,681] <inf> ble: Scanning ..
[00:00:11.827,819] <inf> ble: Device found: DE:56:FE:56:A4:A9 (random), RSSI: -70
[00:00:12.331,939] <inf> sensor: sensor_connect: Connecting to sensor with address DE:56:FE:56:A4:A9 (random)
[00:00:14.683,898] <inf> pss_client: Reset reason received: 4096
[00:00:14.684,326] <inf> sensor: Sensor with address DE:56:FE:56:A4:A9 (random) has UUID 996b1211dbecbdfd, FW version 0.7.2, reset reason 4096
[00:00:14.783,813] <inf> sensor: Time synchronized for sensor 996b1211dbecbdfd
[00:00:14.784,851] <inf> gateway: sensor_connected: Connected sensors = 1
[00:00:14.885,620] <inf> ble: Scanning ..
[00:00:17.683,746] <inf> ble: Connection parameters updated: interval 500.00 ms, latency 2 intervals, timeout 10000 ms

I don't have a full log from the disconnect process at the ready, but I can tell that the disconnect reason is recorded in the on_disconnected callback on the nRF52840 of the nRF9160DK and forwarded to the nRF9160 to be included in a periodic update message to our cloud infrastructure. That's how I can see how often/when it happens without having actual logs.

I'll try to get some logs from a disconnect event, but it may take some time until I get it.

In the meantime, I wanted to already check to see if there are specific things I should log as part of the application to provide as much information as possible? My thinking is that the main reasons for the peripheral for not being able to respond within the timeout would be a reset on the peripheral or a low quality connection which should be characterized by low RSSI. I'm monitoring both factors, and they both seem fine. So are there other things I should try to monitor or investigate?

Best,

Wout

[Simonr]

Hi

Are you connecting multiple boards to the central device here? If so, how many? If you have a lot of connected devices, increasing the connection supervision timeout to make sure all devices are able to get back to the central before they time out. Especially if the disconnects happen rarely, I think increasing the timeout should help a lot.

It's difficult to find specific factors to monitor here. The best way to find what the restricting factor is would be a sniffer trace to monitor what's going on on-air, but as you say, that might not be too easy to make happen.

Best regards,

Simon