Ещё чуть-чуть о ESP-NOW

[Heatseeker]

Приветствую.
Рискну ещё раз поднять тему о потере пакетов при использовании протокола ESP-NOW.
Постараюсь покороче.
Начал изучать работу этого протокола, он мне подходил для проекта. Энергоэффективность не важна, питание от сети. Почитал форум о потере пакетов при пересылке по протоколу ESP-NOW. Решил проверить, насколько все плохо. В общем, конфигурация следующая.
ESP32 - принимающая сторона, ESP8266 передающая.
Написаны 2 программы для этих контроллеров.
ESP8266 отправляет 10 раз в секунду по 1 пакету с данными 60-70 байт каждый. Проверяет по callback, доставлен или нет пакет. Тайм-аут ожидания ответа 10мс , если превышен тайм-аут, то пакете отсылается повторно.
Принимающая сторона регистрирует пакеты и увеличивает счётчик поступлений, выводя его на oled дисплей.
Результат работы следующий. За 10 мин отослано 6000 пакетов. При этом передатчик ESP8266 определил около сотни недоставок, и повторил, по его мнению, потерянные пакеты. Итого он послал 6105 пакетов для гарантированной доставки 6000 из них
Вроде бы все норм и потерянные пакеты в итоге дошли, но. Взглянем на приемник на ESP32.
Видим, что кол-во полученных пакетов равно не 6000, а 6104 пакета. То есть ESP32 реально принимало пакеты, а есп8266 не получало ответы вовремя (больше 10мсек). Увеличил тайм-аут до 20мсек, количество неподтвержденных пакетов уменьшилось на 20-30%.
Как резюме. Доставка на расстояние десять метров через 1 стену, Иден нормально, а ответы о доставке идут черте-как долго. Более 20 мс - это совсем не дело.
Кто, что думает? Может я какой режим или параметр не учел?

 

[rkit]

Проверяет по callback, доставлен или нет пакет

Это не подтверждает доставку, это подтверждает успешную отправку.

 

[nikolz]

Приветствую.
Рискну ещё раз поднять тему о потере пакетов при использовании протокола ESP-NOW.
Постараюсь покороче.
Начал изучать работу этого протокола, он мне подходил для проекта. Энергоэффективность не важна, питание от сети. Почитал форум о потере пакетов при пересылке по протоколу ESP-NOW. Решил проверить, насколько все плохо. В общем, конфигурация следующая.
ESP32 - принимающая сторона, ESP8266 передающая.
Написаны 2 программы для этих контроллеров.
ESP8266 отправляет 10 раз в секунду по 1 пакету с данными 60-70 байт каждый. Проверяет по callback, доставлен или нет пакет. Тайм-аут ожидания ответа 10мс , если превышен тайм-аут, то пакете отсылается повторно.
Принимающая сторона регистрирует пакеты и увеличивает счётчик поступлений, выводя его на oled дисплей.
Результат работы следующий. За 10 мин отослано 6000 пакетов. При этом передатчик ESP8266 определил около сотни недоставок, и повторил, по его мнению, потерянные пакеты. Итого он послал 6105 пакетов для гарантированной доставки 6000 из них
Вроде бы все норм и потерянные пакеты в итоге дошли, но. Взглянем на приемник на ESP32.
Видим, что кол-во полученных пакетов равно не 6000, а 6104 пакета. То есть ESP32 реально принимало пакеты, а есп8266 не получало ответы вовремя (больше 10мсек). Увеличил тайм-аут до 20мсек, количество неподтвержденных пакетов уменьшилось на 20-30%.
Как резюме. Доставка на расстояние десять метров через 1 стену, Иден нормально, а ответы о доставке идут черте-как долго. Более 20 мс - это совсем не дело.
Кто, что думает? Может я какой режим или параметр не учел?

вообще-то для ESP типичное время 100 ms.
Вы передаете пакеты каждые 100 ms, поэтому и ожидание надо установить аналогичное.
Попробуйте увеличить время ожидания до 100.
Если хотите действительно разобраться, то надо начать с посылки пакетов 1 в секунду и если потерь нет постепенно увеличивать скорость.
У ESP32 желательно задействовать для этого второе ядро (если возможно).
-----------------
я делал исследования для ESP8266 - потерь пакетов не наблюдал. минимальное время для отсылки пакета и режим deep-sleep получилось 120 ms

 

[Heatseeker]

Это не подтверждает доставку, это подтверждает успешную отправку.

Читаем документацию:
Call esp_now_send() to send ESP-NOW data and esp_now_register_send_cb to register sending callback function. It will return ESP_NOW_SEND_SUCCESS in sending callback function if the data is received successfully on the MAC layer.
Так что, callback возвращает именно информацию о успешности именно доставки.

Вечером сделаю тест с таймаутом 50 и 100 мс. Для 100 мс придется сократить частоту отправок до 5 пакетов в секунду, чтобы временные диаграммы отправок и проверок не накладывались. Хотя такие задержки - это вообще бред, не должно устройство 100 мс в delay висеть. Вообще не комильфо.

 

[rkit]

Читаем документацию

on the MAC layer

 

[Heatseeker]

Читаем документацию

Читаем дальше.
It is not guaranteed that application layer can receive the data. If necessary, send back ack data when receiving ESP-NOW data.

Это значит следующее. Даже если вам пришло ESP_NOW_SEND_SUCCESS о доставке пакета на канальном уровне, нет гарантии, что до прикладного уровня он дошёл.
Ясно, что канальный ниже прикладного. И мне не приходят своевременно ответы о получении именно на канальном уровне, хотя приемник видит пакеты уже на прикладном.
Нет никакой нужды делать проверку доставки на более высоких уровнях, если на нижних ответ отрицательный.

 

