2

I'm writing a small BT app on a microcontroller (using aioble on Micropython), but my question is more general on the BT spec itself.

Since I'm still developing the device, I keep adding/changing services and characteristics all the time, and found out that Chrome seems to cache the old services and chars UUID it found from previous runs. I understand this is done for performance and resources reasons, but I'd like to invalidate this cache on every boot.

I found out about the Generic Attribute Service (0x1801) and the Service Changed Characteristic (0x2A05) which suppose to do exactly this. I couldn't find official specs in the official BT site (this link for example seems to be broken), but found some other resources that basically say that the server should send a notification with a value representing the range of handles that should be invalidated.

That sounds exactly like what I want, but nothing describes how do I represent a "handle range".. I basically want to erase all.

Any help? Also - do I write value to the char once at startup or I can send notification throughout the device's lifecycle?

Zach Moshe
  • 2,782
  • 4
  • 24
  • 40

1 Answers1

2

The Bluetooth Core Specification v5.3 describes the Service Changed Characteristic on page 1532:

The Service Changed Characteristic Value is two 16-bit Attribute Handles concatenated together indicating the beginning and ending Attribute Handles affected by an addition, removal, or modification to a GATT-based service on the server. A change to a characteristic value is not considered a modification of the service. If a change has been made to any of the GATT service definition characteristic values other than the Service Changed characteristic value and the Client Supported Features characteristic value, the range shall also include the beginning and ending Attribute Handle for the GATT service definition.

This table describes the value decleration needed for the Service Changed Characteristic: Service Changed Characteristic Value declaration

Michael Kotzjan
  • 2,093
  • 2
  • 14
  • 23
  • thanks! exactly what I was looking for. Something still doesn't seem to work for me - I don't need any fine-grained control, so I passed 0x0000 and 0xFFFF as the boundaries, assuming this would invalidate all cached information from this device, but I still don't see the newly added characteristics. In my server code, I notify the client immediately upon connecting (with the data of the 4 bytes 0x0000FFFF). Do I need to do anything else? – Zach Moshe Aug 29 '22 at 08:45
  • Bluetooth stacks handle the Service Changed Characteristic differently. For example, just the existence of the Service Changed Characteristic causes iOS to simply not cache anything at all for this specific device whereas Android requires the indication to be sent. I'm not sure how Chrome (We are talking about the browser here, aren't we?) handles this part of the Bluetooth spec – Michael Kotzjan Aug 29 '22 at 09:41
  • Yes. Chrome. I wasn't aware that there are differences there. Would expect this to be defined in the BT specs... Thanks! I'll try to ask in Chrome forums. – Zach Moshe Aug 29 '22 at 10:49
  • The Bluetooth specs are actually not that strictly defined as the name suggests – Michael Kotzjan Aug 29 '22 at 10:51