Драйвером Wi-Fi поддерживаются следующие возможности:

· 4 виртуальных Wi-Fi интерфейса: STA, AP, Sniffer и reserved.
· Режимы: только станция (station-only), только точка доступа (AP-only), и совмещенный режим(station/AP-coexistence).
· Протоколы соединения IEEE 802.11b, IEEE 802.11g, IEEE 802.11n и API-функции для конфигурирования режима протокола.
· WPA/WPA2/WPA3/WPA2-Enterprise/WPA3-Enterprise/WAPI/WPS и DPP (Device Provisioning Protocol [3]).
· AMSDU, AMPDU, HT40, QoS другие ключевые функции.
· Modem-sleep.
· Специфичный для Espressif протокол ESP-NOW и режим Long Range, что позволяет передавать данные на расстоянии до 1 км.
· Полоса пропускания до 20 мегабит/сек для TCP и до 30 мегабит/сек для UDP.
· Сниффер.
· Быстрое сканирование (fast scan) и сканирование всех каналов (all-channel scan).
· Несколько антенн.
· Информация о состоянии канала.

[Как написать приложение Wi-Fi]

Обычно самый эффективный способ начать разрабатывать свое приложение Wi-Fi - выбрать пример, который больше всего похож на ваше будущее приложение, и портировать из него полезную часть в свой проект. Не обязательно прочитать эту документацию, но все-таки это настоятельно рекомендуется, особенно если вы хотите получить надежное приложение Wi-Fi.

Эта статья (здесь приведен перевод документации [1]) является дополнением к документации Wi-Fi API / примерам. Здесь описываются принципы использования Wi-Fi API, ограничения текущей реализации Wi-Fi API, и наиболее общие промахи в использовании Wi-Fi. Также раскрываются некоторые подробности дизайна драйвера Wi-Fi. Примеры приложений Wi-Fi можно просмотреть и выбрать на GitHub [4].

Инициализация Wi-Fi, установка соединения. Основные действия для этих процедур описаны во врезке "ESP32 Wi-Fi Station General Scenario".

Обработка событий. Обычно проще всего писать код для сценариев "удачного дня", таких как события WIFI_EVENT_STA_START и WIFI_EVENT_STA_CONNECTED. Гораздо труднее написать подпрограммы для обработки сценариев неудачи, таких как событие WIFI_EVENT_STA_DISCONNECTED. Качественная обработка плохих сценариев - фундаментальное условие для построения надежных приложений Wi-Fi. Обратитесь к врезкам "Описание событий ESP32-C3 Wi-Fi" и врезке "ESP32-C3 Wi-Fi station General Scenario". Также см. описание библиотеки цикла обработки событий [5].

Восстановление из всех ошибок. Так же, как и обработка "неудачных" сценариев, хорошо работающие подпрограммы восстановления также являются фундаментально важными для надежных приложений Wi-Fi, см. врезку "ESP32-C3 Wi-Fi API Error Code".

[Инициализация параметров ESP32-C3 Wi-Fi API]

При инициализации параметров структуры для API следует придерживаться одного из двух подходов:

· Явно устанавливать все поля параметров.
· Использовать get API, чтобы сначала извлечь текущую конфигурацию, и после этого установить поля, специфичные для приложения.

Инициализация или извлечение корректного состояния всей структуры очень важно, поскольку в большинстве случаев значение поля 0 означает использование настройки по умолчанию. В будущем в структуру может быть добавлено больше полей, и инициализация их нулями будет гарантировать, что приложение все еще будет работать корректно после перехода на новый релиз ESP-IDF.

[Модель программирования ESP32-C3 Wi-Fi]

Рис. 4. Wi-Fi Programming Model.

Драйвер Wi-Fi можно рассматривать как черный ящик, который ничего не знает о высокоуровневом коде, таком как стек TCP/IP, задача приложения (application task) и задача событий (event task). Задача приложения (её код) обычно вызывает API-функции драйвера Wi-Fi для инициализации Wi-Fi и по мере необходимости, когда обрабатываются события Wi-Fi. Драйвер Wi-Fi получает API-вызовы, обрабатывает их и генерирует события для приложения.

Обработка событий Wi-Fi основана на библиотеке esp_event [5]. События посылаются драйвером Wi-Fi в цикл обработки событий по умолчанию (default event loop). Приложение может обработать эти события в callback-функциях, зарегистрированных вызовом esp_event_handler_register(). События Wi-Fi также обрабатываются компонентом esp_netif, чтобы обеспечить набор поведений по умолчанию. Например, когда станция Wi-Fi подключается к точке доступа (AP), esp_netif по умолчанию автоматически запустит клиента DHCP client.

[ESP32-C3 Wi-Fi Scan]

В настоящий момент API-функция esp_wifi_scan_start() поддерживается только в режиме станции (station mode) или в смешанном режиме (station/AP mode).

Таблица 2. Типы сканирования.

Режимы сканирования, приведенные в таблице выше, могут произвольно комбинироваться, в результате получается 8 различных сканирований:

· All-Channel Background Active Scan
· All-Channel Background Passive Scan
· All-Channel Foreground Active Scan
· All-Channel Foreground Passive Scan
· Specific-Channel Background Active Scan
· Specific-Channel Background Passive Scan
· Specific-Channel Foreground Active Scan
· Specific-Channel Foreground Passive Scan

Конфигурация сканирования. Тип сканирования и другие атрибуты, относящиеся к сканированию, конфигурируются esp_wifi_scan_start(). Таблица ниже предоставляет подробное описание wifi_scan_config_t.

Таблица 3. Поля конфигурации сканирования.

Также существуют некоторые глобальные атрибуты сканирования, которые конфигурируются API-функцией esp_wifi_set_config(), см. далее "Station Basic Configuration".

Сканирование всех точек доступа на всех каналах (Foreground). Сценарий:

Рис. 5. Foreground Scan всех каналов Wi-Fi.

Сценарий, показанный выше, описывает foreground-сканирование всех каналов в текущем потоке. Foreground-сканирование может происходить только в режиме станции, когда станция не подключена ни к одной точке доступа. Какое сканирование будет происходить foreground или background - полностью определяет драйвер Wi-Fi, и это не может быть сконфигурировано приложением.

Подробное описание сценария:

Scan Configuration Phase

s1.1: Вызов esp_wifi_set_country() для установки информации о стране (country info) если информация страны по умолчанию это то, что вам нужно. См. далее "Wi-Fi Country Code".

s1.2: Вызов esp_wifi_scan_start() для конфигурации сканирования. Как это делается, см. "Конфигурация сканирования" выше. Поскольку выполняется сканирование всех каналов, то просто установите SSID/BSSID/channel в 0.

Wi-Fi Driver’s Internal Scan Phase

