Результаты поиска

@nikolz - Подоспел ответ на ваш вопрос: https://esp8266.ru/forum/threads/tlsr8251-lcd-termometr-lywsd03mmc-xiaomi-bluetooth-termometr.5263/post-99516 Т.е. самый шумным является WiFi. От него коллизий в эфире больше всех остальных, при условии работы WiFi роутера на непересекающемся с другими...

Уже можно подвести некоторые итоги по системе BLETHR "BLE устройство с малой батареей и экраном, производит прием и показ данных внешнего BLE датчика". Условия первого измерения: Дом с 3 жителями (2 подростка). Источники шума в эфире: 3 смартфона, 2 компа, WiFi роутер, 3 постоянно работающих...

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

Для USB2.0 будет дискретность 1 мс (к hub подключено одно устройство). Для WiFi - неопределенно: от 1 мс до секунд. При наличии только 1 клиента у AP, чистейшем радио-эфире, и активном соединении возможны дырки на пару мс на время приема-передачи beacon. Zigbee - сверх зависимость от топологии...

С использованием стандартных средств: 1. При соединении это можно сделать только за счет минимального "интервала соединения". Будет дискретность 7.5 мс 2. При передаче маяка - у меня выходит 3..7 мс от события до декодирования уже на приемной стороне. Время передачи маяка по трем каналам - 3...

NanoPi NEO Plus2, Allwinner H5 с четырьмя ядрами Cortex A53, производит 100000 вызов пустой команды fork() примерно за 53 секунды. Т.е. одна команда fork()в Ubuntu выполняется за 537 мкс. При полном кэшировании ядра в памяти - работает в основном блок MMU – СPU там расставляет битики... vfork()...

А на чем вы делаете проверку? На старых чипах BT4.2 c внутренним буфером на 23 полезных байта для передачи выходит совсем плохо: при минимальном интервале в 7.5 мс такие чипы передают подряд, между интервалом, всего 4 пакета. Так и выходит, что трафик с подтверждением на них чуть больше или...

Это и есть случай, когда данные уже подготовлены и CPU занимается только переключением DMA на новый готовый блок и вообще не задействует XIP (кэш SPI-Flash)... А в случае, когда вы передаете отдельными пакетами с паузами – это совсем другая ситуация. Для такой задачи CPU необходимо...

Учитывая, что BLE разрабатывался и разрабатывается для простых и маломощных CPU ядер, то в нем очень редко используются числа с плавающей точкой. Только целочисленные мат. операции. Иначе CPU не имеющие FPU будут не успевать работать с BLE таймингами. А в Arduino, помимо плавающей точки...

При приеме BLE рекламы (маков), скорость их поступления достигает 3 мс (с учетом приема каждого по 3-м каналам). В итоге необходимо успевать сливать каждый во вне за 3 мс. Сливаемые данные маяка около 40 байт (raw) на маяк, если не переводить в ASCII и не создавать большого заголовка для...

Если считать, что ESP принимает данные от BLE устройства и передает их по MQTT, тогда: Пусть на передачу пакета в 20 байт в среднем по BLE уходит 1 мс. ESP переводит данные пакета в string для MQTT (расширяет в сотню байт в Json) и отправляет. Ответ от сервера по WiFi-TCP при местной связи...

C ESP32-xxx в BLE/Zigbee вообще многое не ясно. К примеру, какие задержки у RF для обслуживания ALC/ ALC2. Для nRF52840 они указаны в PDF: Время между задачей RXEN и событием READY после настройки частоты канала (1 Мбит/с BLE с быстрым нарастанием) - 40 мкс. Время между задачей TXEN и событием...

Но у него производительность RF и ПО в сотни раз больше при в десять раз меньшей тактовой частоте CPU, чем у ПО от "программеров" в ESP-IDF и двух ядер ESP32 на 240 MHz. :) Для полноценного обслуживания BLE в BT5.2 (PHY 2M) сверх достаточно Cortex M0 на 16 МГц с выборкой кода из SPI-Flash на 40...

Это относится только к софт подтверждению - получите специальный фрейм о приеме в какой callback() или стек BLE. Но никак не относится к RF подтверждению приема.

И вы видели кучу процедур разбора принятых блоков в ESP-IDF. Пока они отработают в ESP, устройство уже десятки раз передаст повторно этот блок, т.к. RF подтверждения приемо-передачи не было. И так на каждый блок, в итоге каждый блок устройство дублируется более 50 раз. Это как разговор с глухим...

На данной картинке и показано, что интервал соединения = 20 ms, а "latency" = 124. Т.е., если нет нужды в передачах, то устройство пропускает 125 интервалов (2.5 сек). Но когда происходи запрос устройству на чтение данных (на графике это 5000 ms), то устройство меняет latency на 0 и согласует -...

В этом бардаке участвует и значение MTU и параметр соединения “latency”. "latency" указывает, сколько интервалов соединения может пропустить устройство (не выходить на связь), но мастер всё равно должен включать приемник на каждое окно интервала соединения для приема от устройства... Это...

Время после передачи на опрос, что есть ещё данные в BLE - пара сотня мкс. Т.е. они должны быть уже в очереди передачи до конца передачи предыдущего блока. А ESP тормоз и не успевает производить анализ ответа-подтверждений мастера после передачи блока и подсунуть новый блок в эту сотню мкс...

Передача данных при BLE соединении аналогична USB. Примерно так (упрощенно): В USB мастер опрашивает устройство с фиксированным интервалом (USB2.0 - 1 ms). Если у устройства есть данные, то передается первый блок данных. Но, по концу приема блока мастер опять опрашивает устройство на доп...

> Спасибо за ответы, только не удается открыть изображения . Дублирую... (видимо копирование своих картинок с github как-то не так проходит): Пример считывания 50 измерений из истории термометра. 50 измерений передаются в ESP32 за 12 секунд (график тока от батареи в мА и msна стороне BLE...