CH582M (СH581, CH582, СH583)

[nikolz]

вот SDK
texas instruments에서 만든 BOOSTXL-AOA, комплект для разработки CC2652R1, LPSTK-CC1352R 들을 사용하여 ble 5.1에 추가된 기술인 угол входа 기술을 구현하였습니다.

GitHub - riversnails/ti-aoa: ble aoa with ti booster pack

ble aoa with ti booster pack. Contribute to riversnails/ti-aoa development by creating an account on GitHub.

github.com

 

[nikolz]

это от Telink

http://wiki.telink-semi.cn/doc/an/AN_19052700-E_Telink%20Position%20Solution%20Introduction.pdf

 

[nikolz]

5.2.1 Demo Parameter Variable parameters in drivers/8258/aoa.h:
5.3.1 Как использовать
Шаг 1: загрузите указанный файл bin на чип. Затем подключите плату к
компьютеру с помощью USB или SWS для включения питания и обмена данными. Подключите polygon board
к компьютеру через SWS, особенно при тестировании SOA с помощью polygon board, поскольку
на плате нет USB.
Шаг 2: откройте Tscript.exe , дважды щелкните RF_AutoTest_Kite\AoA.lua следующим образом.
Затем интерфейс показан как показано на рисунке 4-0-2 ниже. Выберите AoA_Sniffer_draw_by
_sws_V1.4.lua или AoA_Sniffer_draw_by_usb_V1.4.lua в зависимости от другого
режима подключения между компьютером и платой.

 

[pvvx]

Замечу, что эти чипы CH582M единственные на Али с BLE 5.1,
которые можно купить 50 шт и более по цене менее 1 доллара включая пересылку .

ST17H66 по 60 шт до 42 руб за шт.
TSSOP16, 64KB SRAM, BLE 5.2 feature, Compliant to Bluetooth 5.2
PDF и SDK есть. Аналог PHY6252, но там SSOP24.

 

[pvvx]

@pecherskih Пришли макетки с CH582M. Что на них возможно попробовать?
Или с сентября у вас ничего не сдвинулось?

 

[pvvx]

За годы у WCH ничего не поменялось, кроме букв на чипе....
Как жрали их чипы от неподключенных ножек так и жрут с модуляцией от наводок в 50Гц или какой сигнал подведен...
До платы не дотронуться и руку не поднести - сразу 50Гц на несколько мА по питанию (можно и десятки выжать)...
Для замера пришлось нажимать кнопку RST пластиковой палочкой

Пример из SDK "Broadcaster"

шкалы - мА/мс, питание 3.3В
Пуск от RST (0 мс на графике), потом через 3000+ мс опять нажата кнопка RST.
Плата со светодиодиком в питании (он и LDO (в обратку) жрут пару мА):

Пока не разрезал дорожки, чтобы точно всё измерить, т.к. смысла не видно - таким чипом пусть пока китайцы питаются

 

[pvvx]

Легким движением руки:

А когда-то всегда учили подключать неиспользованные выводы чипов к GND или на резистор(ы) к +питания.... Но то были TTL чипы, у которых средний уровень чуть-ли не выжигал чип из-за генерации...

 

[pvvx]

Чудо чип.
Отрезал на плате питание со светодиодом. Больше ничего не контачит с ногами чипа, кроме питания и кнопки RST.
На В7 подал синус 1Гц амплитудой от 0 до 3В p-p. старт на RST, потом отпустил RST:

И такое поведение практически на любом GPIO и любой форме сигнала.
Вот какая ему разница, что творится во время RST на входах или при работе, если это просто вход GPIO?
Там что, "подтяжки" какие навешаны при Reset и ...? Но тогда от чего прием всех помех и наводок?

 

[pecherskih]

@pecherskih Пришли макетки с CH582M. Что на них возможно попробовать?
Или с сентября у вас ничего не сдвинулось?

