Introduction to Bluetooth Low Energy
You will be redirected back to this guide once you sign in, and can then subscribe to this guide.
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.
The following diagram should explain the way that Bluetooth Low Energy devices work in a connected environment. A peripheral can only be connected to one central device (such as a mobile phone) at a time, but the central device can be connected to multiple peripherals.
If data needs to be exchanged between two peripherals, a custom mailbox system will need to be implemented where all messages pass through the central device.
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.
An important concept to understand with GATT is the server/client relationship.
The peripheral is known as the GATT Server, which holds the ATT lookup data and service and characteristic definitions, and the GATT Client (the phone/tablet), which sends requests to this server.
All transactions are started by the main device, the GATT Client, which receives response from the secondary 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 main device initiating every transaction:
GATT transactions in BLE are based on high-level, nested objects called Profiles, Services and Characteristics, which can be seen in the illustration below:
A Profile doesn’t actually exist on the BLE peripheral itself, it’s simply a pre-defined collection of Services that has been compiled by either the Bluetooth SIG or by the peripheral designers. The Heart Rate Profile, for example, combines the Heart Rate Service and the Device Information Service. The complete list of officially adopted GATT-based profiles can be seen here: Profiles Overview.
Services are used to break data up into logical entities, and contain specific chunks of data called characteristics. A service can have one or more characteristics, and each service distinguishes itself from other services by means of a unique numeric ID called a UUID, which can be either 16-bit (for officially adopted BLE Services) or 128-bit (for custom services).
A full list of officially adopted BLE services can be seen on the Services page of the Bluetooth Developer Portal. If you look at the Heart Rate Service, for example, we can see that this officially adopted service has a 16-bit UUID of 0x180D, and contains up to 3 characteristic, though only the first one is mandatory: Heart Rate Measurement, Body Sensor Location and Heart Rate Control Point.
The lowest level concept in GATT transactions is the Characteristic, which encapsulates a single data point (though it may contain an array of related data, such as X/Y/Z values from a 3-axis accelerometer, etc.).
Similarly to Services, each Characteristic distinguishes itself via a pre-defined 16-bit or 128-bit UUID, and you’re free to use the standard characteristics defined by the Bluetooth SIG (which ensures interoperability across and BLE-enabled HW/SW) or define your own custom characteristics which only your peripheral and SW understands.
As an example, the Heart Rate Measurement characteristic is mandatory for the Heart Rate Service, and uses a UUID of 0x2A37. It starts with a single 8-bit value describing the HRM data format (whether the data is UINT8 or UINT16, etc.), and then goes on to include the heart rate measurement data that matches this config byte.
Characteristics are the main point that you will interact with your BLE peripheral, so it’s important to understand the concept. They are also used to send data back to the BLE peripheral, since you are also able to write to characteristic. You could implement a simple UART-type interface with a custom ‘UART Service’ and two characteristics, one for the TX channel and one for the RX channel, where one characteristic might be configured as read only and the other would have write privileges.
This guide was first published on Mar 20, 2014. It was last updated on Mar 20, 2014.
This page (GATT) was last updated on Jan 24, 2014.
BLE & GATT или как отправить данные по Bluetooth.
Разрабатывая кормушку для кота, я в итоге прикрутил к ней блютус. Конечно, можно поставить на телефон обычный Bluetooth to Serial Terminal и спокойно слать нужные команды. Но так как мы не ищем простых путей, я решил написать свое приложение (на JS + Cordova) для общения с модулем HM-10. Однако, общение оказалось не таким простым, как c обычными Bluetooth устройствами. А все почему? Да потому что устройства BLE имеют немного другой принцип коммуникации.
BLE
Принцип работы BLE описан уже в его названии: Low Energy. Протокол подразумевает передачу данных короткими пакетами по необходимости, затем – выключение передатчика. Низкое энергопотребление частично достигается применением именно этого принципа. Вместо классического тандема в обычном Bluetooth, устройства BLE связываются друг с другом лишь при необходимости отправки или получения информации.
Протокол BLE строго структурирован по принципу своей коммуникации с другими устройствами. Вначале девайсы изучают доступные сервисы для отправки/принятия данных; неотъемлемая часть этих сервисов – их характеристики (characteristics), определяющие тип данных для будущей передачи. Характеристики, из соображений наглядности, могут иметь в своём составе описания-дескрипторы (descriptors), которые помогают определить тип данных. К примеру, разберём сервис под названием «Heart Rate Monitor» (монитор частоты сердцебиения) – среди его характеристик присутствуют такие, как «измерение пульса».
Большинство API для Bluetooth LE позволяют искать локальные устройства и определять доступные в них сервисы, характеристики и дескрипторы.
Термины и концепции протокола BLE
Предлагаю вашему вниманию краткий обзор ключевых терминов протокола BLE и его концепций. До начала работы над проектом BLE нужно понимать каждый из них.
Профиль общих атрибутов (GATT)
Профиль общих атрибутов (General Attribute Protocol, GATT) – это обязательный профиль с общими спецификациями отправки и приёма коротких порций данных, известных в Bluetooth Low Link под названием «атрибуты». Все нынешние профили приложений LE основаны на GATT. Институт стандартизации и разработки протокола – Bluetooth Special Interest Group уже задал для устройств BLE несколько профилей. Эти профили представляют собой спецификации, описывающие способ применения и взаимодействия с устройствами.
Протокол атрибутов (ATT)
Протокол атрибутов (он же Attribute Protocol, ATT) – основывается на GATT. ATT – оптимизированный протокол, созданный исключительно для устройств BLE. Принцип ATT – отсылать столь малое количество байтов, насколько это возможно. У каждого атрибута есть уникальный универсальный идентификатор, UUID. Он представляет собой стандартизированный 128-битный строковый ID, используемый для идентификации уникальной информации. Формат атрибутов, передаваемых как ATT, бывает двух типов: характеристики и сервисы:
Характеристика (Characteristic)
Характеристика содержит однозначный параметр, а также дескрипторы. Количество дескрипторов может быть равно нулю, то есть это не обязательная часть характеристики. Дескрипторы описывают значение характеристики.
Дескрипторы (Descriptors)
Дескрипторы представляют собой определённые атрибуты, которые описывают значение характеристики. Дескрипторы могут быть в виде понятных описаний на вполне человеческом языке, определять единицы измерений, а также задавать ряд допустимых значений.
Сервис (Service)
Сервис это совокупность характеристик. Список существующих профилей на основе GATT можно просмотреть здесь.
Работа с GATT в Cordova
Для большей наглядности взаимосвязи этих терминов приведем схему
Т.е. профайл устройства HM-10 имеет несколько сервисов, каждый из которых включает себя различные характеристики.
Пока не особо понятно, как мне теперь со всем этим работать. Естетсвенно, порыскав в гугле я начал пробовать все это на практике.
Для Cordova есть модуль для работы с BLЕ — BLE Central. Подключив его и посмотрев характеристики моего HM-10, я увидел следующее.
Вот наши сервисы:
А вот наши характеристики:
В блоге BLE нам говорят о том, что стандартный режим работы с HM-10 это работа с сервисом 0000ffe0-0000-1000-8000-00805f9b34fb, также упоминают единственную характеристику 0000ffe1-0000-1000-8000-00805f9b34fb.
Т.е. в описаниях сервисов и характеристик uuid указан неполностью (сервис — ffe0, характеристика — ffe1)
Однако это все я узнал немного позднее. Сначала я экспериментировал с передачей данных подключаясь к устройствам исходя из описания характеристик.
bleService = connectedDevice.characteristics.find(function(item) < return item.properties.indexOf('Read') >-1 && item.properties.indexOf('WriteWithoutResponse') > -1 >) Мне нужно было найти такую характеристику, которая позволяла бы передавать и получать данные. Как я понял, описание этих характеристик и сервисов должно быть в тех документации к каждому BLE-устройству.
Подключаемся к устройству через функцию ble.connect(device_uuid) .
Отключитсья можно через ble.disconnect(device_uuid) (неожиданно, да?).
Отправляем данные через ble.write(device_uuid, service, characteristic, stringToBytes(data), . callbacks) ;
Чтобы получить данные от устройства нам нужно подписаться на обновления ble.startNotification(connectedDevice.id, bleService.service, bleService.characteristic, . callbacks) .
В принципе, этого мне было достаточно, для того чтобы передавать нужные команды и получать фидбек от устройства.
Если у Вас есть что добавить, уточнить или указать мне на неточности или ошибки, пишите комментарии. Потому что некоторые углубленные моменты для меня остались непонятны 🙂
В статье были исользованы материалы с хабра и оф сайта Bluetooth
Присоединяйтесь к нашим каналам FrontEndDev и Web Stack и моему личному блогу Sleepless Tech в Telegram, чтобы не пропустить самое интересное из мира Web!
