ESP-NOW test 2025

[nikolz]

Добрый день, Всем!!!
Написал такой тест.
Две ESP8266 (ESP1 и ESP2) обмениваются сообщениями по протоколу ESP-NOW следующим образом:
ESP1 ждет сообщение от ESP2.
ESP2 посылает широковещательное сообщение номер счетчика.
ESP1 принимает его и возвращает номер счетчика
ESP2 принимает ответ сравнивает с посланным номером и считает ошибки
При первом приеме ответа заменяет широковещательный адрес на адрес ESP1 и далее общается с ESP1
и так в цикле
-------------------------
И вот результат :


T - время обмена одним сообщением с подтверждением в мкс. Т е в среднем менее 1 ms.
В данный момент число сообщений (count) 794 тысячи. ошибок нет.
Сейчас число сообщений составляет более 1 млн. ошибок нет

 

[aZholtikov]

Не пробовали ESP-NOW V2 (ESP32 ESP-IDF v5.4 и выше) с максимальным пакетом 1490 байт?
Версия вышла относительно недавно, руки не доходят посмотреть... ;-)

 

[pvvx]

В данный момент число сообщений (count) 794 тысячи. ошибок нет.
Сейчас число сообщений составляет более 1 млн. ошибок нет

Разнесите устройства хотя-бы на 500 метров.
Тогда, или при других помехах, ESP-NOW должен перейти на другую модуляцию и алгоритмы. И никаких 1 мс не будет.

Ваши тесты двух устройств на одном столе не говорят ни о чем и в практике такое не используется.
Для ближней связи есть другие устройства и там задержки практически нет = время преодоления 1 метра светом туда-сюда
Есть и чипы для меж-платной коммуникации...

 

[pvvx]

Добрый день, Всем!!!
T - время обмена одним сообщением с подтверждением в мкс. Т е в среднем менее 1 ms.

Зачем так обманывать всех?
У вас строка в TerraTerm равна 40 символам UART. Это 40*10/115200=0.00347222 секунды. Т.е. от 3.5 мс только вывод в UART при 115200 Baud.
А где "send to:" - там в три раза больше...
Т.е. вы перепутали счетчик времени - там миллисекунды - millis().

 

[pvvx]

DeepSeek: Какова длительность минимальной транзакции в ESP-NOW?

Длительность минимальной транзакции в **ESP-NOW** зависит от нескольких факторов, включая размер пакета, скорость передачи и условия среды. Вот ключевые аспекты:

### 1. **Скорость передачи данных**
- По умолчанию ESP-NOW использует скорость **1 Мбит/с** (для ESP32 и ESP8266) .
- В идеальных условиях (например, в экранированной среде) скорость может достигать **555 Кбит/с**, а в открытой среде — около **214 Кбит/с** .
- Скорость можно увеличить через API, например, до **2 Мбит/с** с помощью `esp_wifi_config_espnow_rate()` .

### 2. **Размер пакета**
- Минимальный полезный объём данных — **250 байт** (для ESP-NOW v1.0) или до **1532 байт** (для v2.0) .
- Заголовки MAC и служебные данные добавляют **24 байта** (MAC-заголовок) + **7–255 байт** (вендор-специфичные поля) .

### 3. **Расчёт длительности**
Для минимального пакета (например, 28 байт полезной нагрузки + заголовки):
- **При 1 Мбит/с**:
- Общий размер: ~60 байт (28 + 24 + 8 служебных).
- Время передачи: \( \frac{60 \times 8 \text{ бит}}{1 \times 10^6 \text{ бит/с}} = 0.48 \text{ мс} \).
- С учётом служебных задержек (ACK, обработка) общая длительность составит **1–2 мс** .

### 4. **Факторы, влияющие на задержку**
- **Помехи**: В условиях помех (например, через стены) время может увеличиваться из-за повторных передач .
- **Режим работы**: При одновременной работе Wi-Fi и ESP-NOW требуется совпадение каналов, что может добавлять задержки .
- **Шифрование**: Использование AES-CCM (для зашифрованных пакетов) увеличивает время обработки .

### 5. **Примеры из практики**
- В тестах передача структуры данных размером **60 байт** занимала **~1 мс** на расстоянии до 5–6 метров, но при увеличении расстояния до 7 метров возникали потери и задержки .
- Для аудиопотоков (85 КБ/с) задержки могут достигать **10–20 мс** из-за необходимости буферизации .

### Вывод
Минимальная длительность транзакции ESP-NOW в идеальных условиях составляет **около 1–2 мс** для небольших пакетов. Однако реальное время зависит от среды, расстояния и настроек скорости. Для критичных к задержкам приложений рекомендуется тестирование в целевых условиях .

 