[pvvx]

Более 20 мс - это совсем не дело.
Кто, что думает? Может я какой режим или параметр не учел?

Не отключен вывод логов в UART.
И условия радиоэфира не описаны. Как будет вести себя приемник, если получил преамбулу от стороннего WiFi пакета, а затем пошел ваш с более низким RSSI?
Коллизий в городском эфире WiFi немерянно. Это в пещере у nicolz всё хорошо, когда на столе два ESP и более ничего...
А если вдруг по WiFi кто-то смотрит кино, то канал полностью забит, на все 100%

 

[pvvx]

WiFi устройства переждут хоть секунды забитого канала в эфире – на то есть буферизация в роутере. Это в браузере и не заметно - там тайм-ауты до повтора от 20 сек. А ваш ESP-NOW то как, с всего 10 мс ожиданием? Ставьте сразу 1000 повторов

 

[pvvx]

У всех ESP от espressif и так нелады с приемником WiFi или драйверами – не понимэ короткую преамбулу в новых, т.е. уже старых для современной техники, стандартах WiFi, а вы хотите использовать какой-то кривой обрубок... Только это уже сильно увеличивает вероятность выпадения приема.

На все чипы ESP в PDF давно надо было написать “не для новых разработок”, а для ностальгирующих блогеров.

 

[p-a-h-a]

Вопрос к знатокам: Что означает функция (Документация)
esp_now_set_wake_window( window uint16_t )
работает только при использовании WiFi.disconnect() в режиме STA;
Правильно ли понимаю что после отправки пакета ESP-NOW wi-fi включен и жрет энергию, а задав таймаут wake_window WIFI отключается до следующей отправки? И стоит ли использовать эту функцию если после отправки вхожу в глубокий сон?

 

[p-a-h-a]

Приветствую.
Рискну ещё раз поднять тему о потере пакетов при использовании протокола ESP-NOW.
Постараюсь покороче.
Начал изучать работу этого протокола, он мне подходил для проекта. Энергоэффективность не важна, питание от сети. Почитал форум о потере пакетов при пересылке по протоколу ESP-NOW. Решил проверить, насколько все плохо. В общем, конфигурация следующая.
ESP32 - принимающая сторона, ESP8266 передающая.
Написаны 2 программы для этих контроллеров.
ESP8266 отправляет 10 раз в секунду по 1 пакету с данными 60-70 байт каждый. Проверяет по callback, доставлен или нет пакет. Тайм-аут ожидания ответа 10мс , если превышен тайм-аут, то пакете отсылается повторно.
Принимающая сторона регистрирует пакеты и увеличивает счётчик поступлений, выводя его на oled дисплей.
Результат работы следующий. За 10 мин отослано 6000 пакетов. При этом передатчик ESP8266 определил около сотни недоставок, и повторил, по его мнению, потерянные пакеты. Итого он послал 6105 пакетов для гарантированной доставки 6000 из них
Вроде бы все норм и потерянные пакеты в итоге дошли, но. Взглянем на приемник на ESP32.
Видим, что кол-во полученных пакетов равно не 6000, а 6104 пакета. То есть ESP32 реально принимало пакеты, а есп8266 не получало ответы вовремя (больше 10мсек). Увеличил тайм-аут до 20мсек, количество неподтвержденных пакетов уменьшилось на 20-30%.
Как резюме. Доставка на расстояние десять метров через 1 стену, Иден нормально, а ответы о доставке идут черте-как долго. Более 20 мс - это совсем не дело.
Кто, что думает? Может я какой режим или параметр не учел?

Сейчас протестировал ESP-NOW между ESP01->NodeMCU. Передавал структуру c двумя uint32_t в которых передавались № отправки и количество доставленных сообщений. Приемник в режиме WIFI_AP_STA подключен к роутеру 1й канал. Туда же 3 телефона и еще 3 умных устройства. Приемник в частном доме. Передатчик через две стены на улице, расстояние 10м. Частота отправок 123 сообщения в секунду. Отправитель ждет когда обратная функция вернет отчет, только после этого отправляет, потом delay(8).
В результате за 6+ минут работы:
Отправлено: 48193 сообщений, из них c подтверждением: 48141. Получено: 48150. Подтверждение не пришло 9 раз. Потеряно: 43

Heatseeker , Что значит "Увеличил тайм-аут "?

 

[p-a-h-a]

Что за ерунда выходит. Почему данные ESP-NOW успешно передаются с 4го канала вайфай на 1й?
Пытаюсь автосопряжение сделать, перебираю канали и отправляю широковещательный пакет. И тут доходя до 4го канала передатчика приемник видит пакет, находясь на 1м канале.

 

[p-a-h-a]

Пытаюсь разобраться. Канал не меняется или не отображается. Как его менять?

  for (esp_channel = 14; esp_channel >= 1; esp_channel--) {
   Serial.println(WiFi.channel());
    WiFi.printDiag(Serial);
    esp_now_add_peer(peer_addr, ESP_NOW_ROLE_COMBO, esp_channel, NULL, 0); // регистрируем пиры (плату, куда будем отправлять)
    esp_now_send(peer_addr, (uint8_t *) &msg, sizeof(msg)); // ==ESP_OK
    esp_now_del_peer(peer_addr); // Удаляем добавленный пир.
  }

Все время 1й канал пишет. Все 14 раз.