Advertising interval dependent issue: Could not get GATT services: Unreachable

[DaGigabyte]

Background

I have a custom BLE device with a known address that I would like to connect to using bleak. Using uart_service.py, I am able to connect to the device when its advertising interval is set to 500ms. However, when its advertising interval is 10240ms, uart_service.py always failed to connect to the BLE device.

Description of issue

uart_service.py

Since I know the address and the characteristics, I have slightly modified the uart_service.py to the following:

target_address = "f5:f5:22:22:33:44"
UART_TX_CHAR_UUID = "e09abcdef..."
UART_RX_CHAR_UUID = "e09abcdef..."
...
async with BleakClient(target_address, disconnected_callback=handle_disconnect, timeout=100) as client:
    await client.start_notify(UART_TX_CHAR_UUID, handle_rx)
    print("Connected, start typing and press ENTER...")
...

Case 1: Adv_int = 500ms

1. Launch script with python .\uart_service.py
2. After 1-5 seconds passed...
3. Connected, start typing and press ENTER...
4. At this point, I can type into the terminal and the communication with the BLE device characteristics works perfectly.

Case 2: Adv_int = 10240ms

1. Launch script with python .\uart_service.py
2. After 10-102 seconds passed...
3. Exception raised:

raise BleakError(f"{fail_msg}: Unreachable")
bleak.exc.BleakError: Could not get GATT services: Unreachable

My Intuition

This seem to be an advertising interval dependent issue. Increasing timeout parameter from the default 10s to 100s did not help to solve it. In both cases, I have verified that the BLE device is advertising at the correct interval using a nRF Connect app on my phone.

[dlech]

Which OS are you using?

You didn't give the full stack trace, but I'm guessing this is propagating an error from the OSes Bluetooth stack. So there isn't really anything we can do about it in Bleak.

[DaGigabyte]

The OS is Windows 11, running on a laptop that is BLE-capable.

May I know what kind of stack trace should I provide? I have installed Wireshark as recommended in the official debug guide, but I don't know what to filter or look for among the full stack trace.

[dlech]

May I know what kind of stack trace should I provide?

The stack trace from this exception:

raise BleakError(f"{fail_msg}: Unreachable")
bleak.exc.BleakError: Could not get GATT services: Unreachable

I assume there was more printed that included the stack trace?

I have installed Wireshark as recommended in the official debug guide, but I don't know what to filter

For issues like this, I usually look for what is different between a "good" capture and and "bad" capture.

[DaGigabyte]

I have captured the connection packets with WireShark. It seems that LE Create Connection is followed by LE Create Connection Cancel after 7.7s.
I have already passed timeout=100 into the context manager async with BleakClient(target_address, disconnected_callback=handle_disconnect, timeout=100) as client:
The only difference in the below cases is that the BLE device is programmed with a different advertising interval. The bleak code remains unchanged.

Advertising interval = 10240ms (Bad capture)

Advertising interval = 500ms (Good capture)

[dlech]

#1900 could possibly help with this.

[DaGigabyte]

As the PR #1900 is still in develop branch, how may I try out the development branch?

[dlech]

This was released in Bleak v2.1.1 already. But in general, pip and other tools allow installing Python packages from git if you ever need to test something not released on PyPI.

[MarcAlmirallBertran]

I don't know if this could be helpful, in our testing we need to do the pairing with pin, so we use BluetoothDevicePairing for this part, after this if we wait or not impacts directly to the fail rate, we added a 10s wait and all the tests failed, but if we delete this waiting time It works without any problem.

async def connect(self, *args, **kwargs):
    try:
        logger.info('Connect to charger')
        await self._client.connect()
        if not self.is_connected:
            logger.error('Failed to connect.')
            return False
        await asyncio.sleep(1)
        logger.info('Charger connected')
     except Exception as e:
         logger.error(e)
        raise Exception('Error connecting to charger')
    await self.start_notifications()


if self._pin:
    logger.info("Pairing started (attempt %d)", attempt)
    await self.pair_by_mac(self._pin)

await connect()
logger.info("Successfully connected to %s", self._address)

[ekspla]

@MarcAlmirallBertran I doubt what you observed is related to the OP's issue.

I saw many times in BLE sniffer logs that Windows OS tend to change the connection parameters
very frequently when connected, reagrdless of the version (10/11), especially when in idle.
So the 10s wait in your case can change the connection parameters.

[ekspla]

Please correct me if the followings are not true.

It seems to me, considering that the duration it takes to connect is probabilistic, that
the 10240 msec advertising interval is not comatible to those described in the official
Bluetooth Core Specifications (Volume 3, Part C, Appendix A, TIMERS AND CONSTANTS).

TGAP(100): 10.24 s

 Time span that a Bluetooth device performs device discover

 Recommended value

TGAP(adv_slow_interval): 1 s to 1.2 s

 Minimum to maximum advertisement interval in any discoverable or connectable mode 
 when background advertising on the LE 1M PHY

 Recommended value