• Уважаемые посетители сайта esp8266.ru!
    Мы отказались от размещения рекламы на страницах форума для большего комфорта пользователей.
    Вы можете оказать посильную поддержку администрации форума. Данные средства пойдут на оплату услуг облачных провайдеров для сайта esp8266.ru
  • Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram

BLE SoC PHY6202

pvvx

pvvx

Активный участник сообщества
cool2000 написал(а):
Длина передаваемых данных в примере 1200 байт. Реально передаются только первые 245 байт
Нажмите для раскрытия...
Должна быть какая-то передача блоками. В таких рекламах есть номер канала (не RF) и другие идентификаторы. Может передаваться последовательно кусками...
И вариантов передачи несколько - простая расширенная, периодическая, PAwR. Не все ещё имеют закрепившееся популярное название...
Тут надо уточнять в спецификации Bluetooth SIG
К примеру в старом варианте SDK Telink есть какой-то непонятный доп. флаг, похожий на подтверждение приема. Но в спецификации для расширенной рекламы его нет.
По этому не до конца понятны реальные реализации....
 
pvvx

pvvx

Активный участник сообщества
И не известно - nRFConnect умеет принимать все варианты extended advertising?
 
C

cool2000

Member
В текущей реализации получается, что весь буфер передаётся (по частям), только если выставлен флаг PERIODIC.
В противном случае после передачи первой части в 245 байт на дополнительном канале (3) указатель на следующую часть принудительно сбрасывается в 0 и выполняется переход на канал 37. Т. е. фактически в таком режиме максимальный размер блока равняется 245 байт.
Опять же непонятно, как назначается этот дополнительный канал. У китайцев phy он просто выбран от балды.
Запросы на сканирование и соединение (приём) ожидаются только после первой передачи на дополнительном канале.
 
pvvx

pvvx

Активный участник сообщества
cool2000 написал(а):
В текущей реализации получается, что весь буфер передаётся (по частям), только если выставлен флаг PERIODIC.
Нажмите для раскрытия...
С этим не разбирался, т.к. пока никто не принимает периодическую рекламу.
Но в приемниках есть поля номеров принятых блоков и данные поступают кусками... Это тупо передаю в своих сканерах на внешний интерфейс.
В противном случае после передачи первой части в 245 байт на дополнительном канале (3) указатель на следующую часть принудительно сбрасывается в 0 и выполняется переход на канал 37. Т. е. фактически в таком режиме максимальный размер блока равняется 245 байт.
Нажмите для раскрытия...
У Silabs вообще ограничение в 254 байта

и Periodic Advertisement Example

Опять же непонятно, как назначается этот дополнительный канал. У китайцев phy он просто выбран от балды.
Запросы на сканирование и соединение (приём) ожидаются только после первой передачи на дополнительном канале.
Нажмите для раскрытия...
У других тоже не задается RF канал. У Telink есть отладочная функция для принудительного задания RF канала, с указанием что это debug.
 
pvvx

pvvx

Активный участник сообщества
Я не изучал оф. спецификацию, т.к. ограничения в приемниках.
Перебирал разные варианты и смотрел, какие будут приниматься в Linux в Bluez и в далее в интеграции BTHome у Home Assistant , после хака переключения адаптера на прием LR и т.д.
То есть всё упирается не в оф. документацию, а текущую реализацию на приемной стороне.
Тоже самое и с простой BLE рекламой BT4.2. Linux и её не поддерживает по полной.
Все настройки интервалов и макс. размеров приходится выбирать такими, какие как поддерживает убогий Linux.
У Aplle есть свой док с "рекомендации".
 
C

cool2000

Member
pvvx написал(а):
С этим не разбирался, т.к. пока никто не принимает периодическую рекламу.
Но в приемниках есть поля номеров принятых блоков и данные поступают кусками...
Нажмите для раскрытия...
У phy сделано аналогично.
pvvx написал(а):
У Silabs вообще ограничение в 254 байта
Нажмите для раскрытия...
Здесь тоже самое, максимальный размер передачи 255 байт, но 11 байт отъедают байт флагов и дополнительные поля. Остаётся 245 для данных в первом пакете расширенной рекламы.
pvvx написал(а):
У других тоже не задается RF канал. У Telink есть отладочная функция для принудительного задания RF канала, с указанием что это debug.
Нажмите для раскрытия...
Можем добавить такой вызов.

Ещё нашёл, что пауза после передачи на 39 канале жестко задана в rom в 2000мкс (Функция ll_allocAuxAdvTimeSlot()). У вас на осциллограмме Telink она явно меньше, порядка 330мкс.
pvvx написал(а):
То есть всё упирается не в оф. документацию, а текущую реализацию на приемной стороне.
Нажмите для раскрытия...
Хотелось бы докрутить хотя бы peripheral до рабочего состояния coded phy.
И это всё пока в режиме без сна. Там ещё надо будет отдельно разбираться.
Планировщик у китайцев написан ужасно. Изначальный код им явно кто-то другой написал или купили(позаимствовали) готовый. В дальше уже начались беспорядочные правки.
 
pvvx

pvvx

