How are the BLE attribute handle offsets defined?

[BPaik]

Where can I find documentation on the BLE attribute handle offsets? I was adapting code from the sensor demo for the BLE NRG 2 and am trying to understand the "aci_gatt_attribute_modified_event" callback. Through observation and experimentation I found that adding 1 to the attribute handle identifies write characteristic events from the BLE client and adding 2 to the handle identifies characteristic notifications being enabled or disabled. I haven't seen any description of this behavior in the BLE programming guide, but I would like to know all the available offsets and what they are for.

[Winfred LU · Accepted solution]

The handles are sequentially assigned during the server initializing its services and attributes.

The client has to use the service and characteristic discovery to obtain all the handles of the attributes it is interested in.

This is not in programming guide because it is more likely to be a background knowledge for Bluetooth GATT/GAP.

https://www.bluetooth.com/bluetooth-resources/intro-to-bluetooth-gap-gatt/

[paul19]

Hi @BPaik​ . Did you finally understand what's happening with this handle offset? @Winfred LU​ 's answer doesn't seem to help...

[BPaik]

I recall seeing a table that had a list of all the GATT offsets and what they correspond to. I've been searching online, but I can't seem to find it anywhere. It's strange that it so difficult to find despite being common knowledge. The two I use in my code are 1 for a write event, and a 2 for enabling notifications.

[paul19]

Thanks a lot. I cannot find this table either. Hopefully one day someone will do and post it here.

Also, in the sample code, I think ST should replace the puzzling hard coded constants with meaningful #define.

[BPaik]

Haha yeah, "magic numbers" are generally frowned upon for this exact reason.​

[Winfred LU]

The handlers aren't magic numbers.

Each BLE device can have very different services and attributes, which indicates that the handlers are different a lot.

Even for the devices with same attributes, they CAN have different handler assigning due to implantation.

Thus, there is no way to #define them.

The GATT client has to perform the Service Discovery and Characteristic Discovery to understand all handlers in a server.

[BPaik]

We were not referring to the handles themselves being "magic numbers" - we were referring the handle offsets used in the software examples. Specifically, the function "Attribute_Modified_Request_CB" looks at specific offsets from the handle addresses for things like notify enable. Checking for enabling or disabling notifications in the code looks like this:

if(attr_handle == ReadCharHandle + 2) {}

In this case it appears that the notify enable offset is +2 from the handle address. What we are looking for is a list of offsets and descriptions of what they correspond to. For instance:

+1 new data received from client

+2 notify enable or disable

+3 ?

+4 ?

+5 ?

[Winfred LU]

An attribute handler plus some offset is another attribute handler.

There is no magic number here. The assigning of the handlers can vary depending on that GATT server.

The implementation with BlueNRG-2 (stack) may not be the same as others.

As explained in the Core spec:

The Attributes are ordered by increasing Attribute Handle values. Attribute Handle values may begin at any value between 0x0001 and 0xFFFF. Although the Attribute Handle values are in increasing order, following Attribute Handle values may differ by more than one. That is to say there may be gaps between successive Attribute Handles. When the specification requires two attribute handles to be adjacent or for one to immediately follow one the other, such gaps are still permitted and shall be ignored.

Please use "Discover All Characteristic Descriptors" sub-procedure In case you'd like to know what the descriptors are:

[BPaik]

The example software is intended for the BlueNRG-2 stack, so software definitions should still be possible since they don't need to be compatible with any other type of GATT server. (Even so, #ifdef statements could still be used to redefine constants for different BLE stack targets). Are you saying that the BlueNRG-2 stack assigns handle offsets differently for each charactersistic? (For instance, notify enable may be "handle + 2" for one characteristic and "handle + 4" for another characteristic when using the BlueNRG-2 stack?).