Discovery Optional?


#1

When read/writing characteristics, can the discovery step be skipped if the characteristic handles are already known from a previous connection?


#2

Hi @panda, currently the Duo doesn’t cache the peer device’s GATT data base, so it has to discovery the service every time it connect with peer device. And we are not going to implement this feature. Much sorry for that :cry:


#3

It appears that while the library does not cache the GATT if I cache it manually (in the SPI flash for example) then I can avoid having to do discovery every time I connect. If the attribute handles are known then there is no need to discover. At least in my testing that is how it behaves.


#4

Ohhhh, I spoke too soon. While I can read etc, writing characteristics has issues. The write command actually reaches the peripheral BLE device, but the payload data is wrong. Any ideas how I would go about working around this? I am thinking the discovery process creates a map that includes the attribute length. Despite passing the data length and data to the writeValue() function, something is still not getting passed correctly to the periperal device.

Why am I avoiding discovery you ask? I have an application that requires very short connection times and the discovery process takes time. I previously was using a SiLabs chip set that did not have this limitation. You could pass the attribute handles without any need for discovery.


#5

Hi @panda, essentially you should cache the attribute handles. The data and data length you passing to the writeValue() function is your own data and nothing about the GATT attribute table.


#6

Yea, caching is of coarse what I am doing and I would have thought it was that easy, but there is something with the discovery process that then allows writes to work. I can not use the cached handles alone. I have to actually do the discovery after connect to allow writes to operate properly. Seems like it could point to a bug.

Are you able to perform writes successfully (meaning: the expected data sent to the peripheral) without doing a discovery?


#7

I don’t think that some write permission is done during discovering services and characteristics.

Did you mean the value written to the peripheral device is not as expected you passing to the write function? Are you sure you were passing the right value handle to the write function? To verify this, you can write this characteristic with specific value handle after discovering procedure, and reconnect without discovery procedure and then write the same characteristic with the same value handle.


#8

I am passing the correct Val handle. Choosing to discover vs. not discover has an effect on the correct data getting to peripheral device. I found that I actually only need to discover services for the write to operate correctly. Odd right?


#9

Without discovering characteristics? I.e. you invoked the connect API in the service discovery callback? If so, that’s really odd, because discovering service does not provide any attribute handle in detail. @mringwal Any idea?

Btw, could you share your sketch here?


#10

I know sounds implausible, but in fact real. I can’t share sketch as-is, but perhaps have time tomorrow to post a simplified version.


#11

Assuming the attribute handles don’t change and you know them already, BTstack also provides functions to read/write characteristics just by their handle. see src/ble/gatt_client.h: e.g.

uint8_t gatt_client_read_value_of_characteristic_using_value_handle(btstack_packet_handler_t callback, hci_con_handle_t con_handle, uint16_t characteristic_value_handle);

or

uint8_t gatt_client_write_value_of_characteristic(btstack_packet_handler_t callback, hci_con_handle_t con_handle, uint16_t characteristic_value_handle, uint16_t length, uint8_t * data);