• Система автоматизации с открытым исходным кодом на базе 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 имеются только заглушки с комментарием типа этого нет.
Интересно что на самом деле - просто тупо не странслировали в либу или баги в чипах?
 
Войдите или зарегистрируйтесь для ответа.
Сверху Снизу