Bluetooth LE (Low power bluetooth®)-part fifth

Review:

In the previous articles in this series we completed the discovery of a BLE sensor and established a connection with it. Now it's just getting the data from it, but it's not as simple as it looks. In this article we will discuss the characteristics of GATT and how to facilitate the exchange of data between the host and the sensor.

Structure of the GATT server:

In the previous article we learned that the sensor contains the GATT server, we have also established a connection with GATT. The GATT server contains one or more GATT services, and the different GATT services represent different types of data that can be exchanged. For example, there are different GATT services in Sensortag that represent different sensor components in the sensortag (humidity sensors, barometric pressure sensors, etc.).

Each GATT service contains one or more GATT attributes. An GATT feature is an atomic data that can be passed through BLE. An GATT attribute can contain arbitrary data, with a type identifier representing the type of any data. It can also contain 0 or more GATT descriptors.

The GATT descriptor contains atomic data about the GATT characteristics, such as the units of the GATT attribute values, or whether it is necessary to notify us when the GATT eigenvalues change.

In summary, the GATT server may contain one or more GATT services, and each GATT service may contain one or more GATT attributes, each of which may contain 0 or more GATT descriptors.

One common denominator of GATT services, features, and descriptors is that they all use a common unique identifier (UUID) identifier. As the UUID name shows, the UUID is a simple and unique identifier used to find the GATT service, features, and descriptors.

Sensortag's UUIDs can be found in the GATT Server reference documentation. This may be a bit confusing, but it's actually very simple. All Sensortag UUID is based on this form: F0000000-0451-4000-b000-00000000. The number of the four boldface characters is different from the GATT service, the characteristic, the description is the unique place. If we look at the humidity sensor below, we can see that its UUID is for AA20 (type Gatt_primary_service_uuid). The complete UUID of this service is f000aa20-0451-4000-b000-00000000.

There are two features of the service:

The first represents the actual sensor data, the UUID is AA21, and the converted complete UUID is F000AA21-0451-4000-b000-00000000. These data are 4 bytes, which represent the temperature and humidity values: TempLSB:TempMSB:HumidityLSB:HumidityMSB We will see how to decode. The feature has a descriptor (Gatt_client_char_cfg_uuid entry) that does not have a UUID definition for that feature in the document. This is because this is a standard UUID, because it provides a common function and is used together, that is, we need to be notified when the value changes. We will discuss this in depth later.

The second feature is a flag that requires us to set it to an open state, the UUID is AA22, and the full UUID is F000AA22-0451-4000-b000-00000000. Or that sentence, we will see how it is used in due course.

It is necessary to explain some of the things about UUID and how UUID works, and in some cases they may not be as significant features of devices as they do on Sensortag. Many of the sensors may have a common UUID and structure, and different vendors insist on using a standard GATT service standard for sensors that perform the same function (e.g. with a dedicated heart rate, GATT service standard, etc.). Also, it is possible to include GATT service UUIDs in the device discovery phase to match devices which offer Specifi C Services. 。 Unfortunately, Sensortag does not support this, so this piece is not covered in this tutorial. If you are interested, you can do this by calling different forms of the Bluetoothadapter#onstartlescan () method.

So, now that we know how the service is organized, we can start reading the data, right? Unfortunately, it's not that simple. Remember that the connection to the GATT server consists of two parts: the GATT server on the sensor, and a local proxy. Although we may know the GATT service, the local agent does not know, so we want the local agent to get a list of its services from the sensor. This is accomplished by using the Discoverservices () method:

Private Bluetoothgattcallback Mgattcallback = new Bluetoothgattcallback () {    @Override public    Void Onconnectionstatechange (Bluetoothgatt GATT,         int status, int newstate) {        Super.onconnectionstatechange (GATT, status, NewState);        LOG.V (TAG, "Connection State Changed:" +             (newstate = = bluetoothprofile.state_connected?                 ") Connected ":" Disconnected "));        if (newstate = = bluetoothprofile.state_connected) {            setState (state.connected);            Gatt.discoverservices ();        } else {            setState (state.idle);        }    }    @Override public    void onservicesdiscovered (Bluetoothgatt GATT,         int status) {        if (status = = bluetoothgatt.gatt_success) {            log.v (TAG, "onservicesdiscovered:" + status);}}}    

Again, this is an async method, so we can invoke it without any hesitation in the UI thread, and we need to define an appropriate callback method that is called when the list of services is complete. It is important to check the status value in the callback method, because sometimes the corresponding callback is invoked during the search service, but the search service is actually complete. So checking whether the Gatt_success status will ensure that once the service discovery is complete our callback method executes only once.

Next Issue preview:

Once the supported service is loaded into the local agent, we can access the features that the service contains, and we'll discuss this in a summary of this series of articles.

The source code for this article can be found here.

Bluetooth LE (Low power bluetooth®)-part fifth