Добрый день. Сейчас не часто захожу в эту ветку, поэтому пропустил вопрос. На счет CH582M отвечу следующее. Железом я особенно не занимался, возможно к разочарованию pvvx Дело в том, что у меня модуль будет стоять на постоянном питании от аккумулятора и мне не так важно сколько он будет жрать. Я главный упор сделал на изучение стека. Там есть где разойтись. Для меня нужно что бы на WCH исполнялась роль центрального устройства. Что я могу сказать. Софт сырой. В SDK порядка 70 примеров, но в основном это вариации двух/трех (mesh-сеть я не трогал, пишу только о классическом сценарии). Описания на функции нет, есть только хедер, где хоть как то в несколько строк рассказывается что это за функции. Почему сырой софт? Ну вот есть общий запрос характеристик присоединенного блока. Стек его нормально отрабатывает. А если запрашивать наличие характеристик по UUID, стек одни видит, а другие нет. Вот как с этим работать? Я понимаю, что роль центрального устройства сложнее чем периферического, но всё же. WCH в роли периферического устройства я тестировал мало, поэтому косяков особых пока не видел. Мне сильно помогает режим DEBUG, хотя pvvx его хаит, но мне он помогает пройтись по шагам программы. Общее впечатление от стека - сырой, но ваять на нем в принципе возможно. Сразу скажу что переходить на esp32 я не собираюсь, если вдруг кто то захочет посоветовать. Если будут конкретные вопросы - пишите, постараюсь ответить.

 

[pvvx]

А если запрашивать наличие характеристик по UUID, стек одни видит, а другие нет.

Не понятно описали.
Обычно, даже не смотря в SDK к данным чипам, это часто ваша задача обработки, а не SDK.
При соединении вы работает с индексом UUID, а не с UUID. При первом соединении получают всю кросс таблицу UUID в индексы (последовательные номерки). Потом работают по номеркам.
Получение всей таблицы выжирает очень много батарейки у устройства (UUID-s у него может быть сотнями), и если заранее знаете уже индекс, то и работаете сразу по нему. Это самый быстрый и маложрущий вариант - соединение занимает десятку ms (запрос на соединение и сразу чтение по индексу).
"Большие" адаптеры должны запоминать эту таблицу для последующих соединений. И при повторном соединении у устройства опрашивается только специальный UUID в котором указывается есть ли какая замена в таблице устройтсва UUID->индекс.
Но ESP и прочие на это забили... Им пофиг на всё.

 

[pvvx]

Эти запоминания всего и вся у нормальных BLE адаптеров приводят к сложностям когда творите всякие безобразия - меняете у устройства прошивку, а МАС остается старым. OS при следующем соединение часто в ауте от такого и требуется полная перезагрузка OS и/или адаптера BT.

 

[pvvx]

Я главный упор сделал на изучение стека. Там есть где разойтись.

Ничего в BLE стеке нет, чтобы нужно было изучать. Описывается в пару слов.
Стек BLE - это подобие TCP стека. Т.е. собирает передаваемые-принимаемые фрагменты в единый блок до размера MTU. Усё.

 

[pvvx]

Для меня нужно что бы на WCH исполнялась роль центрального устройства. Что я могу сказать. Софт сырой.

Не сырой, а у данных чипов нема памяти и полный вариант на все случаи для пользователя привыкшего к Arduino "невпихуем".
Если смотреть на nRF - там SoftDevice (вставляемая бинарная прошивка для простой работы "Привет мир") составляет сотни килобайт и хорошо жрет RAM.
А у выбранных чипов - 32 кБ RAM всего.

 

[pvvx]

Вообще вся работа с WCH выплескивается в борьбу с "китайщиной".
Прошить чипы нет возможности, не найдя альтернативных путей. Вот так выглядит программа прошивки:

Попробуйте в ней что выбрать
Залезая через "черный ход", копаясь в кусках от неё, можно найти другой exe. Но и там лог вы никогда не увидите - масштабирование строк перекрывает предыдущие
Ну и подобное у WCH повсеместно. Зато китайцы очень рады "отечественному" чипу

 

[pvvx]

С SDK ещё такие ограничения:
1) Требуется MounRiver Studio_Community (построена на Eclipse).
2) Отладчик только WCH

 

[pecherskih]

Не понятно описали.
Обычно, даже не смотря в SDK к данным чипам, это часто ваша задача обработки, а не SDK.
При соединении вы работает с индексом UUID, а не с UUID. При первом соединении получают всю кросс таблицу UUID в индексы (последовательные номерки). Потом работают по номеркам.
Получение всей таблицы выжирает очень много батарейки у устройства (UUID-s у него может быть сотнями), и если заранее знаете уже индекс, то и работаете сразу по нему. Это самый быстрый и маложрущий вариант - соединение занимает десятку ms (запрос на соединение и сразу чтение по индексу).
"Большие" адаптеры должны запоминать эту таблицу для последующих соединений. И при повторном соединении у устройства опрашивается только специальный UUID в котором указывается есть ли какая замена в таблице устройтсва UUID->индекс.
Но ESP и прочие на это забили... Им пофиг на всё.