s2.1: драйвер Wi-Fi переключается на канал 1. В этом случае тип сканирования WIFI_SCAN_TYPE_ACTIVE, и probe request широковещательный (broadcasted). Иначе Wi-Fi будет ждать маяка от точки доступа. Драйвер Wi-Fi будет некоторое время (dwell time) оставаться на канале 1. Dwell time конфигурируется параметрами min/max, со значениями по умолчанию 120 мс.

s2.2: Драйвер Wi-Fi переключится на канал 2, и выполнит ту же операцию, что на шаге 2.1.

s2.3: Драйвер Wi-Fi сканирует последний канал N, где N определяется кодом страны, который конфигурируется на шаге 1.1.

Scan-Done Event Handling Phase

s3.1: Когда все каналы просканированы, возникает событие WIFI_EVENT_SCAN_DONE.

s3.2: Callback-функция события приложения оповестит задачу приложения, что получено событие WIFI_EVENT_SCAN_DONE. Будет вызвана esp_wifi_scan_get_ap_num(), чтобы получить количество точек доступа, найденных во время этого сканирования. Затем выделяется достаточное количество элементов, и делается вызов esp_wifi_scan_get_ap_records() для получения записей точки доступа (AP records). Имейте в виду, что записи точки доступа в драйвере Wi-Fi будут освобождены, когда вызывается esp_wifi_scan_get_ap_records(). Не вызывайте esp_wifi_scan_get_ap_records() дважды для одного события завершения сканирования. Если esp_wifi_scan_get_ap_records() не вызвана, когда произошло событие завершения сканирования, то записи точки доступа, выделенные драйвером Wi-Fi, не будут освобождены. Поэтому убедитесь, что вызываете esp_wifi_scan_get_ap_records(), но делаете это только 1 раз.

Сканирование всех точек доступа на всех каналах (Background). Сценарий:

Рис. 6. Background Scan всех каналов Wi-Fi.

Выше показан сценарий background-сканирования всех каналов. В отличие от foreground-сканирования всех точек доступа на всех каналах, при background-сканировании драйвер Wi-Fi будет сканировать back-to-home канал в течение 30 мс перед тем, как переключится на следующий канал, чтобы дать шанс Wi-Fi-подключению передавать/принимать данные.

Сканирование определенной точки доступа на всех каналах. Сценарий:

Рис. 7. Сканирование определенной AP на всех каналах Wi-Fi.

Это сканирование подобно сканированию всех точек доступа на всех каналах (Foreground). Отличия следующие:

s1.1: На шаге 1.2 целевая точка доступа будет сконфигурирована на SSID/BSSID.

s2.1 ~ s2.N: Каждый раз, когда драйвер Wi-Fi сканирует точку доступа, происходит проверка, целевая эта точка доступа, или нет. Если сканирование WIFI_FAST_SCAN, и найдена целевая точка доступа, то возникнет событие завершения сканирования, и сканирование завершается; иначе сканирование продолжится. Обратите внимание, что первый сканируемый канал может быть не каналом 1, потому что драйвер Wi-Fi оптимизирует последовательность сканирования.

Возможна ситуация, когда несколько точек доступа совпадают с информацией целевой точки доступа, например у двух точек доступа SSID установлен "ap". В этом случае, если сканирование WIFI_FAST_SCAN, то будет найдена только первая "ap". Если сканирование WIFI_ALL_CHANNEL_SCAN, то будут найдены обе "ap", и станция подключится к одной из этих "ap" в соответствии со сконфигурированной стратегией. См. далее "Station Basic Configuration".

Вы можете сканировать определенную точку доступа, или все точки доступа на любом канале. Эти два сценария очень похожи.

Сканирование в Wi-Fi Connect. Когда вызывается esp_wifi_connect() драйвер Wi-Fi попытается сначала сканировать сконфигурированную точку доступа. Сканирование в Wi-Fi Connect такое же, как и сканирование определенной точки доступа на всех каналах, за исключением того, что не будет сгенерировано событие завершения сканирования, когда сканирование завершено. Если найдена целевая точка доступа, то драйвер Wi-Fi начнет соединение Wi-Fi; иначе будет сгенерировано событие WIFI_EVENT_STA_DISCONNECTED. См. "Сканирование определенной точки доступа на всех каналах".

Сканирование с блокировкой (Blocked Mode). Если параметр block для esp_wifi_scan_start() установлен в true, то сканирование происходит в блокирующем режиме, т. е. задача приложения будет заблокирована, пока сканирование не завершится. Сканирование с блокировкой подобно сканированию без блокировки, за исключением того, что не будет генерироваться событие завершения сканирования, когда сканирование завершилось.

Параллельное сканирование. Две задачи приложения могут вызвать одновременно esp_wifi_scan_start(), или одна и та же задача приложения может вызвать esp_wifi_scan_start() до получения события завершения сканирования. Могут иметь место оба этих сценария. Однако драйвер Wi-Fi не предоставляет адекватную поддержку нескольких конкурентных сканирований. В результате следует избегать конкурентных сканирований. Поддержка конкурентного сканирования будет расширена в будущих релизах, поскольку функционал ESP32-C3 Wi-Fi постоянно улучшается.

Сканирование, когда происходит подключение Wi-Fi. Вызов esp_wifi_scan_start() немедленно завершится неудачей, если происходит подключение Wi-Fi, потому что у подключения приоритет выше, чем у сканирования. Если сканирование потерпело неудачу из-за подключения, то рекомендуемая стратегия - немного подождать и попробовать произвести сканирование снова. Сканирование завершится успешно после завершения подключения.

Однако стратегия retry/delay может сработать не всегда. Рассмотрим следующие сценарии:

· Станция подключается к несуществующей точке доступа, или подключается к существующей, но с неправильным паролем, в таком случае всегда возникнет событие WIFI_EVENT_STA_DISCONNECTED.
· Приложение вызвало esp_wifi_connect() для повторного подключения, когда получило событие disconnect.
· Другая задача приложения, например console task, вызвала esp_wifi_scan_start() для выполнения сканирования, сканирование всегда завершается неудачей, потому что станция поддерживает соединение.
· Когда сканирование потерпело неудачу, приложение просто выполняет задержку на некоторое время, и делает повторное сканирование.

В показанных выше сценариях сканирование никогда не будет успешным, потому что станция находится в состоянии соединения. Так что если приложение подразумевает возможность подобного сценария, то оно должно предусмотреть лучшую стратегию повторного подключения. Например:

· Приложение может выбрать определение максимальных следующих друг за другом попыток переподключения с остановкой этих попыток, когда счетчик достиг максимума.
· Приложение может выбрать немедленное переподключение при первых N непрерывных переподключениях, затем дать задержку на некоторое время и снова переподключиться.
· Приложение может определить свою собственную стратегию переподключения, чтобы избежать бесполезной траты процессорного ресурса на бесконечные попытки переподключения. См. "ESP32-C3 Wi-Fi Station Connecting When Multiple APs Are Found -> Wi-Fi Reconnect" в документации [1].

