Делюсь опытом Уменьшаем потребление ESP в 10 и более раз!!!

[pvvx]

Ну и разница 700мкс при укороченном запросе и 60мс Ардуино существенна, имхо. Хотелось бы побороть.

Я так и не понял - вопрос вроде про передачу с установкой канала?
Я по тому и смотрел SoftAP...

Режим Активного сканирования (Active Scanning) - активно послылаем запросы в эфир.
Устройство посылает фреймы типа Probe Request по всем частотным каналам в поддерживаемом диапазоне часто с указанием искомого SSID сети (direct probe request) или без SSID (null probe request). Активное сканирование значительно повышает динамику работы с сетью и помогает в решении таких задач,как, например, обеспечение быстрого роуминга и т.п., но и создает некоторую дополнительную нагрузку на сеть.

Источник: Wi-Fi, Фреймы

 

[pvvx]

Появятся два примера ESP_AdHoc_Data для передатчика и приёмника.
ESP_AdHoc_Data – Google Диск

Тут ещё будет большая путаница с названиями (про что автор предупрежден). AdHoc есть в WiFi и описывает режим функционирования (IBSS - Independent Basic Service Set, одноранговые соединения типа Ad-hoc). Это примерно как задание ST, или AP, или AdHoc режима и так и прописывается в именных константах...
Да и по практике - на фрейм ProbeRequest AP отвечают пачкой по 4 и более Probe response. Это часто не успевают прокачать сниферы из-за узкого канала к логгеру или тормозов логгера... Нормальная AP при включении сканирует сеть тоже, чтобы обнаружить дубль и ещё объявляет о своем выходе. По этому выход AP в эфир это долгий процесс... У ESP этого ничего нет - обрезано.
Сканирование по другим каналам ST тоже может сделать без "разрыва" соединения с AP. Но перед этим ST оповещает AP о временном уходе с канала и по завершению оповещает, что вернулась... Не знаю, насколько правильно и быстро исполняется эта реализация в ESP... Таким образом некоторые ST держат соединение с несколькими AP имея одно-канальную антенну

 

[Сергей_Ф]

@pvvx попробую объяснить принцип работы, так как я его понял. Судя по тому что реализация работает, то похоже понял правильно.
Есть точка доступа в эфире. Это сервер-приемник. Понятно что если её реализовывать на esp, то это режим softAP или комбинированный. С установкой канала в этом режиме никаких проблем не возникло, поскольку там я использовал вызовы Ардуино. Собственно на приемнике и нет никакой необходимости экономить энергию, он в любом случае должен быть включен всегда.
А есть передатчик (датчик). В нем используется режим deep sleep и периодически выходит в эфир для передачи данных. Задача обеспечить минимальное время работы его радиопередатчика WiFi для экономии батареи.
Для этого @nikolz предложил использовать принцип передачи, описанный в HarringayMakerSpace/sonoff-adhoc
Для этого esp должен послать запрос сканирования сети с нужным каналом (либо по всем) и нужным именем точки доступа. Соединение с точкой доступа при этом не устанавливается, более того, она поднимается без возможности установки соединения (max_connection=0) . Если предварительно esp присвоить определенный адрес MAC, то точка доступа при получении запроса probe request сможет его идентифицировать и дешифровать полученный адрес в данные. Полезной информации там не много, но часто этого достаточно. Вопрос именно в запросе

Спойлер: wifi_station_scan

Scan for available access points

bool wifi_station_scan(
struct scan_config *config,
scan_done_cb_t callbackFunction)

We can scan the WiFi frequencies looking for access points. We must be in station mode in order
to execute the command. When the function is executed, we provide a callback function that
will be asynchronously invoked at some time in the future with the results.
The scan_config structure contains:
• uint8 *ssid
• uint8 *bssid
• uint8 channel
• uint8 show_hidden
If we supply this structure, then only access points that match are returned.
The scan_config parameter can be NULL in which case no filtering will be performed and all
access points will be returned.
The scan_done_cb_t is a function with the following structure:
void (*functionName)(void *arg, STATUS status)
The arg parameter is a pointer to a struct bss_info .

Я заполняю config и передаю его для вызова wifi_station_scan, но запрос отправляется всегда на канал 1. Понимаю, что я что-то сократил больше чем нужно, но не понимаю что.
В принципе датчику не нужно даже слушать ответ от точки доступа, передал - и уснул. Потому посчитал возможным убрать колбэк, в котором надо слушать ответ. Время это существенно экономит, а подтверждение приема не всегда нужно.

С названием я особо не думал, возможно его надо поменять, взял от автора идеи.

 

[pvvx]

Для этого @nikolz предложил использовать принцип передачи, описанный в HarringayMakerSpace/sonoff-adhoc

