CH582M (СH581, CH582, СH583)

[il-2]

В общем я решил - не парить себе и окружающим мозги и сделать нормальную поддержку Client Characteristic Configuration descriptor.
У меня весь обмен от сервера к клиенту планируется делать нотификациями. Пусть клиент включает нотификацию, как положено.

Кстати - раз пошел разговор, то хочу представить на рассмотрение свой вариант (протокол над аттрибутами) обмена данными. Цель моего самопального протокола - работа по принципу "команда-ответ" с наибольшей пропускной способностью и наименьшими задержками.
Стандартные процедуры записи и чтения аттрибутов мне не нравятся тем, что на каждый запрос идет подтверждение, и если ATT_MTU будет маленьким (23 байта), это кардинально уменьшит и без того маленькую пропускную способность. Поэтому я планирую:
- Для выдачи команд использовать WRITE_NO_RESP - выдавать необходимое количество, на сервере их собирать и перезапрашивать если какие-то пакеты не дошли (в пакетах будет присутствовать идентификатор). Для перезапроса (и подтверждения приема всей команды) сервер будет использовать нотификации в спец формате.
- Для выдачи ответов использовать нотификации, поступать с ними так-же как описано выше - собирать на клиенте, перезапрашивать недостающие. Клиент для перезапросов будет использовать WRITE_NO_RESP в спец. формате.
Формат блоков у меня уже проработан. В этой части проблем быть не должно.
Интересует мнение знающих стандарт BLE - получится таким образом выжать бОльшую скорость??? Или может есть какие-то проблемы, которых я не вижу...

 

[pvvx]

Совсем пофиг все описанные извращения. MTU тоже не поможет.
Перезапрашивать при WRITE_NO_RESP тоже ничего не требуется.
И 20 байт тоже не мешают получить нормальную скорость.
Смотрите как работает USB.
Успеваете подготавливать, передавать, обрабатывать пакетики, то они так и попрут передача-подтверждение-передача-подтверждение-... вплоть до следующего "интервала соединения". Если запнулись, то цепочка разорвется до следующего "интервала соединения".
Тут более зависит от адаптера - если он тупой или это Linux, и типа, то значит не тянет - аналог как с USB2.0.

 

[pvvx]

Для этого в нормальных SDK есть программный fifo, который заполняется подготовленными пакетами для отправки. На ходу слабый CPU не успеет формировать пакеты, т.к. время окна приема после передачи пакета что-то около до 500 us до приема синхро... Точнее уточняйте в спецификации BLE - мне пофиг, т.к. использую другой SDK.

 

[pvvx]

Кстати - раз пошел разговор, то хочу представить на рассмотрение свой вариант (протокол над аттрибутами) обмена данными.

Это не будет работать у всех, т.к. у большинства дурные BT адаптеры и устаревшие ОС.
Как в Web bluetooth API вы установите или узнаете MTU?
Только через задний проход - нужно команду устройству по вашему интерфейсу о смене MTU и чтение согласовалось ли оно.
И все эти беды из-за недоразвитости Linux. Особенно Bluez. Они не представляют интерфейса для работы c BT5.0.

 

[pvvx]

В итоге все BT адаптеры, выпущенные за последние 10 лет (особо китайские) очень часто имеют кривое ПО. Т.к. BT5.0 не поддерживается в Linux, то никто их и не отлаживал, и даже тестировать не смог, или написать претензию производителю...
nRF тоже не выпустил BT адаптера (прошивки с HCI).
Одна надежда на Realtek или на адаптеры PCIe от Intel и AMD. В них могут правильно работать спецификации BT5+, но проверить не на чем
USB-BT RTL8761BU имеет загружаемое ПО, BT5.0 реклама с ним работает (и то через з.. путем предварительной подачи хитрых команд адаптеру по HCI), но соединение LE Long Range не работает в Linux. Только в Android.
Удивляет что в Linux как-то работает USB2.0, а то могли бы оставить только USB1.0, по аналогии с поддержкой в Linux Bluetooth.

 

