Hi,
-----Original Message-----
>Hi there,
>
>TL;DR: I have observed that BlueZ does some operations which incur in extra latency when connecting to a bonded peripheral. I would like to know if it's possible to remove those operations through configuration or, if maintainers are open for it, provide some patches to remove them.
>
>I have a BLE peripheral with a button. The button state (key pressed / key released) is associated to a custom characteristic (i.e. it's not HID). The state is conveyed through ATT notifications to a central running BlueZ (5.47, using dbus gatt api) with which it’s bonded.
>
>In order to save battery, the peripheral is normally disconnected and only starts advertising when the key is pressed. The central is always attempting to connect. Once the connection is established, the key-press in conveyed to the central as a notification (the central calls StartNotify() as soon as a connection is established).
>
>For the application’s purpose, it’s critical that the notification is recieved with the minimum latency.
Is there any reason why you wish to have the button in a disconnected state when inactive over having it in a connected state but with a high connection interval and a large slave latency? A high slave latency means it can stay in sleep mode if there is nothing to report back to the central device for a specified number of packets so is perfect for battery powered devices. Using this method means you don't have the slowdown in establishing a connection or exchanging GATT table information because the connection is live, and I think is preferable to burdening the BlueZ maintainers with maintaining a blacklist which, in my mind, really shouldn't be a part of BlueZ.
Thanks,
Jamie
��.n��������+%������w��{.n�����{��� �^n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