[Сценарий подключения станции Wi-Fi]

Этот сценарий показывает только случай, когда на фазе сканирования найдена только одна целевая точка доступа. Для сценария, когда найдено больше одной точки доступа с одинаковыми SSID, см. "ESP32-C3 Wi-Fi Station Connecting When Multiple APs Are Found" в документации [1].

Обычно приложению не нужно заботиться о процессе подключения. Ниже приведено краткое введение в некоторые моменты процесса подключения которые могут быть интересны.

Сценарий:

Рис. 8. Процесс подключения станции к точке доступа Wi-Fi.

Scan Phase

s1.1, драйвер Wi-Fi начинает сканирование в как описано в "Wi-Fi Connect".

s1.2, если сканирование прошло неудачно и целевая точка доступа не найдена, то возникнет событие WIFI_EVENT_STA_DISCONNECTED, и код причины (reason-code) будет WIFI_REASON_NO_AP_FOUND (см. далее врезку "Wi-Fi Reason Code").

Auth Phase

s2.1, посылается пакет запроса аутентификации, и разрешается работа таймера аутентификации (auth-timer).

s2.2, если не получен пакет ответа аутентификации до истечения таймаута таймера аутентификации, то возникнет событие WIFI_EVENT_STA_DISCONNECTED, и reason-code будет WIFI_REASON_AUTH_EXPIRE (см. далее врезку "Wi-Fi Reason Code").

s2.3, Получен пакет ответа на запрос аутентификации (auth-response), и auth-timer останавливается.

s2.4, точка доступа отклонила аутентификацию в ответе, возникнет событие WIFI_EVENT_STA_DISCONNECTED, и reason-code будет WIFI_REASON_AUTH_FAIL, или причины отказа будут указаны точкой доступа (см. далее врезку "Wi-Fi Reason Code").

Association Phase

s3.1, посылается запрос ассоциации (association request), и разрешается работа таймера ожидания ассоциации.

s3.2, если ответ на запрос ассоциации не получен до истечения таймаута таймера ожидания ассоциации, то возникнет событие WIFI_EVENT_STA_DISCONNECTED, и reason-code будет WIFI_REASON_ASSOC_EXPIRE (см. далее врезку "Wi-Fi Reason Code").

s3.3, получен ответ на запрос (association response), и таймер ожидания ассоциации останавливается.

s3.4, точка доступа отклонила ассоциацию в ответе, возникнет событие WIFI_EVENT_STA_DISCONNECTED, и reason-code указывается в ответе на запрос ассоциации (см. далее врезку "Wi-Fi Reason Code").

Four-way Handshake Phase

s4.1, разрешается handshake-таймер, 1/4 EAPOL не получен до истечения таймаута handshake-таймера, возникнет событие WIFI_EVENT_STA_DISCONNECTED, и reason-code будет WIFI_REASON_HANDSHAKE_TIMEOUT (см. далее врезку "Wi-Fi Reason Code").

s4.2, получен 1/4 EAPOL.

s4.3, станция (STA) ответила 2/4 EAPOL.

s4.4, если 3/4 EAPOL не получен до истечения таймаута handshake-таймера, возникнет событие WIFI_EVENT_STA_DISCONNECTED, и reason-code будет WIFI_REASON_HANDSHAKE_TIMEOUT (см. далее врезку "Wi-Fi Reason Code").

s4.5, получен 3/4 EAPOL.

s4.6, STA ответила 4/4 EAPOL.

s4.7, STA генерирует событие WIFI_EVENT_STA_CONNECTED.

[Конфигурация ESP32-C3 Wi-Fi]

Когда разрешено Wi-Fi NVS, вся конфигурация сохраняется во flash, иначе см. Wi-Fi NVS Flash.

Wi-Fi Mode. Вызовите esp_wifi_set_mode(), чтобы установить режим Wi-Fi.

Таблица 5. Константы режима Wi-Fi.

Station Basic Configuration. API-функция esp_wifi_set_config() может использоваться для конфигурирования режима станции. Следующая таблица более подробно описывает поля конфигурации.

Таблица 6. Поля конфигурации.

Внимание: режимы безопасности WEP/WPA устарели в спецификациях IEEE 802.11-2016, и их использование не рекомендуется. Эти режимы могут быть отклонены с использованием порога режима аутентификации (authmode threshold) путем установки threshold как WPA2 через threshold.authmode в WIFI_AUTH_WPA2_PSK.

AP Basic Configuration. См. документацию [1].

Wi-Fi Protocol Mode. В настоящее время ESP-IDF поддерживате следующие режимы протокола.

Таблица 7. Режимы протокола Wi-Fi.

[Wi-Fi Easy Connect™ (DPP)]

Технология Wi-Fi Easy ConnectTM (или Device Provisioning Protocol) это безопасный и стандартизированный протокол для конфигурирования устройств Wi-Fi. Дополнительную информацию можно найти в описании API esp_dpp [6].

WPA2-Enterprise. Это безопасный механизм аутентификации для корпоративных беспроводных сетей (enterprise wireless networks). Механизм использует сервер RADIUS для аутентификации пользователей сети перед подключением их к точке доступа (Access Point, AP). Процесс аутентификации основан на политике 802.1X, и поставляется вместе с разными методами расширенного протокола аутентификации (Extended Authentication Protocol, EAP) наподобие TLS, TTLS, PEAP и т. п. Сервер RADIUS аутентифицирует пользователей на основе их учетных записей (username и password), цифровых сертификатов, или с помощью обоих этих средств. Когда ESP32-C3 в режиме станции пытается подключиться к точке доступа в режиме Enterprise, она посылает запрос аутентификации (authentication request) точке доступа, которая в свою очередь пересылает запрос серверу RADIUS, чтобы аутентифицировать станцию. На основе различных методов EAP, могут быть установлены параметры конфигурации с помощью idf.py menuconfig. WPA2_Enterprise поддерживается ESP32-C3 только в режиме станции (Station mode).

Для установки безопасного соединения точка доступа и станция договариваются и приходят к соглашению по самому лучшему возможному для использования шифровальщику. ESP32-C3 поддерживает метод 802.1X/EAP (WPA) стандарта AKM and Advanced encryption с протоколом шифрования Counter Mode Cipher Block Chaining Message Authentication (AES-CCM). Также возможна поддержка шифровальщиков, которые допустимы библиотекой mbedtls, если установлен флаг USE_MBEDTLS_CRYPTO.

ESP32-C3 в настоящий момент поддерживает следующие методы EAP:

EAP-TLS: метод, основанный на сертификате, и он требует только SSID и EAP-IDF.

PEAP: метод Protected EAP. Обязательно использование Username и Password.

