Reading & notifying

Reading vs. notifying

Up to the version 9.6.7.0 of the blessTags application, the data transfer was carried out mainly, only where it was possible, through the notification mechanism. In this way, the battery on the SensorTag was saved and higher data transfer speeds were also achieved. 

Starting with blessTags application version 9.7.8.0 both reading and notifying data transfer was implemented, each time when a SensorTag allows us (when a characteristic support both mechanism of data transfer).

But what it is the significance of reading or notifying operations?

When a smartphone application or a PC application (like blessTags application) interacts with a SensorTag, over a Bluetooth connection, we have a client/server architecture. In our case, the application (e.g. blessTags application) is the GATT client and the SensorTag is the GATT server.

The hierarchical organization of the Services, Characteristics and Descriptors is presented in the above figure. In a Bluetooth device, a Service contains, at least, one or more Characteristics. A Characteristic owns none or more Descriptors. The Descriptors are completely optional, but a Service must contain at least one Characteristic.

In a Bluetooth SensorTag, part of the Characteristics are items of data which are related to a state of one sensor or of another sensor. Other Characteristics represent configuration data such as the period at which a sensor will measure a specific information – e.g. the ambient temperature.

Each Characteristic may have various properties. These properties define what kind of operations are allowed or can be configured for the values associated with each Characteristic. Most common properties are:

• Read (data transfer took place from server to client): if enabled, it will allow a client (an application) to read a value from the SensorTag (the server). 
• Write (data transfer took place from client to server): if enabled, it will allow a client to change a value from the SensorTag. 
• Indicate: if enabled, the client will be notified if a value changes (e.g. a new data was acquired) – in this case, a confirmation from the client to the server is expected. 
• Notify: if enabled, the client will be notified by the SensorTag if a value belonging to a specific characteristic change – in this case, a confirmation is NOT expected.

Usually, a value may be read or write by specifying the characteristic's UUID.

The values associated with some characteristics could have multiple modes of data acquisition – e.g. through notifying and reading, like the temperature Characteristic of the CC2650STK and CC2541DK SensorTags, see the following two figures (the first one it is a print screen of the developer window of blessTags application and the second one is from Wikipedia official page of the CC2541DK SensorTag).

Information (service, characteristics and descriptors) obtained through the 

data developer functions of the blessTags applications

All these data were taken from the Wikipedia official page of the CC2541DK SensorTag User Guide

       Another Characteristic can only be accessed based only one method of data reading. One such example is the reading of the buttons states on the CC2650STK and CC2541DK that can only be read by means of the notification mechanism, see figures below (the first one it is a print screen of the developer window of blessTags application and the second one is from Wikipedia official page of the CC2650STK SensorTag). 

Information (service, characteristics and descriptors) obtained through the data developer functions 

of the blessTags applications

All these data were taken from the Wikipedia official page of the CC2650STK SensorTag User Guide

Indications and Notifications provide a more efficient way for Clients to know when a value has changed.

The client (the application) may request a notification (or an indication) for a particular characteristic from the server (SensorTag) – the settings of this request must be configured by the client only one time at the beginning. The server can then send the value to the client whenever it becomes available or when a value has changed (instead of having to manually poll continuously and read the characteristic value to know when it changes). On each notification, your program (blessTags in our case) only get an event saying "you have received a packet" and in the associated function you will get the data packet.  For instance, a temperature sensor may notify its client every time it takes a new measurement. Using this approach, it will avoid the need for the client to continuously poll the server, which would require the server's radio circuitry to be constantly operational. Minimizing radio usage is especially important when developing systems that must work longer on a coin cell battery – like our SensorTag systems, mainly because radio usage has an adverse effect on a device’s battery life.

Notifications are also preferred if you need a higher data transfer rate between the server and the client. Using notifications, the server can queue a certain number of packets before sending – in this mode a higher data transfer ration can be achieved.