• Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram

TLSR8251 + LCD + термометр = LYWSD03MMC XIAOMI Bluetooth термометр

pvvx

Активный участник сообщества
Каждый кулик хвалит свое болото...
Вам удалось исправить драйвера BLE в ESP32?
А то из десятка разнообразных модулей BLE у него самое большое кол-во потерь-пропусков при приеме рекламных пакетов. А это самый востребованный метод приема с датчиков BLE, т.е. главная функция для IOT.
 

miks69

Member
Вам удалось исправить драйвера BLE в ESP32?
А то из десятка разнообразных модулей BLE у него самое большое кол-во потерь-пропусков при приеме рекламных пакетов. А это самый востребованный метод приема с датчиков BLE, т.е. главная функция для IOT.
BLE-библитотека ядра ESP32 очень тяжелая, поэтому я пользуюсь другой, аналогичной и полностью совместимой, но она существенно полегче, и, судя по всему, работает стабильнее - NimBLE-Arduino.
Что касается потерь-пропусков при приеме рекламных пакетов, то на мой взгляд данный метод изначально проигрышный, т.к. либо вы постоянно слушаете эфир чтобы ничего не пропустить, либо сканируете эфир периодически, чтобы успевать еще что-то делать в перерывах, но тогда заведомо пропускаете часть пакетов. Поэтому для меня предпочтительнее метод соединения и подписки на уведомления, при котором я ничего не теряю, и которые не прерывают работу основного алгоритма работы устройства на время сканирования эфира в ожидании рекламных пакетов. Так что насчет востребованности данного метода тут еще бабушка надвое сказала...
 

pvvx

Активный участник сообщества
BLE-библитотека ядра ESP32 очень тяжелая, поэтому я пользуюсь другой, аналогичной и полностью совместимой, но она существенно полегче, и, судя по всему, работает стабильнее - NimBLE-Arduino.
Что касается потерь-пропусков при приеме рекламных пакетов, то на мой взгляд данный метод изначально проигрышный, т.к. либо вы постоянно слушаете эфир чтобы ничего не пропустить, либо сканируете эфир периодически, чтобы успевать еще что-то делать в перерывах, но тогда заведомо пропускаете часть пакетов.
Вы опять чего-то напутали. Видимо пристрастие к Ардуино дает себя знать.
Каким фигом АЛУ принимает радиоволны, детектирует и декодирует модуляцию?
Вашей библиотекой от Ардуино? Ногодрыгом? :)
Вооще-то, в любом нормальном чипе сам процессор не занят приемом, а получает пакеты по прерыванию и DMA. CPU остается только перекинуть блок в пользовательский код. Даже при использовании кривой и тормозной (Ардуино-RTOS) ресурсов на это требуется не более самого тупого Cortex на 5-8 МГц.

Поэтому для меня предпочтительнее метод соединения и подписки на уведомления, при котором я ничего не теряю, и которые не прерывают работу основного алгоритма работы устройства на время сканирования эфира в ожидании рекламных пакетов. Так что насчет востребованности данного метода тут еще бабушка надвое сказала...
Ваша бабушка не в состоянии принять данные от сотен датчиков...
У неё Ардуино головного мозга... :)
 

miks69

Member
Вы опять чего-то напутали. Видимо пристрастие к Ардуино дает себя знать.
Каким фигом АЛУ принимает радиоволны, детектирует и декодирует модуляцию?
Вашей библиотекой от Ардуино? Ногодрыгом? :)
Вооще-то, в любом нормальном чипе сам процессор не занят приемом, а получает пакеты по прерыванию и DMA. CPU остается только перекинуть блок в пользовательский код. Даже при использовании кривой и тормозной (Ардуино-RTOS) ресурсов на это требуется не более самого тупого Cortex на 5-8 МГц.
Обратите внимание на первую строчку комментария в коде процедуры сканирования:
Код:
/**
* @brief Start scanning and block until scanning has been completed.
* @param [in] duration The duration in seconds for which to scan.
* @return The BLEScanResults.
*/
BLEScanResults BLEScan::start(uint32_t duration, bool is_continue) {
    if(start(duration, nullptr, is_continue)) {
        m_semaphoreScanEnd.wait("start");   // Wait for the semaphore to release.
    }
    return m_scanResults;
} // start
 