EAP-TTLS: метод, основанный на учетных записях. Обязательна только аутентификация сервера, аутентификация пользователя опциональна. Username и Password обязательны. Поддерживаются разные методы Phase2, наподобие:

    - PAP: Password Authentication Protocol.
    - CHAP: Challenge Handshake Authentication Protocol.
    - MSCHAP и MSCHAP-V2.

Подробную информацию о создании сертификатов, и как запустить пример wpa2_enterprise на ESP32-C3, см. репозиторий wifi/wifi_enterprise [7].

[Wireless Network Management]

Wireless Network Management позволяет клиентским устройствам обмениваться информацией о топологии сети, включая информацию, связанную с условиями распространения радиосигнала (RF environment). Это делает каждого клиента лучше осведомленным о сети, повышая общую производительность беспроводной сети. Это часть спецификации 802.11v. Также это позволяет клиенту поддерживать Network assisted Roaming. Network assisted Roaming позволяет WLAN посылать сообщения соответствующим клиентам, в результате клиенты связываются с точками доступа, у которых лучшие метрики для связи. Это полезно как для балансировки нагрузки беспроводной сети, так и направлению подключения для клиентов, испытывающих проблемы со связью.

Текущая реализация 802.11v включает поддержку для кадров управления быстрым роумингом (BSS transition management frames).

[Radio Resource Measurement]

Стандарт управления ресурсами радиоканала (Radio Resource Measurement, 802.11k) предназначен для улучшения распространения трафика по сети. В беспроводной сети (wireless LAN, WLAN) каждое устройство обычно подключается к той точке доступа (access point, AP), от которой приходит более сильный сигнал. В зависимости от количества конкурирующих подписчиков и их географического места расположения такое согласование общего радиоканала может привести к чрезмерной нагрузке на одну точку доступа, и недостаточное использование других точек доступа, в результате производительность сети ухудшается. В организации сети, удовлетворяющей стандарту 802.11k, если у точки доступа самый сильный сигнал, и она загружена полностью, то беспроводное устройство может быть перемещено на одну из других недогруженных точек доступа. Даже если уровень сигнала может быть ниже, общая пропускная способность при этом повысится за счет более эффективного использования сетевых ресурсов.

Текущая реализация 802.11k включает поддержку отчета измерения маяка (beacon measurement report), отчета измерения линка (link measurement report) и опроса соседа по сети (neighbor request).

См. описание примера ESP-IDF examples/wifi/roaming/README.md для настройки и использования этих API-функций. Код примера только демонстрирует, как использовать этот функционал, и приложение должно определить собственный алгоритм для разных случаев использования.

[Wi-Fi Location]

Wi-Fi Location улучшает точность данных месторасположения (location data) по отношению к точке доступа (Access Point, AP), что позволяет создавать новые, богатые возможностями приложения и службы, такие как геозонирование (geo-fencing), управление сетью (network management), навигация и другие полезные функции. Один из протоколов, который используется для определения места положения устройства по отношению к точке доступа - Fine Timing Measurement, который вычисляет время доставки по радио (Time-of-Flight) кадра Wi-Fi.

Fine Timing Measurement (FTM). FTM используется для измерения круговой задержки распространения сигнала Wi-Fi Round Trip Time (Wi-Fi RTT), что дает возможность измерить время, за которое сигнал проходит от одного устройства к другому, и обратно. С помощью Wi-Fi RTT расстояние между устройствами может быть вычислено по простой формуле RTT * c / 2, где c это скорость света. FTM использует метки времени, предоставляемые аппаратурой интерфейса Wi-Fi в моменты, когда кадры Wi-Fi приходят или уходят при обмене между парами устройств. Один из участников такого измерения, который называется FTM Initiator (обычно это устройство станции), обнаруживает другой объект, FTM Responder (может быть либо станцией, либо точкой доступа), и согласовывает запуск процедуры FTM. Эта процедура использует несколько кадров Action, отправляемых пачками, и подтверждений на них (ACK-кадры), чтобы определить по меткам времени задержку. FTM Initiator захватывает данные в конце этого процесса, и вычисляет среднее Round-Trip-Time. ESP32-C3 поддерживает технологию FTM в следующей конфигурации:

· ESP32-C3 как FTM Initiator в режиме станции.
· ESP32-C3 как FTM Responder в режиме SoftAP.

Измерение дистанции с использованием RTT неточное, потому что на измерение влияют такие факторы, как наложение и отражение сигналов RF, множественные пути распространения сигнала, ориентация антенны и неточность калибровки. Чтобы улучшить результаты, рекомендуется выполнить FTM между двумя устройствами ESP32-C3, работающими как станция и SoftAP. См. ESP-IDF файл описания примера examples/wifi/ftm/README.md для необходимых шагов по настройке и выполнению FTM.

[ESP32-C3 Wi-Fi Power-saving Mode]

Station Sleep (режим сна станции). В настоящий момент ESP32-C3 Wi-Fi поддерживает режим Modem-sleep, который относиться к обычному режиму пониженного энергопотреблению (power-saving mode) в протоколе IEEE 802.11. Режим Modem-sleep работает в режиме "только станция" (Station-only mode) и станция сначала должна подключиться к точке доступа (AP). Если разрешен режим Modem-sleep, то станция будет периодически переключаться между состоянием активности (active) и сна (sleep). В состоянии сна блоки RF, PHY и BB выключаются для снижения энергопотребления. В режиме modem-sleep станция может сохранять соединение с точкой доступа.

Режим Modem-sleep включает режимы минимального снижения потребления мощности (minimum power save mode) и максимального снижения потребления мощности (maximum power save mode). В minimum power save mode, станция пробуждается каждый DTIM для приема маяка (beacon). Данные широковещания (broadcast data) не теряются, потому что передаются после DTIM. Однако если DTIM короткий, то не получается экономить значительное количество мощности, и DTIM определяется точкой доступа.

В maximum power save mode станция пробуждается в каждом интервале прослушивания для приема маяка. Этот интервал прослушивания (listen interval) может быть установлен больше, чем период DTIM точки доступа. В этом случае данные широковещания могут быть потеряны, потому что станция может быть в состоянии сна во время DTIM. Чем интервал прослушивания дольше, тем больше мощности экономится, однако больше теряется данных широковещания. Интервал прослушивания может быть сконфигурирован вызовом esp_wifi_set_config() перед подключением к точке доступа.

Вызовите esp_wifi_set_ps(WIFI_PS_MIN_MODEM) для разрешения режима минимального сохранения энергии Modem-sleep, или esp_wifi_set_ps(WIFI_PS_MAX_MODEM) для режима максимального сохранения энергии после вызова esp_wifi_init(). Когда станция подключилась к точке доступа, запуститься режим Modem-sleep. Когда станция отключится от точки доступа, режим Modem-sleep остановится.

