Maintaining a Long-Lived BLE Connection

[RodrigoM11]

Hello h2zero:

I'm trying to establish a permanent BLE connection between:

BLE Client: ESP32 running NimBLE-Arduino 2.5.1.

BLE Peripheral: nRF54L15 using the bluefruit.h library.

The peripheral sends temperature notifications whenever an alert condition occurs. Notifications are event-driven rather than sent at fixed intervals.

My main concern is maintaining a stable connection over many hours or days and ensuring reliable recovery after an unexpected disconnection.

Current behavior

I've implemented a client using code based on the NimBLE_Client example provided with NimBLE-Arduino 2.5.1.

The connection works correctly for approximately one hour, but then the client loses the connection. If I restart the client code, the connection is successfully re-established and works for another similar period before disconnecting again.

I've monitored the peripheral and confirmed that it continues advertising and operating normally. It does not appear to stop transmitting or become unresponsive.

I would like to understand whether this behavior could be related to my client implementation, connection parameters, or reconnection logic.

Questions:

Could you recommend another client example or the recommended architecture for maintaining a long-lived BLE connection with this type of setup?

In particular, I'd appreciate your advice on the following:

Connection stability: Are there any specific settings or best practices for maintaining a BLE connection for many hours or days?

Notifications: Is there anything special I should consider when subscribing to event-driven notifications?

Connection parameters: What connection interval, peripheral latency, and supervision timeout would you recommend for this use case?

Disconnection handling: What should be done inside onDisconnect() to ensure reliable recovery?

Client lifecycle: After an unexpected disconnection, should the existing NimBLEClient be reused, or should it be deleted and recreated, or should NimBLE itself be restarted?

Memory safety: Are there any recommended practices to prevent invalid pointers, race conditions, or crashes during reconnection?

I've already reviewed the NimBLE_Client example, but my application requires a connection that remains active continuously and can recover reliably from unexpected disconnections.

Any guidance would be greatly appreciated.

[h2zero]

Hello @RodrigoM11

Long lived connections are difficult to maintain even in the best of environments, many factors contribute to the stability of such, so I will give you some ideas from experience.

1. Supervision timeout, this will determine how long inactivity is permitted before disconnection is assumed, this should be set to something you determine in your application to be too long/missing data etc..

2. the connection interval/window is basically controlling throughput, you didn't indicate the data rate requirement, tighter values for faster data.

Best way IMO to handle this is responding quickly to disconnects using the asyc connect option in the disconnect callback or some mechanism to trigger a connection call.

As a design note, if this value isn't updated very frequently, less than one every 5 seconds or so, then maybe advertising the value iteslf and finding it in the scan data would be best.

[RodrigoM11]

I'll try implementing asynchronous reconnection using the approach you suggested and see how it performs in my application.

Thank you !!

For your advice and for sharing your experience.