Holiday Bluetooth Engineer, ATT protocol
Foreword
After getting notification from my heart rate sensor through RPi, the next step is to figure out the BLE protocol. I would like to provide some examples illustrating how GATT/ATT works. Hope that this article can help people who want to understand BLE.
ATT (Attribute)
All BLE devices support ATT protocol. ATT stands for attribute. It looks like an table with following data structure:
struct {
u16 uuid; // Universally Unique Identifier
u8 *data; // variable length data
} att[65536];
The ATT protocol is a table under the hood. The data structure enables us doing random access through array-index. In BLE terminology, the array index is "handle". Each entry in the table has an 16bit UUID field describing what's the data is (metadata). Another interesting point is that data is just a pointer, which enables variable length data structure.
In last post, I used the gatttool to communicate with the BLE device. The tool is actually talking to ATT layer of BLE device. Refer to the tool's help window again will give you some feeling:
In gatttool, executing "char-desc" command will return the handle & uuid of the table. You can imagine its pseudo look like:
The commend yields following screenshot:
After getting notification from my heart rate sensor through RPi, the next step is to figure out the BLE protocol. I would like to provide some examples illustrating how GATT/ATT works. Hope that this article can help people who want to understand BLE.
ATT (Attribute)
All BLE devices support ATT protocol. ATT stands for attribute. It looks like an table with following data structure:
struct {
u16 uuid; // Universally Unique Identifier
u8 *data; // variable length data
} att[65536];
The ATT protocol is a table under the hood. The data structure enables us doing random access through array-index. In BLE terminology, the array index is "handle". Each entry in the table has an 16bit UUID field describing what's the data is (metadata). Another interesting point is that data is just a pointer, which enables variable length data structure.
In last post, I used the gatttool to communicate with the BLE device. The tool is actually talking to ATT layer of BLE device. Refer to the tool's help window again will give you some feeling:
for handle in range(1, 65535):
if att[handle] is effective:
if att[handle] is effective:
print "handler=%d, uuid=%d", i, att[i].uuid
The commend yields following screenshot:
So implementing such ATT protocol in either 8051/ARM is not hard. It's just a data structure to store data. Here is some additional point:
- UUID stands for Universal Unique IDentifier, which is the metadata describing how to interpret the data. By searching some keyword "Bloetooth BLE NNNN" and one can find its definition easily.
- ATT protocol has no limitation on data length. The actual limitation is from upper layer, GATT.
Take handle[0x3] as example, reading the handle via gatttool tells us the device name (UUID = 0x2A00). The screenshot show read-back value is 0x48, 0x52, 0x4D. By checking the ASCII code, they are "HRM" which is the same one I seen in smart phone.
The BLE Device
After doing some hard work to check all ATT fields, I got table below. It showed some internal parameters of the heart rate monitor. For example, it's based on CSR solution (handle[0x1f]) and the development kit is "uEnergy SDK 1.4.3" (handle[0x1b]).
* Generic Access Service
handle: 0x0001, uuid: 2800 1800, Generic access
handle: 0x0002, uuid: 2803 0a 0003 2a00
handle: 0x0003, uuid: 2a00 Device Name, "HRM"
handle: 0x0004, uuid: 2803 02 05 2a01
handle: 0x0005, uuid: 2a01 Appearance, 0x340=832, Generic Heart Rate Sensor
handle: 0x0006, uuid: 2803 02 07 2a04, Peripheral preferred connection parameter
handle: 0x0007, uuid: 2a04 000a 0010 0064 04e2
min-connection-interval = 0xA * 1.25ms = 12.5ms
max-connection-interval = 0x10 * 1.25ms = 20ms
Slave latency = 0x64 * interval = 100*interval = 1.25s ~ 2s
Connection Superviser Timeout = 0x4E2 * interval = 1250 * interval = 15.625s ~ 25s
* Generic Attributes
handle: 0x0008, uuid: 2800 1801, Generic attributes
* Heart Rate
handle: 0x0009, uuid: 2800 180D, Heart Rate
handle: 0x000a, uuid: 2803 10 000b 2a37
handle: 0x000b, uuid: 2a37 Heart rate measurement, only notify (*)
handle: 0x000c, uuid: 2902 Control channel
handle: 0x000d, uuid: 2803 02 000e 2a38
handle: 0x000e, uuid: 2a38 01, chest
handle: 0x000f, uuid: 2803 08 0010 2a39
handle: 0x0010, uuid: 2a39 Heart rate control point
* Battery Service
handle: 0x0011, uuid: 2800 180F, Battery Service
handle: 0x0012, uuid: 2803 12 0013 2a19
handle: 0x0013, uuid: 2a19 Battery level, 0~100
handle: 0x0014, uuid: 2902 Control channel
* Device Information
handle: 0x0015, uuid: 2800 180A, Device Information
handle: 0x0016, uuid: 2803 02 0017 2a25
handle: 0x0017, uuid: 2a25 Serial Num, 34 36 58 41 36 37 39 57 44 4e 44 52 43 58 37 50 00
handle: 0x0018, uuid: 2803 02 0019 2a27
handle: 0x0019, uuid: 2a27 Hw Revision String, 41 30 34 55, “@04U"
handle: 0x001a, uuid: 2803 02 001b 2a26
handle: 0x001b, uuid: 2a26 FW Rev String, “uEnergy SDK 1.4.3”
handle: 0x001c, uuid: 2803 02 001d 2a28
handle: 0x001d, uuid: 2a28 SW Rev String, “1.4.3.1”
handle: 0x001e, uuid: 2803 02 001f 2a29
handle: 0x001f, uuid: 2a29 Manufacturer, “Cambridge Silicon R"
handle: 0x0020, uuid: 2803 02 0021 2a50
handle: 0x0021, uuid: 2a50 PnP ID, 01 000a 014c 0100, vendor-id-src, vendor-id, product-id, product-rev
Next Step: GATT
Based on the table above, it's more easier to understand the GATT protocol. I will write another article describing it.
留言