Wireless Communication Library Support Forum

Frameworks => Bluetooth Framework => Topic started by: briandunham on September 15, 2022, 01:52:49 AM

Title: Unpredictable GATT Client Connects
Post by: briandunham on September 15, 2022, 01:52:49 AM
I am sometimes getting a WCL_E_BLUETOOTH_LE_CONNECTION_ESTABLISHING_FAILED (0X00051081) error when connecting to a GATT server. The error description says "LL initiated a connection but the connection has failed to be established. Controller did not receive any packets from remote end." Is there any way to make this more reliable from the client side? Like a longer wait before it throws an error?
Title: Re: Unpredictable GATT Client Connects
Post by: Mike Petrichenko on September 15, 2022, 09:03:25 AM
Hello,

This error usually appears if the server has random MAC and the MAC was changed while client trys to connect with previous MAC. Rediscovering should help.
Also this error may appear if the server accepts only single connection and the previous one was not closed yet (on server side). Closing connection usually takes about 2 * connect_interval.
Title: Re: Unpredictable GATT Client Connects
Post by: briandunham on September 15, 2022, 06:06:00 PM
I am always doing a discover before connecting and there are no other connections. So I'm wondering if it might be something else.
The server is running on an RTOS system that has other processes running. And those other processes might block the bluetooth process depending on priority. Is there some kind of timeout that the client has if the server doesn't respond quick enough? Could that timeout be extended?
Title: Re: Unpredictable GATT Client Connects
Post by: Mike Petrichenko on September 15, 2022, 06:13:08 PM
Unfortunately no. All you can do is change connection interval on Windows 11 or with BLED112 dongle.

More universal solution is simple try to reconnect: once you get this error during connection simple try to connect again.
Title: Re: Unpredictable GATT Client Connects
Post by: briandunham on September 15, 2022, 06:38:51 PM
Ah okay. A simple reconnect makes sense here and it's easy enough to implement clean reconnects. Thanks!