Read long characteristic

[Coimbra1984]

Is it possible to read more than 20 bytes ("read long") from a handle/UUID?

[peplin]

I'm not familiar with "read long" - is this part of the BLE spec? Does it just mean continuing to read from a characteristic until it returns no more data?

[Coimbra1984]

You can get details of "read long" for example from https://www.silabs.com/documents/login/reference-manuals/Bluetooth_Smart_Software-BLE-1.3-API-RM.pdf (page 58).

The command starts a procedure, where the client first sends a normal read command to the server and if the returned attribute value length is equal to MTU, the client will send further read long read requests until rest of the attribute is read.

[FlurinArner]

I'm having the same problem, but I think it's relevant to gatttool (BlueZ) and not directly to pygatt.

When I directly read my characteristic, with "gatttool -t random -b C8:91:43:82:D9:52 --char-read -a 0x000d", it correctly returns all 40 bytes of my characteristic.
When instead I enable notifications with "gatttool -t random -b C8:91:43:82:D9:52 --char-write-req -a 0x000e -n 0100 --listen", the value is truncated after 20 bytes. I can even go through an MTU_Request with "gatttool -t random -b C8:91:43:82:D9:52 -m 40 --char-write-req -a 0x000e -n 0100 --listen" and nothing changes.
My system is: Lenovo T570, Ubuntu 16.04.03 LTS, BlueZ 5.37 (5.37-0ubuntu5.1), pygatt 3.1.1 (pygatt 3.2.0 failed to discover characteristics, necessary for enabling notifications)

If I do the same with my cell phone (Sony Xperia XA1 Ultra, G3221, with Android 7.0, using nRF Connect), the entire 40 bytes are transmitted when I enable notifications.

[att365]

Having the same issue with the MTU size over 20 bytes... Any updates?

[Coimbra1984]

I added a PR #177 which at least adds the possibility to read more than 20 bytes for BGAPI devices. Unfortunately it doesn't enhance anything for the notifications.

[squarewavesbelow]

Same issue here as well. If a characteristic is longer than 20 bytes it gets truncated when I perform read operation from pygatt, but when I read the characteristic straight from gatttool I can read all of it. I have tried also with bluez 5.5. Can you please comment on this or suggest any possible workaround.

[EricGCooper]

Not sure if this applies in your case but increasing search_window_size in the GATTToolBackend constructor may help.

[EricGCooper]

Also, I had to set the mtu as a cli option as opposed to exchange mtu.

[YBDecawave]

Hello guys, any update regarding long read with PyGatt ?

[wlyzcz]

It need to be connect first,so you can set the mtu.

[gabmartinez]

Hello guys,

I had the same problem with the MTU size using gatttool and I fixed with the comment of @wlyzcz. I hope @peplin can add this feature soon to his library.

@wlyzcz thank you for your comment and thank you @peplin to share with us your library.

Regards,

[peplin]

v4.0 adds two new functions:

• char_read_long (Add char_read_long_handle to base device API #213)
• exchange_mtu (Added GATTToolBackend MTU-request #182)

Please give it a try, and open a new issue if it's not working as expected. Thanks!

[mattie47]

If like me, you came across this ticket on Google and are using gatttool backend but not getting all the expected data returned, refer to the following:

As peplin says above, exchange_mtu #182 implements the ability to set the MTU size for a frame. I initially dismissed this when looking through code because I was looking for "set" MTU rather than "exchange".

From this thread above, I initially thought you needed to set the MTU using GATTToolBackend() with cli_options set with either:
--m, ---mtu=MTU

This of course didn't work.

Instead it needs to be done like the example in PR: #182

After being set, it appears you still use char_read, and not char_read_long.

Thanks.