Активный участник сообщества
С периодической рекламой есть несколько проблем – приемный адаптер будет загружен её приемом и не сможет принимать другие, если в нем качественно не распределено время работы RF на все события. Но и если распределено, то пропуски приема других реклам всё равно будут. По этой причине использование периодической рекламы ограничено и не желательно для использования в системе сбора данных с датчиков. Но может применяться как интерфейс между устройствами. И то его полностью вытесняет PAwR. В итоге периодическая реклама не нужна.
 
pvvx

pvvx

Активный участник сообщества
cool2000 написал(а):
К тому же Periodic у phy явно нерабочий. В коде вызывается llSetupAuxChainIndPDU(pExtAdvInfo, 0); // pExtPrdInfo = 0 А внутри функции llSetupAuxChainIndPDU1() без всяких проверок обращаются к указателю pExtPrdInfo.
Нажмите для раскрытия...
Получается, что лучше не копать китайский код, а написать сразу своё.
Нужно создать блок передачи с форматом рекламы имеющей 50% констант и запустить tx2rx() по таймеру на 3 канала. Потом, с интервалом, блок ext.adv и опять tx2rx().
Уже давно хочу так написать на всех чипах, которые использую. В Telink и WCH функции tx2rx() расписаны.
Стек BLE нужен только для соединения.
 
C

cool2000

Member
В итоге я выяснил, почему не работала программа на gcc при переключении на coded phy. Недосмотрел в phy62x2.ld и __gnu_thumb1_case_uqi (case helper) линкер поместил в xip, из-за чего только вызов нужного обработчика из LL_IRQHandler занимал порядка 50мкс (~2500 тактов CPU).

Но планировщик надо в любом случае переделывать.
 
pvvx

pvvx

Активный участник сообщества
Для интеграции в общую сеть умного дома лучше варианта не придумать. От WiFi отказываются все, кто пытается сделать действительно какую-то автоматизацию в доме, а не играют с одним датчиком.
Как-бы жду коммерческого исполнения от других, чтобы сравнить и вдрух какую новую идею подкинут... Тогда можно будет причесать исходники и выкинуть.
 
C

cool2000

Member
Переделал планировщик. Нужно ещё немного почистить (отстаёт на 20мкс за цикл) и доделать соединение.
Нужно ли цикл расширенной рекламы запускать со случайным смещением advDelay?
У китайцев это сделано только для варианта legacy.

1711144370932.png
The advDelay is a (pseudo-)random value with a range 0 ms to 10 ms generated by the Link Layer for each advertising event.
 
pvvx

pvvx

Активный участник сообщества
WCH
C: 
// Set advertising interval
        GAP_SetParamValue(TGAP_DISC_ADV_INT_MIN, advInt);
        GAP_SetParamValue(TGAP_DISC_ADV_INT_MAX, advInt);
Telink
C: 
// ext. adv
            blc_ll_setExtAdvParam(ADV_HANDLE0,
                    ADV_EVT_PROP_LEGACY_CONNECTABLE_SCANNABLE_UNDIRECTED,
                    CONNECTABLE_ADV_INERVAL, CONNECTABLE_ADV_INERVAL + ADV_DELAY, // min/max advertising interval
                    BLT_ENABLE_ADV_ALL, // primary advertising channel map
                    OWN_ADDRESS_PUBLIC, // own address type
                    BLE_ADDR_PUBLIC, // peer address type
                    NULL, // * peer address
                    ADV_FP_NONE, // advertising filter policy
                    ext_adv_tx_level(), // cfg.rf_tx_power -> advertising TX power
                    BLE_PHY_1M, // primary advertising channel PHY type
                    0, // secondary advertising minimum skip number
                    BLE_PHY_1M, // secondary advertising channel PHY type
                    ADV_SID_0,
                    0); // scan response notify enable ?
// bt4.2
        bls_ll_setAdvParam(adv_interval, adv_interval + ADV_DELAY, // min/max advertising interval
            ADV_TYPE_CONNECTABLE_UNDIRECTED, OWN_ADDRESS_PUBLIC, 0, NULL,
            BLT_ENABLE_ADV_ALL, ADV_FP_NONE);
...
 
C

cool2000

Member
Periodic пока не стал трогать, оставил как есть. А вообще его как-то можно проверить?
 
C

cool2000

Member
Уфф, убил кучу времени, пока разобрался как переключить Ext Adv на Legacy. Оказалось, что nRF Connect обязательно выполняет активное сканирование, а оно как раз у китайса не работало.
Теперь надо допроверить соединение на Coded phy.
 
pvvx

pvvx

Активный участник сообщества
А мне тут другое интересно. У WCH объявлено, что
CH592/CH591: BLE complies with Bluetooth Low Energy Specification 5.4 - Support 2Mbps, 1Mbps
CH583/CH582/CH581: BLE complies with Bluetooth Low Energy Specification 5.0 - Support 2Mbps, 1Mbps, 500Kbps and 125Kbps
CH32V208: The series integrates 2Mbps low-power Bluetooth BLE communication module - Low-power Bluetooth BLE5.3
Но, для CH32V208 есть все примеры с любыми PHY и даже PAwR.
Для CH583 нет PAwR.
Для CH592 для Coded PHY в хидерах SDK имеются только заглушки с комментарием типа этого нет.
Интересно что на самом деле - просто тупо не странслировали в либу или баги в чипах?
 
Войдите или зарегистрируйтесь для ответа.
Сверху Снизу