[il-2]

Спасибо, PVVX!!! Однако я пока не буду отказываться от своего намерения. Насколько я понял, основная проблема - в клиенте на ПК, который может не позволить кое-что реализовать.
Первое, что касается MTU и невозможности узнать на ПК-клиенте его размер. Я тестовую прогу пишу под Win10 UWP, там можно узнать MTU. Но в принципе это для меня не так критично. Можно для отправки команд использовать MTU минимального размера. А у меня все команды такие, что поместятся в один минимальный MTU. Ну а ответы - Indication будут какого надо размера. Тут все в моих руках. Эти ответы у меня составляют основной объем данных, который и требуется прокачать побыстрей.
Второе, ... а собственно, что еще? Вроде все. Ну да, еще возможны тормоза приложения на ПК при приеме Indication. Но тут я думаю 99% что драйвер буферизует принятые индикации и выдаст их приложению.
А что касается наворотов BLE5.x, то мне там интересен только PHY 2M. Я кстати еще не интересовался вопросом, как его можно принудительно задействовать и с какой стороны это надо делать. Вроде надо указать его поддержку в FeatureSet, но этого наверное недостаточно.

Еще я с вашей подачи выяснил, что перезапрашивать WRITE_NO_RSP и Indication действительно не надо. На уровне Link-layer есть квитирование, т.е. отправитель DataPDU сам знает, дошел пакет или нет. Все-таки я в стандарт Bluetooth еще не так глубоко занырнул, этот момент пропустил.

 

[pecherskih]

В итоге есть Notification и Indication.
Indication не должен смотреть на включенный флаг Notify.

А вот здесь поподробнее пожалуйста. Насколько я помню - "нотификация не требует подтверждения в получении со стороны клиента. Индикация же этого требует, хотя она и происходит на уровне GATT, не доходя до уровня приложения". Если не затруднит напишите свои мысли поэтому поводу. Может я чего то упускаю.

 

[il-2]

В китайских примерах нарыл еще косячек - в callback-ах чтения значений аттрибутов (функция типа pfnGATTReadAttrCB_t из gattServiceCBs_t) передается параметр offset для чтения длинных значений.
Китайцы в своих примерах выдают ответ ATT_ERR_INVALID_OFFSET(0x07), если offset БОЛЬШЕ ИЛИ РАВНО длинны аттрибута.
В стандарте предписывается немного другое поведение: если offset РАВЕН длинне, то необходимо выдавать ответ нулевой длинны, а не ошибку.
т.е. правильно выдавать ATT_ERR_INVALID_OFFSET(0x07), если offset БОЛЬШЕ ИЛИ РАВНО длинны аттрибута.

 

[pvvx]

А что касается наворотов BLE5.x, то мне там интересен только PHY 2M. Я кстати еще не интересовался вопросом, как его можно принудительно задействовать и с какой стороны это надо делать. Вроде надо указать его поддержку в FeatureSet, но этого наверное недостаточно.

В большинстве случаев переход на PHY 2M или Coded при соединении работает. Тут сказывается то, что ОС в этом не участвует, а это отрабатывает сам адаптер.

 

[pvvx]

Есть первичный и вторичный PHY. Установки вторичного PHY доступны и в Linux.
Первичный - это РНY на котором происходит запрос соединения и заголовки на основных рекламных каналах. Вторичный - это на каком PHY будут будет само тело рекламы или разрешенные PHY для соединения.
Первичный по стандарту может быть только 1M и Coded. Вторичный - любой.
И т.к. первичный в Linux не устанавливают, или если вы сами установили, то на запросе соединения Linux всё равно сбросит PHY на 1M и соединения с LE LR не будет.

 

[pvvx]