[pvvx]

DeepSeek не умеет считать длительность передачи кадра WiFi Делит байты на битовую скорость, забывая про преамбулу и прочие синхросигналы...
Но фиг с ними.
Минимальная длительность кадра 802.11n составляет около 64 микросекунд. Там 20 мкс preamble.
Но ESP-NOW использует другую версию 802.11...

В итоге без всяких тупых ардуино либ можно получить транзакцию (туда-сюда) в 200 мкс. Но не в ESP-NOW.

 

[pvvx]

И не в ESP-IDF. Но тут ещё неизвестно время переключения RF между прем-передача. Для BLE чипов время переключения или включения с выбором канала типично менее 20 мкс (вместе с исполнением кода).
У ESP это наверно много больше... Тут ещё надо добавить время срабатывания АРУ, а у ESP оно ужасно.

 

[pvvx]

Какова длительность передачи минимального пакета BLE при PHY 2M?



Длительность передачи минимального пакета в Bluetooth Low Energy (BLE) при использовании PHY 2M (скорость 2 Мбит/с) зависит от структуры пакета и служебных заголовков. Рассмотрим расчёт по шагам:
1. Структура BLE-пакета (PHY 2M)
Минимальный пакет BLE включает:

• Преамбула (Preamble)– 2 байта (16 бит)
  • Для PHY 2M используется 1-байтная преамбула, но из-за особенностей радиомодуля часто учитывается 2 байта.
• Заголовок доступа (Access Address)– 4 байта (32 бита)
  • Фиксированное значение для соединения (например, 0x8E89BED6).
• PDU (Protocol Data Unit)– минимум 6 байт (2 байта заголовка + 4 байта данных)
  • Заголовок PDU: 2 байта (тип пакета, длина и др.).
  • Полезная нагрузка: минимум 0 байт, но в реальных пакетах (например, LL_EMPTY_PDU) – 4 байта (CRC включается отдельно).
• CRC (Cyclic Redundancy Check) – 3 байта (24 бита).

Итого размер пакета:
2 (Preamble)+4 (AA)+6 (PDU)+3 (CRC)=15 байт=120 бит2 (Preamble)+4 (AA)+6 (PDU)+3 (CRC)=15 байт=120 бит
2. Расчёт длительности передачи
При PHY 2M скорость передачи – 2 Мбит/с (1 бит = 0.5 мкс).
Длительность пакета:
120 бит2×106 бит/с=60 мкс2×106 бит/с120 бит=60 мкс
Но это только время передачи битов!
На практике добавляются:

• Радиозадержки (~50–100 мкс на переключение Tx/Rx).
• Inter-Frame Space (IFS) – 150 мкс (минимальный интервал между пакетами).

3. Реальная длительность транзакции
Для односторонней передачи (без ACK):

• ~60 мкс (передача) + ~100 мкс (радиозадержки) ≈ 160 мкс.

Для двустороннего обмена (например, запрос-ответ):

• Пакет 1: 60 мкс
• IFS: 150 мкс
• Пакет 2: 60 мкс
• Радиозадержки: ~100 мкс
  Итого: ~370 мкс.

4. Сравнение с другими PHY

PHY	Скорость	Длительность мин. пакета
1M	1 Мбит/с	~120 мкс
2M	2 Мбит/с	~60 мкс
Coded	125 Кбит/с	~1200 мкс

PHY 2M сокращает время передачи в 2 раза по сравнению с 1M, но требует более стабильного канала.
5. Ограничения

• Минимальная полезная нагрузка – 0 байт (но в реальных пакетах обычно 4 байта).
• Реальная пропускная способность ниже из-за IFS и служебных заголовков. Например, для пакетов 27 байт:
  Пропускная способность≈27 байт60 мкс+150 мкс≈1.28 Мбит/с.Пропускная способность≈60 мкс+150 мкс27 байт≈1.28 Мбит/с.

Вывод
Длительность передачи минимального BLE-пакета при PHY 2M составляет ~60 мкс (чистое время передачи битов) или ~160–370 мкс с учётом служебных задержек. Это самый быстрый режим BLE, но его устойчивость к помехам ниже, чем у PHY 1M.

---

Т.е. ESP-NOW нафиг не сдался, т.к. тормоз или малая дистанция. И при этом жуткое потребление..

 

[pvvx]

Каково время передачи события от конечного устройства в сети Zigbee с одним роутером?


Время передачи события от конечного устройства до координатора в сети Zigbee с одним роутером зависит от нескольких факторов, включая тип устройства, задержки маршрутизации и параметры сети. Вот основные аспекты:
1. Структура передачи данных
В сети Zigbee с одним роутером путь передачи выглядит так:
Конечное устройство → Роутер → Координатор

