ESP-NOW test 2025

[pvvx]

В BLE PAwR решает приблизительно такую-же задачу. И из-за ограничений занятости RF части количество абонентов всегда ограничено. Но это ограничение там выражено и сказывается при тысячах обсуживаемых устройствах без всяких ретрансляций за счет распределения по времени когда и кто передает в сети…
И если вам сложно читать и понимать оф. документацию по PAwR в описании стандарта, то давно есть и простые статьи

 

[pvvx]

В человейнике лучшего соединения чем кабелем UTP c POE не существует. И причина в том, что человейники заполонены WiFi роутерами и прочими устройствами WiFi, которые создают фон на уровне 30 дБр по всем каналам 2.4ГГц, в независимости от основного выбранного пользователем канала. Это уже уровень передачи из другой комнаты на основном канале. Т.е. фиг вам в человейнике принять из соседней комнаты что-то, без множества коллизий...

 

[pvvx]

И глупые мечты nikolz создавать устройства для незрячих с радиосвязью в 2.4ГГц обречены на создание беспомощности этим незрячим во множестве мест человейников...

 

[nikolz]

nRF51 и nRF24L в соединении по SPI с ESP не успевают работать и на 150 мкс. Более сотни транзакций в секунду на такой связке не получить. Проверял на нескольких примерах из инета, пробовал уменьшить все задержки - фигу что вышло.
А есть типа стандарт ESB и там 150 мкс. А можно и не по стандарту... но нафиг не нужно - и так хорошо и совместимость сохранена.
И это задержка повтора при не ответе... Сильно не влияет ни на что. И смотря как её считать - между концом передачи и началом следующей, или период.
Если период - тогда длительность передачи большого фрейма не укладывается в 150 мкс.

Вы опять боретесь с мельницами?
----------------
В устройствах серий nRF51 и nRF24L реализована аппаратная задержка в 130 мкс. Если соединение ESB устанавливается только между устройствами серий nRF52 и/или nRF53, эту задержку можно сократить до 40 мкс.
----
Это не я придумал, написано в доках разработчика.
----------------------
Если не можете доказать, то не надо переходить на личности.
Этим Вы не доказываете свою правоту, а лишь унижаете себя.
Печально, что за 10 лет общения на форуме вы так и не поняли это.

 

[pvvx]

Вы опять боретесь с мельницами?
----------------
В устройствах серий nRF51 и nRF24L реализована аппаратная задержка в 130 мкс. Если соединение ESB устанавливается только между устройствами серий nRF52 и/или nRF53, эту задержку можно сократить до 40 мкс.
----
Это не я придумал, написано в доках разработчика.
----------------------
Если не можете доказать, то не надо переходить на личности.
Этим Вы не доказываете свою правоту, а лишь унижаете себя.
Печально, что за 10 лет общения на форуме вы так и не поняли это.

Писатель, но не читатель. Что я доказывал? И где правота?

В источнике, от куда вы скопировали с авто-переводом сказано:
Задержка повторной передачи определяется как длительность между началом каждой попытки передачи. Обратите внимание, что это отличается от устаревшей аппаратной реализации серии nRF24L, где задержка определялась как длительность от окончания передачи пакета до начала повторной передачи.

Время передачи пакета с данными в 8 байт = ~100 мкс (PHY 2M).

А retransmition delay у вас 40 мкс

 

[pvvx]

Если что-то бездумно копируете и требуете пояснений, то хотя бы указывайте от куда скопировали и или о чем идет речь.

Время переключения RF с приема на передачу и обратно у nRF52 указано в даташите на чип – см nRF52840 Product Specification: 6.20.15.8 Radio timing. И оно громадно.
Но это никого не касается, если конечно это значения не больше того, что требуется для совместимости со всеми вариантами реализации ESB на любых чипах
(совместимости кроме связки ESPxx – nRF01 – там ESP тупит на полную и использовать такое не стоит).
Даже беспроводные мышки и клавиатуры поддерживают указанные мной интервалы, а не из варианта “может” быть
В итоге ~100 мкс прием пакета передачи + 40 мкс тупит nRF52 на включение TX + 100 мкс передача АСК + 40 мкс опять тупит nRF52 до следующего включения приема.
И то тут добавляется пауза (указанная в доке) после выполнения RX2TX, т.к. авто процесс заершен и требуется новый запуск RF.
В итоге у nRF52 retransmition delay получается в самом теоретическом минимуме не менее 280 мкс чтобы хоть что-то работало в ESB.
И пауза между передачами = минимум 140 мкс (+ до 40 мкс у nRF52 тупления после цикла RX2TX и запуском нового - параметр tRXEN,FAST в доке).

 

[pvvx]

tRXEN(не fast) у nRF = 130 мкс По этому 150 мкс в самый раз для совместимости.

 

[pvvx]

Вот и выходит, что начинать следующую передачу (или retransmission если не приняли АСК) менее чем через 150 мкс после конца предыдущей передачи нет смысла - nRF52 всё равно не успеет принять, FAST там или что ещё “может” . (т.е. без “может” - он в Fast - только тогда и сможет 150 мкс)