0

Suppose we have a BLE GATT server which can be triggered to execute a search. The search yields a list (e.g. of device names). The list can be (way) longer than 512 bytes, so the result cannot be stored in a single characteristic.

What is the intended way to expose such a list via GATT? I can find no documentation about this. Is there any documentation in the BLE specification or in related documents discussing this which I overlooked?

None of the (standard) examples or specifications I can find (e.g. on https://www.bluetooth.com/specifications/gatt/) contain a list.

I can think of the following strategies:

  • Expose a service which contains the result with n characteristics (dynamic, one per list entry). The service is created and exposed dynamically as a result of the search operation. The service will be removed after the client confirms reading the data or after a certain time.
  • Expose a service statically which contains the result with n characteristics (static, e.g 100). The service also contains a characteristic which contains the number of list entries).
  • Expose a service statically which contains a "value" characteristic which offers the current value of the list. The service also contains a "next" characteristic which updates the "value" characteristic with the next value on write.
  • Expose a service statically which contains a "value" characteristic. The client has to subscribe to this characteristic for notifications/indications. Write one list value to the characteristic after the other. The client has to combine the notifications to a list.

Are one or more of the strategies the intended way to go? Or is there a different strategy that should be applied?

DrP3pp3r
  • 803
  • 9
  • 33
  • 1
    I would go with option 3 or 4. Most likely 4. Option one might probably be problematic if you use smartphone because I'm not sure how reliable service rediscovery is. With option two it will take a lot of time to discover services. – Emil Sep 06 '19 at 08:03
  • 1
    I have used a mix of 3 and 4; have a big characteristic which serves as output-buffer, and a small one as notification. Whenever the data in the output-buffer is updated, the device would also update the notification characteristic with an incremental 'packet' number. When the client sees the notification, it will read the host's output-buffer. Whenever the client requests data, it increments the last received packet-id by one and writes that to a third characteristic. This notifies the host that the output-buffer has been read, and new data can be put into it. – markus-nm Sep 06 '19 at 10:52

0 Answers0