https://github.com/HarringayMakerSpace/sonoff-adhoc
Это решение CNLohr-да, но не суть... Передавать-принимать можно любой пакет. Выбор лежит в тех, которые доступны для приема стандартными средствами.
ProbeRequest ESP принимает с любыми данными MAC и ...
Ещё Web-свалка выдавала массив последних пойманных в эфире запросов ProbeRequest (выдает xml на web запрос ../pr_request.xml).
А вот с передачей произвольных пакетов на ESP всё хуже. Много зависимостей от версий SDK. Этот вопрос так и не решен.

С названием я особо не думал, возможно его надо поменять, взял от автора идеи.

У нас есть ещё один "AdHoc бинарный протокол "

 

[pvvx]

Закончилось эта эпопея "с передачей от датчика" в ESP тем, что время работы загрузчика у nikolz превышало время отправки произвольного пакета. Он так и не вышел на 60..70 мс итогового активного режима между deep-sleep, достигнутого другими. Причины в недопонимании и не взвешивании времен разных стадий процесса загрузки у ESP + к примеру, стандартные вызовы перехода в deep-sleep в SDK составляют от 100 мс...

Хотя и было получено 60..70 мс, но применимость не нашлась – ESP не умеет просыпаться по внешнему событию, да и период от события до обработки слишком велик. Большинство микросхем датчиков (сверх дешевых ардуино-подобных) имеют задержки инициализации и/или готовки ответа после запроса через менее 30 мс. За это время ESP8266 не успевает “поспать”, а жрет в тысячи раз больше работающего датчика... (Тут опять only BLE)
Т.е. для работы в таких системах ESP8266 обрастает внешними костылями превышающими его стоимость, что позволяет поставить другой нормальный SoC и забыть о глюках.

 

[pvvx]

Возьмем, к примеру, accelerometer sensor – все они имеют FIFO. Для разрешения каких-то событий, типа “клик”, смещение, “двойной клик” – программируются прерывания. При анализе чего-то другого нужен поток с около 50 замеров по трем осям в секунду. Хотя у них и FIFO большое (100..500 точек), то все равно надо его считывать для анализа достаточно часто. ESP с таким датчиком экономии энергии обеспечить не может. А BLE – запросто – он успевает спать между считываниями FIFO. По i2c на 400кГц это не более 2 мс каждые 40 мс и потери составляют всего +1 мс на запуск мозгов BLE чипа с потреблением до 5 мА (за весь цикл считывания и обработки данных с датчика на всех современных чипах BLE).

Датчики температуры и влажности i2c - периодическое считывание полученного значения и отправка команды на новый замер имеет период 30..400 мс. ESP8266 опять в пролете.

Ну и т.д.

 

[pvvx]

По цифрам:
ESP8266 имеет минимальную активность 60 мс (+10 если нужна передача) со средним током 70 мА.
BLE имеет минимальную активность 1 мс (+2 мс если нужна передача с подтверждением) со средним током 5..9 мА.
Итого: разница в потреблении 60*10 = 600 раз
Дальность связи у BT 5.0 одинакова с ESP8266.

 

[Сергей_Ф]

@pvvx так никто и не спорит, что BLE5.0 лучше. Реальное время я не замерял, но при отсылки запроса probe request esp укладывается в 700 мкс по счетчику micros(). Это без ожидания подтверждения. Понятно, что есть время на старт и время на засыпание, надо будет померить потом. Может ещё и micros() врёт, тогда будет больше.
Но вот с подтверждением, даже на Ардуино получается 60 мс на передачу 4 байт. Вот и хотел понять откуда это более 60-кратное увеличение времени, да ещё проблема с выставлением канала вылезла .

 

[pvvx]

@pvvx так никто и не спорит, что BLE5.0 лучше. Реальное время я не замерял, но при отсылки запроса probe request esp укладывается в 700 мкс по счетчику micros(). Это без ожидания подтверждения. Понятно, что есть время на старт и время на засыпание, надо будет померить потом. Может ещё и micros() врёт, тогда будет больше.
Но вот с подтверждением, даже на Ардуино получается 60 мс на передачу 4 байт. Вот и хотел понять откуда это более 60-кратное увеличение времени, да ещё проблема с выставлением канала вылезла .

По памяти - когда баловался с отсылкой произвольного пакета в ESP8266 то по началу выходило, что-то 20 мс. Потом запатчил в бинарной либе переход и ожидание ответа (перевод RF на прием).
Ещё не забудьте об инициализации WiFi RF блока.
Программно полное переключение RF части в SoC сопровождается передачей к 20..100 значений регистров. Это какие-то до пары мкс или менее. Но Espressif посчитали что это вам не надо - сИкретно (спрятали из-за нарушения патентов)...