BLE: Чтение длинного значения характеристики с помощью Android/iOS

При нормальном чтении характеристик будет считан только размер MTU (20 байтов) данных. Мой заказчик предложит характеристики большего размера (около 100 байт).

Я видел, что BLE предлагает функцию «долгого чтения», которая считывается до тех пор, пока не будет достигнут размер характеристик. (https://bluegiga.zendesk.com/entries/25053373--REFERENCE-BLE-master-slave-GATT-client-server-and-data-RX-TX-basics)

Команда attclient_read_long — запускает процедуру, в которой клиент сначала отправляет на сервер обычный запрос на чтение, и если сервер возвращает значение атрибута с длиной, равной BLE MTU (22 байта), то клиент продолжает отправлять «длинные» запросы на чтение пока остальная часть атрибута не будет прочитана. Это применимо только в том случае, если вы читаете атрибуты, длина которых превышает 22 байта. Часто проще построить сервер GATT так, чтобы для простоты не было длинных атрибутов. Обратите внимание, что протокол BLE по-прежнему требует, чтобы данные были упакованы в макс. 22-байтовые фрагменты, поэтому использование «длинного чтения» не экономит время передачи.

Но как я могу использовать эту функцию в Android? Класс BluetoothGatt предлагает только простое «Чтение ()» - то же самое для iOS.

Увеличение MTU невозможно, так как нам необходимо поддерживать устройства с AP Level ‹ 21 (увеличение MTU было введено в API 21)


ios android android-bluetooth bluetooth-lowenergy ios-bluetooth
person Michael Probst    schedule 07.07.2016    source источник
comment
По крайней мере, в iOS вам нужно будет выполнять несколько операций чтения, повторяя это до тех пор, пока вы не получите менее 22 байт. Это тот же процесс, описанный BlueGiga; вам просто нужно реализовать это самостоятельно. Я подозреваю, что то же самое может быть верно и для Android   -  person Paulw11    schedule 09.07.2016

Ответы (1)


arrow_upward
1
arrow_downward

Я могу подтвердить для iOS, что сначала будет выполняться операция чтения в соответствии со стандартом. Затем, если сервер возвращает полностью заполненный PDU, устройство iOS продолжит выполнение операции чтения BLOB-объектов. Протестировано с iPhone 7 под управлением iOS 11.2.x.

Вам НЕ нужно вызывать периферию.readValue(characteristic) несколько раз для длинных атрибутов. CoreBluetooth делает все это незаметно.

См. спецификацию Bluetooth Spec Core v5.0, в частности, том 3, часть F. «Длинные значения атрибутов».

Эксперимент, чтобы доказать выше.

У меня есть Android Thing, действующий как сервер, который я заставляю возвращать максимальную длину с моим iPhone во время операции чтения. iOS и мой RPI3 обмениваются MTU, равным 185. Таким образом, ответ чтения имеет длину (MTU - 1) 184 байта. Затем сервер (RPI) получает новый запрос на чтение со смещением 184, по которому вы можете вернуть дополнительные данные. Это продолжается до тех пор, пока смещение не станет > 512, или пока последний ответ чтения не вернет длину, меньшую, чем MTU - 1.

Основываясь на том факте, что BluetoothGattServer поддерживает длинные атрибуты, я полагаю, что и объект BluetoothGatt поддерживает их. Поскольку через API невозможно установить смещение для чтения, я предполагаю, что вы можете вызвать чтение только один раз.

person user2121685    schedule 29.03.2018