Вызовите esp_wifi_set_ps(WIFI_PS_NONE) для полного запрета modem sleep. Это приведет к намного большему потреблению энергии, однако предоставит минимальную латентность для приема данных Wi-Fi в реальном времени. Когда режим modem sleep разрешен, принятые данные Wi-Fi могут задерживаться пока длится период DTIM (в режиме минимального сохранения энергии), или интервал прослушивания (в режиме максимального сохранения энергии). Полный запрет modem sleep невозможен для совместного использования Wi-Fi и Bluetooth.

Режим по умолчанию Modem-sleep - WIFI_PS_MIN_MODEM.

AP Sleep (режим сна точки доступа). В настоящее время точка доступа на основе ESP32-C3 не поддерживает все возможности экономии энергии, определенные в спецификации Wi-Fi. Если точнее, то точка доступа только кэширует unicast-данные для станций, подключенных к этой точке доступа, но multicast-данные для станций не кэшируются. Если на станциях, подключенных к точке доступа на ESP32-C3, разрешен режим пониженного потребления энергии, то может быть потеря multicast-пакетов.

В будущем планируется реализовать поддержку всех функций энергосбережения на точке доступа ESP32-C3.

[Пропускная способность радиоканала ESP32-C3 Wi-Fi]

В следующей таблице показаны самые лучшие результаты по пропускной способности, полученные при лабораторных испытаниях для модуля, заключенного в экран.

Таблица 11. Пропускная способность в разных условиях использования.

Когда пропускная способность тестируется с помощью примера iperf, используется sdkconfig в файле examples/wifi/iperf/sdkconfig.defaults.esp32c3.

[Отправка пакета Wi-Fi 80211]

API-функция esp_wifi_80211_tx() может использоваться для следующих целей:

· Отправка маяка (beacon), probe request, probe response, action frame.
· Отправка non-QoS кадра данных.

Это не может использоваться для отправки шифрованых кадров или кадров с QoS.

Предварительные условия для использования esp_wifi_80211_tx():

· Режим Wi-Fi или Station, или AP, или Station+AP.
· Какая-либо из следующих функций возвратила ESP_OK: либо esp_wifi_set_promiscuous(true), либо esp_wifi_start(), либо обе эти функции. Причина в том, что нам нужно убедиться, что аппаратура Wi-Fi была инициализирована перед вызовом esp_wifi_80211_tx(). В ESP32-C3 оба вызова, esp_wifi_set_promiscuous(true) и esp_wifi_start() могут запустить инициализацию аппаратуры Wi-Fi.
· Предоставлены корректные параметры esp_wifi_80211_tx().

Скорость передачи данных. Если соединение Wi-Fi отсутствует, скорость передачи данных составляет 1 Мбит/с. При наличии Wi-Fi-соединения и наличии пакета от станции к точке доступа или от точки доступа к станции скорость передачи данных совпадает со скоростью передачи данных по Wi-Fi-соединению. В противном случае скорость передачи данных составляет 1 Мбит/с.

Побочные эффекты, которых надо избегать в различных сценариях. Теоретически, если мы не рассматриваем побочные эффекты, которые API накладывает на драйвер Wi-Fi или другие станции/точки доступа, мы можем послать по радио необработанный пакет 802.11, с любым MAC назначения, любым MAC источника, любым BSSID или любым другим типом пакета. Однако надежные/полезные приложения должны избегать таких побочных эффектов. В таблице ниже приведены некоторые советы/рекомендации, как избежать побочных эффектов esp_wifi_80211_tx () в различных сценариях.

Таблица 12. Советы по надежному использованию.

[Wi-Fi Sniffer Mode]

Режим снифера Wi-Fi можно разрешить вызовом esp_wifi_set_promiscuous(). Если режим снифера разрешен, то приложение может выводить дампы следующих пакетов:

· 802.11 Management frame.
· 802.11 Data frame, включая MPDU, AMPDU, AMSDU.
· 802.11 MIMO frame. Для MIMO frame сниффер только выводит длину кадра (length frame).
· 802.11 Control frame.

Дамп следующих пакетов не может быть выведен приложением:

· 802.11 error frame, такой как кадо с ошибкой CRC, и т. п.

Для кадров, которые сниффер может вывести в дамп, приложение может дополнительно определить, какой определенный тип пакетов можно отфильтровать, используя esp_wifi_set_promiscuous_filter() и esp_wifi_set_promiscuous_ctrl_filter(). По умолчанию для приложения фильтруются все кадры данных (802.11 data frames) и кадры управления (management frames).

Сниффер Wi-Fi может быть разрешен в режиме WIFI_MODE_NULL, WIFI_MODE_STA, WIFI_MODE_AP или WIFI_MODE_APSTA. Другими словами, режим снифера активен, когда станция подключена к AP, или когда у AP есть соединение Wi-Fi. Обратите внимание, что сниффер сильно ухудшает пропускную способность Wi-Fi соединения станции или Wi-Fi соединения точки доступа. Обычно мы не должны разрешать сниффер, когда Wi-Fi соединение станции/AP передает плотный трафик, если на то нет веских причин.

Есть еще одна проблема, связанная со сниффером - callback-функция wifi_promiscuous_cb_t. Этот callback будет вызываться непосредственно из задачи драйвера (Wi-Fi driver task), так что если у приложения есть какая-либо обработка для каждого отфильтрованного пакета, то рекомендуется в этом callback публиковать событие (post event) в задачу приложения (application task), чтобы переложить реальную обработку не на драйвер, а на код приложения, выполняющийся в фоновом режиме.

wifi_ant_gpio_config_t config = {
   { .gpio_select = 1, .gpio_num = 20 },
   { .gpio_select = 1, .gpio_num = 21 }
};

wifi_ant_config_t config = {
   .rx_ant_mode = WIFI_ANT_MODE_AUTO,
   .rx_ant_default = WIFI_ANT_ANT0,
   .tx_ant_mode = WIFI_ANT_MODE_ANT1,
   .enabled_ant0 = 1,
   .enabled_ant1 = 3
};

[Wi-Fi Channel State Information]

Информация о состоянии канала (CSI) относится к соединению Wi-Fi. В ESP32-C3 эта информация состоит из частотных откликов каналов поднесущих и оценивается при приеме пакетов от передатчика. Каждый частотный отклик канала поднесущей записывается комплексным значением в виде двух байт со знаком. Первый обозначает мнимую (imaginary) часть, и второй реальную (real) часть. Существует до трех полей частотных откликов канала в зависимости от типа принятого пакета. Это пакеты LLTF, HT-LTF и STBC-HT-LTF. Для различных типов пакетов, которые приняты на каналах с различным состоянием в следующей таблице показаны индекс поднесущей (sub-carrier index) и байты комплексных значений CSI.

Таблица 13. Состояния канала, индекс поднесущей, байты CSI.