Добрый вечер. Попробую ответить на вопросы. Вы пишете - "При соединении вы работает с индексом UUID, а не с UUID" и далее
"и если заранее знаете уже индекс, то и работаете сразу по нему". Совершенно верно, здесь у нас нет разногласий. Далее
вы пишете - "И при повторном соединении у устройства опрашивается только специальный UUID в котором указывается есть ли какая
замена в таблице устройтсва UUID->индекс" И здесь я полностью согласен. Но как раз здесь и возникла проблема. При вычитывании
всей таблицы я получаю один сервис с двумя характеристиками. Это у меня такой тестовый вариант периферийного устройства. А вот
когда я запрашиваю индекс конкретной характеристики для обращения к ней, то один индекс я получаю (характеристики чтения),
а другой (характеристики записи) не получаю. Хотя ранее в общем запросе он был. И если к нему обратиться, то запись в характеристику
происходит. Поэтому я и пишу что стек сырой. Есть ещё наблюдение. Когда я осваивал модем SIM868M с блютусом, там был баг. Дескриптор
0х2902 (СССD) работал только в сервисе, загружаемым первым. На втором не работал и мне приходилось грузить сначала второй, затем первый.
Там сервис передачи данных запускался только после успешной отработки сервиса авторизации. Не буду вдаваться в детали как там было,
главное у WCH похожая ситуация. Если у первого сервиса есть характеристика с CCCD дескриптором, то я могу подписаться на нотификацию.
Если же CCCD дескриптор есть у характеристики второго сервиса, то стек не отдает его индекс и вообще его не видит. А сл-но и нотификации
нет. На счет изучения стека - не согласен. Научиться корректно работать с командами не просто. А вот MounRiver Studio меня не парит.
Работает и ладно. Надеюсь на все вопросы я ответил. Я конечно не считаю себя асом, поэтому может чего и не понимаю пока. Разбираюсь дальше,
если что то накопаю - сообщу

 

[pvvx]

TEST
Broadcaster - только BLE реклама, без возможности подключения и ответа на сканирование. Т.е. не включает приемник после пакета передачи. Типа 'Маяк' с интервалом 3 сек - это самый предел для успешного приема маяка при самом малом потреблении и требований от чипа.

В примере из SDK изменено: HAL_SLEEP=1, DEBUG - отключен, #define DEFAULT_ADVERTISING_INTERVAL 4800 (3 сек), DC-DC включен, светодиод на PB4 отключен.

Итоговые замеры экземпляра чипа CH582M на плате YD-CH58x:

DC-DC включен.
Режим sleep - 2.7мкА (3 сек)
Активность - чуть менее 3 мс
Пробуждающий импульс включения в режим активности более 6 мА (с емкостным спадом ~0,4 мс)
Потребление после включения - 1.2 мА (~1 мс)
Передача - три пакета при 6..7.5 мА (~1.1 мс, 0дБ)
Среднее потребление от 3.3В при интервале рекламы 3 сек - 6.75 мкА

Каждые 120 сек наблюдается пробуждение для выполнения каких-то ритуальных танцев из либы SDK.

PS: На TSLR825x при аналогичных параметрах (3 сек, 0дБ) средний ток составляет менее 5 мкА, sleep - менее 1.8 мкА (постоянно активны 32 кБ RAM), максимальный пик во время передачи порядка 7 мА. При этом длина пакета данных при тесте у TSLR825x больше.

 

[pvvx]

Там сервис передачи данных запускался только после успешной отработки сервиса авторизации.

Многие BLE при соединении имеют разный набор UUID, в зависимости от авторизации (bind, пин-код). В другом варианте - у устройства разные атрибуты к UUID - некоторые с флагами требования авторизации...
Т.е. если в устройстве ввели pin код, то он защищает некоторые сервисы, а не все. Остаются доступные для информации всем.
Может это тот случай?

 

[pvvx]