А вот здесь поподробнее пожалуйста. Насколько я помню - "нотификация не требует подтверждения в получении со стороны клиента. Индикация же этого требует, хотя она и происходит на уровне GATT, не доходя до уровня приложения". Если не затруднит напишите свои мысли поэтому поводу. Может я чего то упускаю.

Я лейбочки из стандарта не изучал. У меня подход с другой стороны - работает или нет и какие биты для этого нужно установить или какую команду дать.
Если оперировать названиями и сленгом лейбочек, то запутается любой. А обычно это всего 1 бит разницы в каком заголовке...
И сленг на русском для BT ещё не сформирован.

 

[pvvx]

Первое, что касается MTU и невозможности узнать на ПК-клиенте его размер.

Mi-Home даже на Android делает так:
Передает в тестовый UUID c функцией эхо пакет максимального размера. Посланные данные передаются обратно.
Принимает и смотрит какой размер принялся. Так определяет MTU.
Почему делают так, при наличии функции чтения-установки MTU - неизвестно. Наверно не везде эти функции работают.

 

[il-2]

Mi-Home даже на Android делает так:
...

Вы похоже много всяких клиентов перепробовали. Я пока с Виндой только упражняюсь. Не подскажете, как обстоят дела с чтением характеристики по любому произвольному смещению??? В стандарте в описании GATT-профиля четко прописаны процедуры работы с аттрибутами. И согласно этим процедурам можно читать только начиная с нулевого смещения. По мне так это дебилизм. Вот интересно - кто нибудь придерживается строго этого дебильного правила???
Если у меня реализована индикация значения характеристики, то клиенту при получении такой индикации сам бог велел прочитать недостающую часть характеристики, а не всю ее с начала. А вот хрен там - стандарт запрещает.
Я уже думаю над таким вариантом - в индикации выдавать значение характеристики (первые ATT_MTU-1 байт), а при чтении характеристики (с нулевого смещения) выдавать клиенту данные со смещением (т.е. при запросе по нулевому смещению выдавать данные, которые не влезли в ATT_MTU-1 пакет индикации).

 

[pvvx]

Вы похоже много всяких клиентов перепробовали. Я пока с Виндой только упражняюсь. Не подскажете, как обстоят дела с чтением характеристики по любому произвольному смещению???

Не понимаю, зачем читать данные характеристики не полностью?
Это так сложно, прочитать всё и взять нужный байт/бит из нескольких?
Энергию это не сильно сэкономит, т.к. пересылка пакета всё равно с заголовками...

 

[pvvx]

И ещё раз про MTU - У подавляющего большинства пользователей имеются адаптеры с MTU всего 23 байта.
Если длина характеристики больше или послали более MTU в Notify или Indication - приемник обычно ничего не примет. Отбросит пакет как с неверным CRC. У него буфер приема в RF части мал.
Аналогично поступит и нормальный BT5.4 адаптер, если не согласован больший MTU.

 

[pvvx]

(первые ATT_MTU-1 байт)
20

 

[pvvx]

Только попробовал WCH-LinkW - работают нормально. Поискал на али ещё купить, но больше не найти Скупили все?
Хорошо что уже пришла пачка...

 

[cryptozoy]

Только попробовал WCH-LinkW - работают нормально. Поискал на али ещё купить, но больше не найти Скупили все?
Хорошо что уже пришла пачка...

Попробуй в «.com»: https://www.aliexpress.com/item/1005006177751678.html
Только через VPN или Tor, чтобы айпи браузера не был российским, иначе будет редирект в «.ru».

 

[cryptozoy]

В другом варианте тот же отладчик:

https://www.aliexpress.com/item/3256805799910464.html

https://www.aliexpress.com/item/3256805615943226.html

И судя по всему «друзья» китайцы всё же устраивают нам частичные санкции по ряду товаров.

 

[pvvx]

И судя по всему «друзья» китайцы всё же устраивают нам частичные санкции по ряду товаров.

Скорее всего это борьба с Почта-России.