miks69

Member
Ваша бабушка не в состоянии принять данные от сотен датчиков...
Мне достаточного принять данные от одного датчика но с гарантией и без тупого ожидания следующего рекламного пакета.
При этом ничего не мешает мне сделать подключение к нескольким датчикам и также оформить подписку на нужные уведомления.
 

miks69

Member
Вы опять чего-то напутали. Видимо пристрастие к Ардуино дает себя знать.
Каким фигом АЛУ принимает радиоволны, детектирует и декодирует модуляцию?
Вашей библиотекой от Ардуино? Ногодрыгом? :)
Вооще-то, в любом нормальном чипе сам процессор не занят приемом, а получает пакеты по прерыванию и DMA. CPU остается только перекинуть блок в пользовательский код. Даже при использовании кривой и тормозной (Ардуино-RTOS) ресурсов на это требуется не более самого тупого Cortex на 5-8 МГц.
Если вам удалось реализовать в своем коде прием рекламных пакетов без ожидания, тогда поделитесь примером кода с неразумной Arduino-школотой...
 

miks69

Member
Подробно и популярно о режимах работы BLE, в том числе о передаче рекламных пакетов и режиме присоединения, который по словам автора работает экономичнее - https://habr.com/ru/post/319388/
 

pvvx

Активный участник сообщества
Мне достаточного принять данные от одного датчика но с гарантией и без тупого ожидания следующего рекламного пакета.
При этом ничего не мешает мне сделать подключение к нескольким датчикам и также оформить подписку на нужные уведомления.
Сделайте расчет пары вариантов, в каком варианте будет более уверенный и более стабильный прием с 3..10 датчиков, при условии импульсной помехи (работа WiFi роутера) и удаления датчиков (с низким уровнем сигнала).
А так-же пересчитайте энерго-эффективность.
 

pvvx

Активный участник сообщества
Подробно и популярно о режимах работы BLE, в том числе о передаче рекламных пакетов и режиме присоединения, который по словам автора работает экономичнее - https://habr.com/ru/post/319388/
Это статья прыгающая по верхам и совершенно не информативная. Уровня - тупенькое упрощенное описание для детсада про основы BLE.
Я не собираюсь тут производить ваше обучение - считайте как хотите, мне от этого будет только лучше (рост цены и спроса на нормальные проф. решения, а не ваших ардуинных игрушек :)).
 

pvvx

Активный участник сообщества
Если вам удалось реализовать в своем коде прием рекламных пакетов без ожидания, тогда поделитесь примером кода с неразумной Arduino-школотой...
Рекламные пакеты не требуют никакой системной обработки, сборки в стек, кеширования. Об этом указано даже в вашей "статье в мурзилке".
Приемник принимает фрейм, отрабатывает прерывание по концу DMA перекидывания в RAM или от самого приемника, по прерыванию CPU сравнивает пару байт с маской (может и не сравнивать, если фильтрация пакетов по типам в пользовательской части) и передает адрес блока в пользовательскую часть. Иногда и в зависимости от правильности аппаратной реализации, CPU по концу приема пакета может переназначать канал приема и массив буферов DMA или fifo. На этом всё - система более задействует CPU. Приемник при этом принимает постоянно, без пауз.
А теперь поглядите насколько тяжелой и тупой реализацией вы пользуетесь в коде Ардуино ESP32.
 

miks69

Member
Приемник принимает фрейм, отрабатывает прерывание по концу DMA перекидывания в RAM или от самого приемника, по прерыванию CPU сравнивает пару байт с маской (может и не сравнивать, если фильтрация пакетов по типам в пользовательской части) и передает адрес блока в пользовательскую часть. Иногда и в зависимости от правильности аппаратной реализации, CPU по концу приема пакета может переназначать канал приема и массив буферов DMA или fifo. На этом всё - система более задействует CPU. Приемник при этом принимает постоянно, без пауз.
Не знаю как вам еще объяснить. Чтобы поймать в эфире рекламный пакет вам необходимо периодически выделять время процессора и слушать эфир. Либо заниматься только этим и больше ничем. В случае режима подключения обработка пришедшего уведомления происходит по прерыванию, давая возможность процессору решать другие задачи. Вот и вся разница. Кто знает о чем речь, тот поймет.
 