При вычитывании всей таблицы я получаю один сервис с двумя характеристиками. Это у меня такой тестовый вариант периферийного устройства. А вот
когда я запрашиваю индекс конкретной характеристики для обращения к ней, то один индекс я получаю (характеристики чтения),
а другой (характеристики записи) не получаю. Хотя ранее в общем запросе он был. И если к нему обратиться, то запись в характеристику
происходит. Поэтому я и пишу что стек сырой.

А у этих двух характеристик одинаковый UUID?
В общий список такое вывалит и-то неизвестно на всех-ли реализациях, не закончится ли такое просто "ошибка" считывания характеристик?
По отдельному запросу найдет первую, т.к. оно единственное верное и должно было иметь ATT_PERMISSIONS_RDWR

 

[pecherskih]

А у этих двух характеристик одинаковый UUID?
В общий список такое вывалит и-то неизвестно на всех-ли реализациях, не закончится ли такое просто "ошибка" считывания характеристик?
По отдельному запросу найдет первую, т.к. оно единственное верное и должно было иметь ATT_PERMISSIONS_RDWR

У характеристик записи и чтения различный UUID. Если интересно, я приведу лог прошивки с комментариями.
В программе в ключевых точках стоит PrintF, а я дополнительно снабдил сообщения цифрами в начале сообщения.
Что бы лучше логику отслеживать. Вот что у меня получилось.
1 - старт считывания всех сервисов присоединенного устройства 2 - приложение получает от стека несколько
сообщений с диапазоном адресов сервисов в памяти стека 3 - запрос всех характеристик 4 - получаю из стека
указатели на эти характеристики. Тут надо пояснить, что на периферийном устройстве запущен только первый сервис
авторизации, второй сервис передачи данных пока пассивен. Здесь мы видим две характеристики с указателями 110 и 112.
Это как раз характеристики чтения и записи сервиса авторизации 10f ~ 11d. 5 - запрос к характеристике сервиса авторизации
для чтения кодового слова с периферического устройства 6 - его получение. Затем я обрабатываю случайное входящее число
при помощи секретного ключа и 7 - отправляю полученный результат обратно. После этого, если периферийное устройство
видит что ответ совпал с ожидаемым, оно поднимает второй сервис - сервис передачи данных. Я же хочу удостовериться, что
он поднят. Для этого 8 - заново делаю запрос всех сервисов на устройстве. И вижу что появился новый с диапазоном
100 ~ 10e. И вот далее самое интересное.

1 Start Discovery My
2 Found Profile Service handle : 1 ~ 5
2 Found Profile Service handle : 6 ~ 8
2 Found Profile Service handle : 10f ~ 11d
2 Found Profile Service handle : 206f ~ 500
3 Find all characteristics
4 Found Characteristic handle : 2
4 Found Characteristic handle : 110
4 Found Characteristic handle : 112
4 Found Characteristic handle : 206f
5 Read Data Characteristic
6 Read code : d1d20950
Param Update...
7 Write code : 581f66f9
8 Start Discovery New !!!!!
9 Found Profile Service handle : 1 ~ 5
9 Found Profile Service handle : 6 ~ 8
9 Found Profile Service handle : 100 ~ 10e
9 Found Profile Service handle : 10f ~ 11d
9 Found Profile Service handle : 206f ~ 500

Если я 10 - запускаю заново считывание всех характеристик, то я не вижу ничего нового.

10 Find All Characteristic
11 Found Characteristic handle : 2
11 Found Characteristic handle : 110
11 Found Characteristic handle : 112
11 Found Characteristic handle : 206f

Если я 10 - запускаю команду поиска в стеке характеристики (DT_Char) по её UUID (128 bit), то
стек отдает мне ссылку на эту характеристику (102) и я могу 12 - запросить данные с блока
и 13 - получаю их

10 Find Characteristic DT_Char
11 Found Characteristic handle : 102
12 Read Data Characteristic
13 Data = 79000000FF00000000FE83100E00

Бывает и наоборот. В общем запросе указатель на характеристику имеется, а при запросе
её по UUID стек её не находит. К логу есть ещё некоторые комментарии. Сервисы 1 ~ 5 и
6 ~ 8 - это стандартные сервисы BLE. Характеристика с точкой входа 2 - это характеристика
Имени устройства. Но вот что такое сервис диапазона 206f ~ 500 и характеристика 206f
мне не понятно. Но вроде бы они никак не мишают. В NRFConnect их не видно. Вот с этими
проблемами я столкнулся. В принципе их можно обойти, но осадочек остается.