Вся информация из этой таблицы находится в структуре wifi_csi_info_t.

· Вторичный канал относится к полю secondary_channel поля rx_ctrl.
· Режим сигнала относится к полю sig_mode поля rx_ctrl.
· Полоса канала относится к полю cwb поля rx_ctrl.
· STBC относится к полю stbc поля rx_ctrl.
· Общее количеств байт относится к полю len.
· CSI data соответствуют каждому типу Long Training Field (LTF), сохраненному в буфере, начинающемуся от поля buf. Каждый элемент сохраняется в 2 байтах: мнимая часть (imaginary), за которой идет реальная часть (real). Порядок для каждого элемента такой же, как в sub-carrier таблицы. Порядок LTF: LLTF, HT-LTF, STBC-HT-LTF. Однако все 3 LTF-а могут не присутствовать, в зависимости от канала и информации пакета (см. выше).
· Если поле first_word_invalid в wifi_csi_info_t равно true, то это значит, что первые 4 байта CSI data некорректные из-за аппаратных ограничений ESP32-C3.
· Дополнительная информация, наподобие RSSI, шумовой порог RF, время приема и антенна antenna, находится в поле rx_ctrl.

Примечания:

· Для пакета STBC предоставляется CSI для каждого продолжительного потока без CSD (Cyclic Shift Delay [13]). Поскольку каждый циклический сдвиг на дополнительных цепях должен быть -200 нс, в поднесущей 0 (sub-carrier) HT-LTF и STBC-HT-LTF записывается только угол CSD первого пространственно-временного потока для отсутствия частотной характеристики канала в поднесущей 0. CSD[10:0] кодируется 11 битами, в диапазоне от -pi до pi.
· Если LLTF, HT-LTF или STBC-HT-LTF не разрешены с помощью вызова esp_wifi_set_csi_config(), общее количество байт CSI data будет меньше, чем в таблице. Например, если LLTF и HT-LTF не разрешены, и STBC-HT-LTF разрешен, то когда принят пакет с состоянием above/HT/40MHz/STBC, общее количество байт CSI data будет 244 ((61 + 60) * 2 + 2 = 244, результат выравнивается на 4 байта, и последние 2 байта не содержат значимой информации).

[Конфигурирование Wi-Fi Channel State Information]

Для использования Wi-Fi CSI нужно выполнить следующие шаги.

· Выберите Wi-Fi CSI в menuconfig, это находится в разделе Components config –> Wi-Fi –> WiFi CSI(Channel State Information).
· Установите callback-функцию приема CSI вызовом esp_wifi_set_csi_rx_cb().
· Сконфигурируйте CSI вызоволм esp_wifi_set_csi_config().
· Разрешите CSI вызовом esp_wifi_set_csi().

Callback-функция приема CSI запускается из задачи драйвера Wi-Fi (Wi-Fi task). Таким образом, в этой callback-функции не должно быть долгих операций. Вместо этого поместите необходимые данные в очередь, и обрабатывайте их в задаче с более низким приоритетом. Из-за того, что станция не принимает любой пакет, когда она отключена, и принимает только пакеты от точки доступа, когда станция подключена, рекомендуется разрешит режим sniffer, чтобы принимать больше CSI data путем вызова esp_wifi_set_promiscuous().

[Wi-Fi HT20/HT40]

ESP32-C3 поддерживает полосу частот Wi-Fi HT20 или HT40, но не одновременно. Может использоваться вызов esp_wifi_set_bandwidth(), чтобы поменять полосу по умолчания станции или точки доступа. HT40 является полосой по умолчанию для станции или точки доступа на основе ESP32-C3.

В режиме станции фактическая полоса пропускания сначала согласовывается по время Wi-Fi подключения. И это полоса HT40 только если обе стороны - станция и точка доступа - её поддерживают, иначе используется HT20. Если меняется полоса подключенной точки доступа, то фактическая полоса пропускания согласовывается заново без отключения Wi-Fi.

Подобным образом в режиме точки доступа фактическая полоса пропускания согласовывается между точкой доступа (AP) и станциями, которые к ней коннектятся. Выбирается HT40, если обе стороны соединения это поддерживают, иначе выбирается HT20.

В режиме совмещения стация/точка доступа (station/AP coexist mode), устройство может сконфигурировать HT20/40 по отдельности. Если и станция, и точка доступа обе договорились о HT40, то канал HT40 должен быть каналом станции, потому что на ESP32-C3 у станции всегда более высокий приоритет, чем у точки доступа. Например, сконфигурированная полоса частот у точки доступа HT40, сконфигурированный primary-канал 6 и сконфигурированный secondary-канал 10. Станция подключена к роутеру, у которого primary-канал 6 и secondary-канал 2, то фактический канал точки доступа автоматически меняется на primary 6 и secondary 2.

Теоретически у HT40 может быть лучше пропускная способность, потому что максимальная физическая скорость данных на низком уровне (PHY) для HT40 150 Mbps, в то время как у HT20 72Mbps. Однако если устройство работает в некотором специальном окружении, например слишком много других Wi-Fi устройств вокруг устройства ESP32-C3, то производительность HT40 может ухудшиться. Таким образом, если приложениям надо поддерживать такой же или подобные сценарии, то рекомендуется всегда конфигурировать полосу частот HT20.

[Wi-Fi QoS]

ESP32-C3 поддерживает все обязательные функции, требуемые сертификацией WFA Wi-Fi QoS.

Спецификацией Wi-Fi определены 4 категории качества доступа AC (Access Category), у каждой AC назначен свой приоритет для доступа к каналу Wi-Fi. Дополнительно определяется правило привязки (map rule), которое связывает приоритет QoS другого протокола, такого как 802.11D и TCP/IP precedence, с Wi-Fi AC.

В следующей таблице описывается, как IP Precedences привязываются к категориям Wi-Fi AC на устройстве ESP32-C3. Также определяется, поддерживается ли AMPDU для AC. Таблица сортируется в порядке убывания приоритета, т.е. AC_VO имеет наивысший приоритет.

Таблица 14. Приоритеты трафика Wi-Fi.

Приложение может использовать фичу QoS конфигурированием IP precedence через socket-опцию IP_TOS. Пример, как создать сокет для использования очереди VI:

const int ip_precedence_vi = 4;

const int ip_precedence_offset = 5;

int priority = (ip_precedence_vi « ip_precedence_offset);
setsockopt(socket_id, IPPROTO_IP, IP_TOS, &priority, sizeof(priority));

Теоретически AC с более высоким приоритетом имеет производительность лучше, чем AC с приоритетом ниже, однако это не всегда верно. Несколько рекомендаций о том, как использовать Wi-Fi QoS:

· Для некоторого особо важного трафика приложения его можно поместить в очередь AC_VO. Избегайте посылать большой трафик через очередь AC_VO. С одной стороны, очередь AC_VO не поддерживает AMPDU и не может получить лучшую производительность, чем другая очередь, если трафик слишком плотный, с другой стороны это может влиять на кадры управления (management frames), которые также используют очередь AC_VO.
· Избегайте использовать более двух разных поддерживаемых AMPDU приоритетов (precedences), например socket A использует precedence 0, socket B использует precedence 1, socket C использует precedence 2: это будет плохим дизайном, потому что потребует больше памяти. Т. е. драйвер Wi-Fi может генерировать сессию Block Ack для каждого precedence, и это потребует больше памяти, если Block Ack определена в настройке.

[Wi-Fi AMSDU]

ESP32-C3 поддерживает AMSDU приема и передачи.

[Wi-Fi Fragment]

ESP32-C3 поддерживает прием и передачу фрагмента Wi-Fi.

[WPS Enrollee]

ESP32-C3 поддерживает фичу WPS enrollee в режимах WIFI_MODE_STA или WIFI_MODE_APSTA. В настоящий момент поддерживается WPS enrollee типа PBC и PIN.

[Wi-Fi Buffer Usage]

В этой секции описывается только конфигурирование динамических буферов.

Почему конфигурирование буфера так важно. Чтобы получить по настоящему высокопроизводительную систему, следует уделить особое внимание использованию и конфигурированию памяти по следующим причинам:

· Доступная память ESP32-C3 весьма ограничена.
· В настоящий момент по умолчанию используется динамический тип буфера в библиотеке LwIP и драйверах Wi-Fi. Это означает, что и LwIP, и Wi-Fi используют общую память вместе с приложением. Программистам следует иметь это в виду, иначе есть риск столкнуться с проблемой нехватки памяти, такой как переполнение кучи ("running out of heap memory").
· Переполнение кучи очень опасно, это приведет к непредсказуемому поведению ESP32-C3 (undefined behavior). Таким образом распределение памяти приложения должно быть тщательно спланировано.
· Пропускная способность Wi-Fi сильно зависит от конфигураций, связанных с памятью, таких как размер окна TCP (TCP window size), количество динамических буферов Wi-Fi RX/TX, и т. п.
· Пиковое потребление памяти в куче стеками ESP32-C3 LwIP/Wi-Fi может зависеть он нескольких факторов, таких как максимальное количество соединений TCP/UDP, которое может быть у приложения, и т. п.
· Также значимым фактором будет общее количество памяти, которое необходимо приложению.

По этим причинам лучше всего рассматривать специально разрабатывать конфигурацию памяти для каждого отдельного приложения.

Динамический буфер против статического. Как уже упоминалось, по умолчанию драйверы Wi-Fi используют динамические буферы (память кучи). Во многих случаях динамическое выделение памяти позволяет значительно экономить оперативную память. Однако это несколько усложняет написание приложения, потому что в этом случае приложению нужно учитывать, что память кучи также используется и для Wi-Fi.

Стек lwIP также выделяет буферы на слое TCP/IP, и эти буферы также динамические. См. секцию "Performance Optimization" документации lwIP [14], где описывается использование памяти и производительность этой библиотеки.

Пиковое использование динамического буфера Wi-Fi. Драйвер Wi-Fi поддерживает несколько типов буфера (см. далее "Конфигурирование буфера Wi-Fi"). Однако в этой секции акцент описания сосредоточен только на динамическом буфере Wi-Fi. Пиковый расход кучи, на выделение памяти для Wi-Fi имеет теоретический максимум, который драйвер Wi-Fi может потребить. Обычно пиковый расход памяти зависит от следующего:

· Сконфигурированное количество динамических буферов приема: wifi_rx_dynamic_buf_num.
· Сконфигурированное количество динамических буферов передачи: wifi_tx_dynamic_buf_num.
· Максимальный размер пакета, который может принять драйвер Wi-Fi: wifi_rx_pkt_size_max.
· Максимальный размер пакета, который может отправить драйвер Wi-Fi: wifi_tx_pkt_size_max.

Таким образом, пиковое количество памяти кучи, которое может потребить драйвер Wi-Fi, можно вычислить по следующей формуле:

wifi_dynamic_peek_memory = (wifi_rx_dynamic_buf_num * wifi_rx_pkt_size_max)
                         + (wifi_tx_dynamic_buf_num * wifi_tx_pkt_size_max)

Как правило можно не заботится о динамических буферах под пакеты кадров управления, потому что они оказывают незначительное влияние на систему.

[Как повысить производительность Wi-Fi]

На производительность ESP32-C3 Wi-Fi влияет множество параметров, и между каждым из параметров существуют взаимозависимые ограничения. Правильно подобранная конфигурация может не только улучшить производительность, то также повысить количество доступной памяти для приложений и улучшить стабильность работы.

В этой секции мы кратко рассмотрим рабочий режим стека протоколов Wi-Fi/LWIP и объясним роль каждого параметра. Будут даны примеры нескольких рекомендуемых рангов конфигураций, пользователь может выбрать подходящий вариант в соответствии со своим сценарием использования.

Рабочий режим стека протоколов

Рис. 10. Путь прохождения данных ESP32-C3.

Стек протокола ESP32-C3 поделен на 4 слоя: Application (приложение), LWIP (поддержка TCP/IP, UDP, ICMP), Wi-Fi и Hardware (аппаратный уровень).

· Во время приема аппаратура помещает принятый пакет в буфер DMA, и затем передает его в RX-буфер Wi-Fi, после чего в LWIP для обработки соответствующего протокола, и далее на уровень приложения. Буфер Wi-Fi RX и буфер LWIP RX по умолчанию используют одну и ту же память. Другими словами, Wi-Fi по умолчанию передает пакет в LWIP просто по указателю.
· Во время передачи приложение копирует сообщения для отправки в буфер TX слоя LWIP для инкапсуляции TCP/IP. Сообщения затем будут переданы в буфер TX слоя Wi-Fi для MAC-инкапсуляции и ожидания передачи.

Параметры. Увеличение размера или количества упомянутых выше буферов может улучшить производительность Wi-Fi. Между тем это уменьшит количество доступной памяти для приложения. Ниже дано введение параметры, которые нужно сконфигурировать пользователям:

В направлении RX:

CONFIG_ESP32_WIFI_STATIC_RX_BUFFER_NUM Этот параметр показывает количество буферов DMA на слое аппаратуры. Увеличение этого параметра повысит пропускную способность одновременного приема, повышая тем самым для стека протокола Wi-Fi возможность обработать плотный трафик.

CONFIG_ESP32_WIFI_DYNAMIC_RX_BUFFER_NUM Этот параметр показывает количество буферов RX на слое Wi-Fi. Увеличение этого параметра повысит производительность приема пакета. Этот параметр должен соответствовать размеру буфера RX слоя LWIP.