pvvx

Активный участник сообщества
Не знаю как вам еще объяснить. Чтобы поймать в эфире рекламный пакет вам необходимо периодически выделять время процессора и слушать эфир. Либо заниматься только этим и больше ничем. В случае режима подключения обработка пришедшего уведомления происходит по прерыванию, давая возможность процессору решать другие задачи. Вот и вся разница. Кто знает о чем речь, тот поймет.
Вам сразу с тяжелого пояснять?
Параметры Connect-а: minimum connection interval, maximum connection interval, slave latency, and time-out.
Особое внимание обратите на slave latency. Когда разберетесь, то осознаете, что приемник должен быть готов всегда. Но кроме приемника в BLE должен быть готов и передатчик. И для обоих необходимо подготовить и содержать разные счетчики и два уровня абстракции протокола с декодированием шифрации, масок, анализа перезапросов, передач подтверждений в минимальные фиксированные интервалы и кучу буферов и прочих обновляемых переменных. Это всё ложится на CPU - программный драйвер BLE.
А при приеме рекламы CPU и драйвер обслуживает только прерывание и передачу указателя на принятый фрейм. :p
Обычный сниффер - в реальности, на практике, принимающий значительно более 300 рекламных пакетов в секунду при ничтожной нагрузки на CPU. :p
Но реализация вашего Ардуино-драйвера содержит более 95% никчемных действий, т.к. заточено не на работу, а на обучение начальным понятиям. Т.е. пытается разложить, декодировать, разбить на типы пакетов и последовательности, на какие-то временные окна и создать десятки логов, на что уходит производительность двух ядер с более 200 MГц. И то, в реализации ESP32 не справляется с тупой задачей. И т.к. размер кода этой обработки занимает сотни килобайт (!), то там миллионы ошибок и никакой гибкости - никакой возможности оптимизации, т.к. всё повязано друг на друга. Тем более используется алгоритмы с динамическим распределением RAM, плюс C++, что обязательно когда-нибудь вызовет дефрагментацию и отказ системы, т.к. в ESP32 нет MMU.
Т.е. о надежности разговор вообще не идет.
И это вместо того, что решает любой, хоть 8-ми битный CPU на десятку МГц со статическими буферами и одной страницей кода на СИ без наличия каких либо ошибок и неточностей выполнения!
 

pvvx

Активный участник сообщества
Кстати, спасибо за прошивку, похоже, что она действительно меньше использует батарею в режиме подключения.
Только при определенных условиях. На практике это не более 20% вариантов реального пользовательского (потребления как рабочее устройство) использования и этот процент уменьшается при работе с ESP32 за счет нескольких факторов заложенных в подходе разработки кода и самого чипа ESP32.
 

pvvx

Активный участник сообщества
При увеличении уровня помех (что является реальной обстановкой типового городского жилья) соединение страдает большим кол-вом перезапросов (большее время работы передатчика и ожиданий ответов, что особо выжирает батарейку датчика), не говоря уже о увеличении расстояния между приемником и передатчиком. Это дополнительно уменьшает время чистого эфира, за которое приемник мог бы принять ещё десятки рекламных пакетов.
Тем более нафига датчику обратная связь? Connect существует для одноразовой настройки и не более. Далее датчик передает все необходимые параметры с дублированием для учета реальных условий выбивания пакетов в эфире, а не кривизной ПО в дровах ESP32. Тесты показывают, что при наличии сотни устройств в радиусе до сотни метров и нескольких WiFi роутеров, смарт-телефонов и прочих занимающих эфир, происходит выпадение (по причине помехи от других) до 7% рекламных пакетов BLE. Но это не в случае применения ESP32. Там за счет реализации происходят потери от 20 до 100%, т.к. выпадения приема происходят большими окнами - по несколько минут! Ардуино-писатели, сказать тут более нечего.
 

pvvx

