Організація обміну даними з 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-операцій одночасно. Тільки одна операція в польоті. Наступну відправляємо тільки після отримання колбека попередньої. Порушення цього правила призводить до помилки 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 днів залежно від складності бінарного протоколу та кількості платформ. Вартість розраховується індивідуально після аналізу вимог.