Comments 7
Интересно было бы почитать о протоколах передачи данных — об ограничениях размера блока, записываемого в характеристику и что делать, если нужно передать данные, не влезающие в ограничения размера пакета. Как делить на «пролезающие» куски, как контролировать целостность, как потом собирать, в каком виде передавать данные.
В нашем случае ограничения описаны в API, в рамках которого мы работаем, поэтому делить данные на куски не приходится. Интересно было бы самому столкнуться с такой задачей на практике.
> об ограничениях размера блока, записываемого в характеристику и что делать, если нужно передать данные
Максимальный размер одного пакета ATT(Atribute protocol) для LE 23 байта (Vol3 Part G: 5.2.1). Считать характеристику можно за один пакет размером ATT_MTU-1. Записать размером ATT_MTU-3 (Vol3 Part F: 3.2.9). Есть возможность читать большую характеристику за но не больше 512 байт и bt стек спрячет все особенности этого. Есть возможность писать длинные характеристики, но за частую бт стек на стороне микроконтроллеров это не прячет (на стороне iOS не знаю). Длинная запись делается через «prepare write».
> Как делить на «пролезающие» куски
Самый простой вариант делить по ATT_MTU-3
> как контролировать целостность, как потом собирать, в каком виде передавать данные
ATT базируется на L2CAP. L2CAP гарантирует целостность и порядок(Vol3 Part A: 1.1.1), но на Anrdoid первый и последний пакеты могут потеряться.
Если надо передавать что-то большое то рекомендуют использовать L2CAP channel. API для L2CAP — стрим с контролем целостности и порядка но без формата.
Максимальный размер одного пакета ATT(Atribute protocol) для LE 23 байта (Vol3 Part G: 5.2.1). Считать характеристику можно за один пакет размером ATT_MTU-1. Записать размером ATT_MTU-3 (Vol3 Part F: 3.2.9). Есть возможность читать большую характеристику за но не больше 512 байт и bt стек спрячет все особенности этого. Есть возможность писать длинные характеристики, но за частую бт стек на стороне микроконтроллеров это не прячет (на стороне iOS не знаю). Длинная запись делается через «prepare write».
> Как делить на «пролезающие» куски
Самый простой вариант делить по ATT_MTU-3
> как контролировать целостность, как потом собирать, в каком виде передавать данные
ATT базируется на L2CAP. L2CAP гарантирует целостность и порядок(Vol3 Part A: 1.1.1), но на Anrdoid первый и последний пакеты могут потеряться.
Если надо передавать что-то большое то рекомендуют использовать L2CAP channel. API для L2CAP — стрим с контролем целостности и порядка но без формата.
Спасибо. Довольно детально. У нас были проблемы, когда нужно некий девайс подключить к Wi-Fi — девайс подключен, как периферия и возвращает список видимых им сетей. Поскольку большого опыта работы с BT нет решили заворачивать данные в JSON в формате, вроде:
И если этих сетей много, то данные просто обрезаются.
{
«resp»:«OK»,
«ssids»:[
{
«ssid»:«HP-Setup>4b-M277 LaserJet»,
«rssi»:"-62",
«security»:«Open»
}
…
]
}
И если этих сетей много, то данные просто обрезаются.
Мы в похожем случае делали workaround но на девайсе:
1. На девайсе есть характеристика CMD в которую можно писать
2. На девайсе есть характеристика RSP с notify property
3. На запись команды в CMD девайс отвечает нотификейшенами по до 20 байт. В этом случае в приложении эти пакеты необходимо склеивать, но размер ответа не ограничен.
В целом для такого советуют использовать L2CAP channel, но с этим существуют проблемы: не на всех SDK API доступно, в iOS поддержка появилась не так давно, в Android с этим бывают удивительные проблемы.
1. На девайсе есть характеристика CMD в которую можно писать
2. На девайсе есть характеристика RSP с notify property
3. На запись команды в CMD девайс отвечает нотификейшенами по до 20 байт. В этом случае в приложении эти пакеты необходимо склеивать, но размер ответа не ограничен.
В целом для такого советуют использовать L2CAP channel, но с этим существуют проблемы: не на всех SDK API доступно, в iOS поддержка появилась не так давно, в Android с этим бывают удивительные проблемы.
Ну да — мы тоже конвертим JSON в строку штатными средствами, делим на куски по 20 байт и собираем потом. Делаем прям топорно — последний пакет содержит в себе условно-уникальный End of Message «символ», чтобы понять, что данные закончились. Собираемся навернуть поверх какой-никакой контроль целостности (хотябы CRC). С удивлением обнаружили, что готового решения для iOS/Android/Embedded нет — нужно свой велосипед городить.
Вот и мне пригодилась статья, спасибо, подключился в elm327 ble адаптеру.
Sign up to leave a comment.
CoreBluetooth на практике