CONFIG_ESP32_WIFI_RX_BA_WIN Этот параметр показывает размер окна AMPDU (AMPDU BA Window) на стороне приема. Этот параметр должен конфигурироваться в меньшее из значений 2 * CONFIG_ESP32_WIFI_STATIC_RX_BUFFER_NUM и CONFIG_ESP32_WIFI_DYNAMIC_RX_BUFFER_NUM.

CONFIG_LWIP_TCP_WND_DEFAULT Этот параметр представляет размер буфера RX слоя LWIP для каждого потока TCP. Это значение должно быть сконфигурировано в WIFI_DYNAMIC_RX_BUFFER_NUM(KB), чтобы достичь высокой и стабильной производительности. Тем не менее, в случае нескольких потоков это значение должно быть пропорционально уменьшено.

В направлении TX:

CONFIG_ESP32_WIFI_STATIC_TX_BUFFER_NUM Этот параметр показывает тип буфера TX. Рекомендуется сконфигурировать его в качестве динамического буфера, что позволит в полной мере использользовать память.

CONFIG_ESP32_WIFI_DYNAMIC_TX_BUFFER_NUM Этот параметр показывает количество буферов TX на слое Wi-Fi. Увеличение этого параметра улучшит производительность отправки пакета. Этот параметр должен соответствовать размеру буфера TX слоя LWIP.

CONFIG_LWIP_TCP_SND_BUF_DEFAULT Этот параметр представляет размер буфера TX слоя LWIP для каждого потока TCP. Это значение должно быть сконфигурировано в WIFI_DYNAMIC_TX_BUFFER_NUM(KB) для достижения высокой и стабильной производительности. В случае нескольких потоков это значение должно быть пропорционально уменьшено.

Замечание: для оптимизации производительности поместите код в в IRAM. Упомянутый выше буфер имеет фиксированный размер 1.6 KB.

Как конфигурировать параметры. Память ESP32-C3 совместно используется стеком протоколов и приложениями. Здесь у нас есть несколько рангов конфигураций. В большинстве случаев пользователь должен выбрать подходящий ранг для конфигурации параметров в соответствии с тем, сколько памяти занято приложением.

Параметры, не упомянутые в следующей таблице, должны быть установлены в значения по умолчанию.

Таблица 15. Параметры, которые не должны быть установлены в значения по умолчанию.

Примечание: тест был выполнен в одном потоке на модуле с экраном, при использовании роутера ASUS RT-N66U. Одноядерный ESP32-C3 CPU работал на частоте 160 МГц, память SPI flash ESP32-C3 была подключена в режиме QIO на частоте 80 МГц.

Предлагаемые ранги:

Iperf. Ранг ESP32-C3 экстремальной производительности.

Default. Ранг конфигурации по умолчанию ESP32-C3, доступная память и производительность сбалансированы.

Minimum. Это ранг минимальной конфигурации ESP32-C3. Стек протоколов использует только необходимое для работы количество памяти. Этот вариант подходит для сценариев, когда нет особых требований к производительности, и приложению требуется повышенное количество памяти.

[Устранение проблем]

Для этого ознакомьтесь с отдельным документом Espressif Wireshark User Guide [8].

[Словарик]

AC Access Category, категория качества доступа. Термин относится к поддержке QoS для Wi-Fi.

AMPDU Aggregated Mac Protocol Data Unit [12], специальная фича, предназначенная для более экономного использования полосы пропускания канала, что позволяет увеличить пропускную способность (см. также AMSDU).

AMSDU Aggregated MAC Service Data Units [12], специальная фича, предназначенная для более экономного использования полосы пропускания канала, что позволяет увеличить пропускную способность (см. также AMPDU).

AP режим работы драйвера, когда ESP32-C3 работает как точка доступа (Access Point) Wi-Fi.

BB Beacon Broadcaster, блок широковещательного маяка.

BSSID Basic Service Set Identification, MAC-адрес беспроводного сетевого адаптера точки доступа [11].

CSD Cyclic Shift Delay, или задержка с циклическим сдвигом. Применяется в технологии Cyclic Shift Diversity, что означает разнесение с циклическим сдвигом, метод разнесения передачи, определенный в стандарте 802.11n.

CSI Channel State Information, информация о состоянии канала.

dBm децибел-милливатт, единица измерения мощности принимаемого сигнала. 0 dBm соответствует 1 милливатту, а значение в dBm показывает относительное изменение от этого значения в большую или меньшую сторону, по логарифмическому закону. Изменение в 2 раза означает, что надо отнять или прибавить 3 dBm. Примеры мощностей: 125 мВт соответствует 21 dBm, 500 мВт соответствует 27 dBm, 1000 мВт (1 Вт) соответствует 30 dBm.

HT-LTF High Throughput LTF Long Training Field.

LLTF Legacy Long Training Field.

MPDU MAC protocol data unit [12].

NVS Non-Volatile Storage, энергонезависимое хранилище данных.

PBUF Packet BUFfer, буфер для временного хранения данных пакета.

PHY PHYsical, в данном контексте это физический интерфейс (аппаратура) трансивера, который обеспечивает низкоуровневую среду передачи и приема данных.

QoS Quality of Service, маркировка трафика для поддержки передачи данных с определенным приоритетом.

RF Radio Frequency, радиочастота.

RSSI Received Signal Strength Indicator, индикатор уровня принимаемого сигнала. Измеряется в децибел-милливаттах (dBm).

RX радиоприем.

STBC-HT-LTF Space Time Block Code HT-LTF.

Station режим работы драйвера, когда ESP32-C3 работает как станция Wi-Fi.

Station+AP режим работы драйвера, когда ESP32-C3 работает и как станция, и как точка доступа Wi-Fi.

TBTT Target Beacon Transmission Time, целевое время передачи маяка [9].

TX передача по радиоканалу.

WFA Wi-Fi Alliance, торговая группа, продвигающая оборудование IEEE 802.11.

[Ссылки]

1. ESP-IDF Wi-Fi Driver site:espressif.com.
2. ESP-NETIF.
3. Wi-Fi Easy ConnectTM (DPP) site:espressif.com.
4. esp-idf / examples / wifi site:github.com.
5. ESP-IDF Event Loop Library site:espressif.com.
6. Wi-Fi Easy ConnectTM (DPP) site:espressif.com.
7. ESP-IDF WPA2 Enterprise Example site:github.com.
8. Espressif Wireshark User Guide site:espressif.com.
9. Кадр маяка Beacon frame site:wiki5.ru.
10. ESP32: библиотека энергонезависимого хранилища данных.
11. В чем разница между SSID, ESSID, BSSID?
12. AMSDU vs AMPDU: A Brief Tutorial on WiFi Aggregation Support site:arxiv.org.
13. Cyclic Shift Diversity (CSD) site:dot11ap.wordpress.com.
14. lwIP API site:espressif.com.