Организация обмена данными с 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 дней в зависимости от сложности бинарного протокола и количества платформ. Стоимость рассчитывается индивидуально после анализа требований.