Активный участник сообщества
Для исполнительных оконечных устройств существуют протоколы такие как BLE MESH, а не BLE Connect mode. Рассмотрите временную диаграмму затрат энергии при обычной рекламной посылке... После передачи рекламного фрейма, в очень ограниченном времени, датчик переключается на прием ожидает запроса на дополнительную рекламу или коды соединения. B MESH это аналогично и это и есть обратная связь.
При connect то-же самое, но пауза ожидания подтверждения гораздо больше и больше потребление. Но из-за того, что связь при connet идет на одном канале, а не на 3-х, то компенсирует различия по потреблению. А т.к. временной при connect интервал нормирован, то сбой транзакции (помеха) вызывает откладывание соединения на следующий интервал или перезапросов - зависит от slave latency. В итоге произойдут потери передачи данных с датчика (переполнение, т.к. предыдущие данные не переданы, а надо передать новые). При уменьшении connection interval у вас сильно растет потребление, а увеличение ведет к потерям и сбоям соединения. Начальное согласование соединения и обрыв связи вызывает сверх потребление, т.к. очень энергоемко, а при наличии помех переконнекты неизбежны.
Если задан slave latency на весь интервал, то вы можете произвести только одно соединение. Иначе будет значительное увеличение потребления у датчика (для понятия этого необходимо глубже знать работу BLE, и расписывать почему это происходит Ардуинщикам нет никакого смысла).
 

pvvx

Активный участник сообщества
Не знаю как вам еще объяснить. Чтобы поймать в эфире рекламный пакет вам необходимо периодически выделять время процессора и слушать эфир.
CPU не занимается приемом. CPU однократно заряжает регистры приемника и DMA/fifo. Далее ждет прерывание приема RF фрейма. DMA/отображение FIFO передатчика настраивается на круговую последовательность статических буферов и работает автоматически, вызывая прерывания завершения приема фрейма.
Либо заниматься только этим и больше ничем. В случае режима подключения обработка пришедшего уведомления происходит по прерыванию, давая возможность процессору решать другие задачи. Вот и вся разница. Кто знает о чем речь, тот поймет.
Всё уже понятно, что вы никогда не работали с реальными системными драйверами и прочим ПО. Так сказать начинающий спамер-противоретчик без знаний. :)
 

miks69

Member
Параметры Connect-а: minimum connection interval, maximum connection interval, slave latency, and time-out.
Особое внимание обратите на slave latency. Когда разберетесь, то осознаете, что приемник должен быть готов всегда. Но кроме приемника в BLE должен быть готов и передатчик. И для обоих необходимо подготовить и содержать разные счетчики и два уровня абстракции протокола с декодированием шифрации, масок, анализа перезапросов, передач подтверждений в минимальные фиксированные интервалы и кучу буферов и прочих обновляемых переменных. Это всё ложится на CPU - программный драйвер BLE.
А при приеме рекламы CPU и драйвер обслуживает только прерывание и передачу указателя на принятый фрейм. :p
Обычный сниффер - в реальности, на практике, принимающий значительно более 300 рекламных пакетов в секунду при ничтожной нагрузки на CPU. :p
Но реализация вашего Ардуино-драйвера содержит более 95% никчемных действий, т.к. заточено не на работу, а на обучение начальным понятиям. Т.е. пытается разложить, декодировать, разбить на типы пакетов и последовательности, на какие-то временные окна и создать десятки логов, на что уходит производительность двух ядер с более 200 MГц. И то, в реализации ESP32 не справляется с тупой задачей. И т.к. размер кода этой обработки занимает сотни килобайт (!), то там миллионы ошибок и никакой гибкости - никакой возможности оптимизации, т.к. всё повязано друг на друга. Тем более используется алгоритмы с динамическим распределением RAM, плюс C++, что обязательно когда-нибудь вызовет дефрагментацию и отказ системы, т.к. в ESP32 нет MMU.
Т.е. о надежности разговор вообще не идет.
И это вместо того, что решает любой, хоть 8-ми битный CPU на десятку МГц со статическими буферами и одной страницей кода на СИ без наличия каких либо ошибок и неточностей выполнения!
Много умных и красивых слов, но на данный момент реализовано и работает так, как я описал выше. И никто пока лучшего не предложил...
 
Сверху Снизу