Skip to main content

Data Communication

We use the Bluetooth GATT service to communicate between the watch and the central device. For the details of the BLE commands please see the BLE Commands.

Introduction to GATT:​

GATT is an acronym for the Generic Attribute Profile, and it defines the way that two Bluetooth Low Energy devices transfer data back and forth using concepts called Services and Characteristics. It makes use of a generic data protocol called the Attribute Protocol (ATT), which is used to store Services, Characteristics and related data in a simple lookup table using 16-bit IDs for each entry in the table.

GATT comes into play once a dedicated connection is established between two devices, meaning that you have already gone through the advertising process governed by GAP.

The most important thing to keep in mind with GATT and connections is that connections are exclusive. What is meant by that is that a BLE peripheral can only be connected to one central device (a mobile phone, etc.) at a time! As soon as a peripheral connects to a central device, it will stop advertising itself and other devices will no longer be able to see it or connect to it until the existing connection is broken.

Establishing a connection is also the only way to allow two-way communication, where the central device can send meaningful data to the peripheral and vice versa. In other words, once a connection is established between a peripherals and central device, however, communication can take place in both directions, which is different than the one-way broadcasting approach using only advertising data and GAP.

GATT Transactions​

An important concept to understand with GATT is the server/client relationship. The peripheral (the watch in our case) is known as the GATT Server, which holds the ATT lookup data and service and characteristic definitions, and the GATT Client (the phone/tablet/computer) which sends requests to this server. All transactions are started by the master device, the GATT Client, which receives response from the slave device, the GATT Server.

When establishing a connection, the peripheral will suggest a 'Connection Interval' to the central device, and the central device will try to reconnect every connection interval to see if any new data is available, etc. It's important to keep in mind that this connection interval is really just a suggestion, though! Your central device may not be able to honour the request because it's busy talking to another peripheral or the required system resources just aren't available. The following diagram should illustrate to data exchange process between a peripheral (the GATT Server) and a central device (the GATT Client), with the master device initiating every transaction:

GATT includes services and characteristics. In this first implementation we use only the File Transfer Service and the RX and TX Characteristics. For sending/reciving data and commands between the watch and a central device, we use a custom service named BLE GATT Nordic UART Service. For the details of this service please refer to the following: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/include/bluetooth/services/nus.html

Implementation of the communication protocol in Java.​

The commands are listed in the code in the main file (called MainActivity.java) in an object called “BleCommand”. Each command is one byte and it may also follow a few data bytes.

For the details of the BLE commands please see the BLE Commands.

For example the command “CMD_Get_HRM_Size” is only one byte (equal to 3), while the command “CMD_Update_Time” (equal to 22) is always followed by 6 bytes (containing a date). A full list of already implemented commands is annexed to this document.

All the commands are sent through the FileTransferService using specific UUIDs. The general methods to implement the low-level transfer of BLE data are in the file FileTransferService.java. for example the function “public void sendCommand(int command, byte []data)” sends a command followed by its associated data into the watch. The response of the commands will be handled in a private function in the FileTransferService.java file named “broadcastUpdate” and it will be available in a public variable called “EXTRA_DATA”. Depending on the command the size of the response packet may be different. In the MainActivity.java, the method “BroadcastReceiver” is in charge of analyzing the received data.

On the other hand, in the firmware of the watch, a GATT server is implemented which I always listening to the BLE communication line. The BLE communication channel is emulated as a UART media through the Nordic BLE_NUS service library. Once a new packet of data arrives, it will process the first byte (the command byte) and depending on the value of this byte will process the next bytes and will perform the associated action of that command. If a command is a request of sending some data (called Get command) the watch will send a packet that includes the command byte and the requested data. On the watch a FIFO is implemented so that all the BLE commands get queued until addressed completely.