• Конечное устройство (например, датчик) обычно находится в спящем режиме и активируется только для отправки данных.
• Роутер (например, умная розетка) ретранслирует данные дальше.
• Координатор (хаб) принимает и обрабатывает информацию.

2. Время передачи
Общее время складывается из:

• Активация конечного устройства (пробуждение из сна): ~15 мс 4.
• Передача данных от устройства к роутеру:
  • Скорость Zigbee (2.4 ГГц): 250 Кбит/с.
  • Минимальный пакет (например, датчика) — около 20 байт (заголовки + полезная нагрузка).
  • Время передачи: ~0.64 мс (20 байт × 8 бит / 250 000 бит/с).
• Обработка и ретрансляция роутером: ~1–5 мс (зависит от загрузки сети).
• Передача от роутера к координатору: аналогично, ~0.64 мс.

Итого:

• Без учета задержек радиоэфира: ~2–10 мс (чистое время передачи).
• С учетом реальных условий (помехи, очередь передачи): 10–100 мс 26.

3. Факторы, влияющие на задержку

• Тип устройства: Датчики с батарейным питанием могут добавлять задержку из-за режима энергосбережения.
• Помехи в эфире: Конкуренция с Wi-Fi/Bluetooth (2.4 ГГц) увеличивает время 7.
• Нагрузка на роутер: Если он обслуживает много устройств, возможны очереди.
• Дальность связи: При слабом сигнале возможны повторные передачи.

4. Пример из практики
Для датчика движения:

• Пробуждение: 15 мс.
• Передача на роутер: 1–5 мс.
• Ретрансляция на хаб: 1–5 мс.
• Общее время: 20–50 мс в идеальных условиях 48.

Вывод
В сети с одним роутером типичное время передачи события — 10–100 мс. Для критичных к задержкам систем (например, аварийных датчиков) рекомендуется минимизировать число роутеров и оптимизировать размещение устройств 36.

---

У альтернативной прошивки BLE время передачи события контакта через стандартный BLE маяк (с учетом времени пробуждения SoC) с приемом на другой модуль по 3-м каналам и коммутации вывода составило 5..7..9 мс. Измерено осциллографом - указан джиттер и основное среднее. Т.е. лампочка включается через 7..20 мс от нажатия кнопки. Тут учитывается питание лампы в 50Гц

 

[pvvx]

Аналогичная коммутация лампочки через HomeAssistant путем приема события по BLE и отправкой в WiFi "умную розетку" (без всяких Cloud) составляет от 120 мс минимально и до более 2.5 секунд.
Большие задержки всегда присущи WiFi, когда там всё занято - идет скачивание Смартом или другие нагрузки...

 

[pvvx]

Опять DeepSeek не учел некоторые нюансы.
Для датчика движения: Пробуждение: 15 мс.

Типовые IR чипы устанавливаемые в Zigbee/BLE/Wifi датчики имеют задержку в 1 секунду от начала появления изменений в приеме для фильтрации от 50Гц. Часто на них есть выводы для переключения этой задержки фильтрации или путем изменения сопротивления. Но добиться менее 50 мс не получается и не получится - будет срабатывать постоянно...
Так же вскользь упомянуто, что в Zigbee существует период опроса (общения с устройством) в 1 qt, равный 1/4 секунды. Меньше незя. А этот интервал уже превышает комфортные нормы времени действие-ответ/реакция для человека (статистическая норма до 250 мс, для Шумахера или игрунчика в комп.игры на порядки меньше ).

 

[nikolz]

Опять DeepSeek не учел некоторые нюансы.
Для датчика движения: Пробуждение: 15 мс.

Типовые IR чипы устанавливаемые в Zigbee/BLE/Wifi датчики имеют задержку в 1 секунду от начала появления изменений в приеме для фильтрации от 50Гц. Часто на них есть выводы для переключения этой задержки фильтрации или путем изменения сопротивления. Но добиться менее 50 мс не получается и не получится - будет срабатывать постоянно...
Так же вскользь упомянуто, что в Zigbee существует период опроса (общения с устройством) в 1 qt, равный 1/4 секунды. Меньше незя. А этот интервал уже превышает комфортные нормы времени действие-ответ/реакция для человека (статистическая норма до 250 мс, для Шумахера или игрунчика в комп.игры на порядки меньше ).

Пытался написать PDU кодер/декодер с помощью DeepSeek. Пишет , проверяет, и говорит что ошибок нет. Проверяю получаю ошибки. Но программы написаны красиво с комментарием. С каждым разом все больше и больше. но работающий вариант так и не получился. Причем каждый раз Deepseek улучшает и расширяет.