Организация обмена данными с BLE-устройствами: GATT, MTU, очереди

Организация GATT-обмена с BLE-периферией

Представьте: вы разрабатываете приложение для взаимодействия с медицинским датчиком пульса через BLE. После подключения вы пытаетесь подписаться на уведомления о сердечном ритме, но данные не приходят. На Android вы видите ошибку status 133, а на iOS запись характеристики возвращает ошибку. Мы сталкивались с этим в более чем 20 проектах по интеграции BLE-устройств: медицинские датчики, фитнес-трекеры, промышленные контроллеры. Одна из частых задач — подписка на уведомления о сердечном ритме или передача больших объёмов данных, например, прошивки размером 100 КБ. При стандартном MTU в 23 байта на отправку 100 КБ уходит около 5000 пакетов, что занимает минуты. Запрос увеличенного MTU до 512 байт сокращает количество пакетов до ~200 и время передачи до нескольких секунд. Мы выработали системный подход к организации надёжного обмена данными с BLE-устройствами: от правильной подписки на уведомления до очереди операций и MTU-negotiation.

Типы операций с характеристиками GATT

Каждая GATT-характеристика имеет набор флагов properties, которые определяют, какие операции с ней возможны. Вот таблица для быстрой справки:

Write Without Response быстрее — нет ACK от устройства. Подходит для потоковой передачи (аудио, показания датчиков). Write — для команд, где важна гарантия доставки.

MTU: как увеличить пропускную способность BLE-канала

По умолчанию MTU (Maximum Transmission Unit) BLE составляет 23 байта, из которых полезных — только 20. Для передачи 10 КБ данных это означает 500 пакетов. Если запросить увеличенный MTU (например, 512), количество пакетов сокращается до ~20 — экономия времени до 90%. Вот как это делается на каждой платформе:

На практике большинство BLE-чипов поддерживают MTU 247–512 байт. При передаче прошивки или больших конфигураций это критично.

Как подписаться на уведомления BLE и не пропустить данные?

Подписка на уведомления — стандартный способ получать данные от BLE-устройства в реальном времени. На iOS достаточно вызвать setNotifyValue(true, for:). Но на Android процесс сложнее: нужно не только включить уведомления локально, но и явно записать в дескриптор CCCD (Client Characteristic Configuration Descriptor) значение ENABLE_NOTIFICATION_VALUE. Многие разработчики пропускают этот шаг — и уведомления не приходят.

iOS: Notify-подписка и парсинг

// Включаем notify peripheral.setNotifyValue(true, for: characteristic) // Получаем данные func peripheral(_ peripheral: CBPeripheral, didUpdateValueFor characteristic: CBCharacteristic, error: Error?) { guard error == nil, let data = characteristic.value else { return } // Пример: датчик отправляет 3 байта [flags, heartRate, energyExpended] guard data.count >= 2 else { return } let flags = data[0] let heartRate: Int if flags & 0x01 == 0 { // heart rate в 1 байте heartRate = Int(data[1]) } else { // heart rate в 2 байтах (little-endian) heartRate = Int(data[1]) | (Int(data[2]) << 8) } } 

Работа с бинарными данными через Data + байтовые смещения. Если устройство нестандартное и документация скудная — Wireshark + BLE sniffer помогают разобрать протокол.

Android: Notify + CCCD дескриптор

Подписка на notify требует двух шагов: включить notify локально и записать в CCCD на устройстве:

fun enableNotification(gatt: BluetoothGatt, characteristic: BluetoothGattCharacteristic) { // Шаг 1: включаем locally gatt.setCharacteristicNotification(characteristic, true) // Шаг 2: пишем дескриптор на устройство val cccd = characteristic.getDescriptor( UUID.fromString("00002902-0000-1000-8000-00805f9b34fb") ) ?: return if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.TIRAMISU) { gatt.writeDescriptor(cccd, BluetoothGattDescriptor.ENABLE_NOTIFICATION_VALUE) } else { @Suppress("DEPRECATION") cccd.value = BluetoothGattDescriptor.ENABLE_NOTIFICATION_VALUE @Suppress("DEPRECATION") gatt.writeDescriptor(cccd) } } 

Шаг 2 часто пропускают — и уведомления не приходят. Это самая распространённая ошибка при работе с notify.

Почему на Android возникает ошибка status 133 и как её избежать?

Одна критичная деталь Android BLE: нельзя выполнять несколько GATT-операций одновременно. Только одна операция в полёте. Следующую отправляем только после получения callback предыдущей. Нарушение этого правила приводит к ошибке status 133 или потере данных на большинстве Android-устройств.

Решение — очередь:

class BleOperationQueue { private val queue: LinkedList<BleOperation> = LinkedList() private var operationInProgress = false fun enqueue(operation: BleOperation) { queue.add(operation) if (!operationInProgress) { executeNext() } } fun onOperationCompleted() { operationInProgress = false executeNext() } private fun executeNext() { val op = queue.poll() ?: return operationInProgress = true op.execute() } } 

Процесс внедрения BLE-обмена

Внедрение надёжного BLE-обмена мы разбиваем на этапы:

1. Анализ протокола устройства или спецификации GATT-сервисов.
2. Проектирование очереди операций и схемы парсинга данных.
3. Реализация на целевых платформах (iOS/Android) с учётом MTU, подключения, переподключения.
4. Тестирование на реальных устройствах с различными версиями ОС.
5. Интеграция в приложение заказчика и передача документации.

Что входит в работу

В рамках услуги мы предоставляем:

• Анализ и документирование текущего протокола BLE-устройства.
• Исходный код модуля обмена данными на Swift/Kotlin с поддержкой очереди операций и MTU.
• Интеграционное тестирование на 3+ реальных устройствах.
• Краткую документацию по API модуля.
• Консультации в течение месяца после сдачи.

Мы гарантируем стабильную работу подписки на уведомления, корректную запись команд и обработку ошибок на обеих платформах. Свяжитесь с нами для предварительной оценки вашего проекта. Получите консультацию наших инженеров, если вы ищете готовое решение для интеграции BLE-устройства или столкнулись с ошибками обмена данными.

Сроки и стоимость

Срок реализации под ключ — от 3 до 10 дней в зависимости от сложности бинарного протокола и количества платформ. Стоимость рассчитывается индивидуально после анализа требований.