fix(wifi-remote): Replace WiFi -> Wi-Fi

david-cermak · david-cermak · commit 091bc69e9927 · 2025-09-04T14:18:18.000+02:00
diff --git a/content/blog/2025/09/esp-wifi-remote/index.md b/content/blog/2025/09/esp-wifi-remote/index.md
@@ -1,5 +1,5 @@
 ---
-title: "Transparent WiFi connectivity for non-WiFi ESP32 chips"
+title: "Transparent Wi-Fi connectivity for non-Wi-Fi ESP32 chips"
 date: 2025-09-05
 showAuthor: false
 summary: "This blog post introduces the `esp-wifi-remote` component, which extends Wi-Fi functionality to ESP32 chips that lack native Wi-Fi support. We will explore the `esp-wifi-remote` ecosystem, its components, architecture, and integration with `esp-hosted`."
@@ -15,61 +15,61 @@ Also, `esp-wifi-remote` can be used with Wi-Fi-enabled ESP32 chips to create an
 ### Terminology
 
 Before diving into the details, let's establish the key terminology used throughout this post:
-- **Backend Solution**: The communication layer that handles the transport of WiFi commands, events, and data between host and slave devices. Examples include [esp-hosted](https://github.com/espressif/esp-hosted-mcu), [eppp](https://github.com/espressif/esp-wifi-remote/tree/main/components/wifi_remote_over_eppp), and [AT-based](https://github.com/espressif/esp-wifi-remote/tree/main/components/wifi_remote_over_at) implementations.
-- **Host-side**: The device running your application code (e.g., ESP32-P4, ESP32-H2, or ESP32 with WiFi).
-- **Slave-side**: The WiFi-capable device that provides the actual WiFi hardware and functionality.
+- **Backend Solution**: The communication layer that handles the transport of Wi-Fi commands, events, and data between host and slave devices. Examples include [esp-hosted](https://github.com/espressif/esp-hosted-mcu), [eppp](https://github.com/espressif/esp-wifi-remote/tree/main/components/wifi_remote_over_eppp), and [AT-based](https://github.com/espressif/esp-wifi-remote/tree/main/components/wifi_remote_over_at) implementations.
+- **Host-side**: The device running your application code (e.g., ESP32-P4, ESP32-H2, or ESP32 with Wi-Fi).
+- **Slave-side**: The Wi-Fi-capable device that provides the actual Wi-Fi hardware and functionality.
 
-## Understanding the WiFi Experience
+## Understanding the Wi-Fi Experience
 
-Let's examine the traditional WiFi experience, then see how esp-wifi-remote enables the same experience with external WiFi hardware:
+Let's examine the traditional Wi-Fi experience, then see how esp-wifi-remote enables the same experience with external Wi-Fi hardware:
 
-### Traditional WiFi scenario
+### Traditional Wi-Fi scenario
 
-- Users call `esp_wifi_...()` API to control the local WiFi
+- Users call `esp_wifi_...()` API to control the local Wi-Fi
   {{< figure
       default=true
       src="wifi_experience_1.webp"
       >}}
 
-### `esp-wifi-remote` with non WiFi Chips
+### `esp-wifi-remote` with non Wi-Fi Chips
 
-- Users call `esp_wifi_...()` API to control the remote WiFi
+- Users call `esp_wifi_...()` API to control the remote Wi-Fi
   {{< figure
       default=true
       src="wifi_experience_2A.webp"
       >}}
 
-### `esp-wifi-remote` with WiFi-capable Chips
+### `esp-wifi-remote` with Wi-Fi-capable Chips
 
-- Users call `esp_wifi_...()` API to control the local WiFi
-- Users call `esp_wifi_remote_...()` API to control the remote WiFi
+- Users call `esp_wifi_...()` API to control the local Wi-Fi
+- Users call `esp_wifi_remote_...()` API to control the remote Wi-Fi
   {{< figure
       default=true
       src="wifi_experience_2B.webp"
       >}}
 
-This dual WiFi scenario is useful for applications that need multiple wireless connections. It is also useful for initial exploring of `esp-wifi-remote` functionality with just two "common" ESP32 chips. For basic setup, you only need two evaluation boards.
+This dual Wi-Fi scenario is useful for applications that need multiple wireless connections. It is also useful for initial exploring of `esp-wifi-remote` functionality with just two "common" ESP32 chips. For basic setup, you only need two evaluation boards.
 
-## WiFi Remote component breakdown
+## Wi-Fi Remote component breakdown
 
 **esp_wifi_remote** is a thin layer that translates `esp_wifi` API calls into the appropriate implementation. Key aspects:
 * API
-  - Remote WiFi calls: Set of esp_wifi API namespaced with `esp_wifi_remote` prefix
-  - Standard WiFi calls: esp_wifi API directly translates to esp_wifi_remote API for targets with no WiFi.
+  - Remote Wi-Fi calls: Set of esp_wifi API namespaced with `esp_wifi_remote` prefix
+  - Standard Wi-Fi calls: esp_wifi API directly translates to esp_wifi_remote API for targets with no Wi-Fi.
 * Configuration:
-  - Standard WiFi library Kconfig options
+  - Standard Wi-Fi library Kconfig options
   - Selection of the backend solution
 
-### WiFi configuration
+### Wi-Fi configuration
 
-You can configure remote WiFi the same way as local WiFi. Kconfig options are structured identically but located under ESP WiFi Remote component.
+You can configure remote Wi-Fi the same way as local Wi-Fi. Kconfig options are structured identically but located under ESP Wi-Fi Remote component.
 
-#### Local vs. Remote WiFi configuration
+#### Local vs. Remote Wi-Fi configuration
 
-Kconfig option names are the same, but identifiers are prefixed differently to differentiate between local and remote WiFi.
+Kconfig option names are the same, but identifiers are prefixed differently to differentiate between local and remote Wi-Fi.
 
 > 💡 Adapt options from sdkconfig
-> If you're migrating your project from a WiFi enabled device and used specific configuration options, please make sure the remote config options are prefixed with `WIFI_RMT_` instead of `ESP_WIFI_`, for example:
+> If you're migrating your project from a Wi-Fi enabled device and used specific configuration options, please make sure the remote config options are prefixed with `WIFI_RMT_` instead of `ESP_WIFI_`, for example:
 
 ```
 CONFIG_ESP_WIFI_TX_BA_WIN -> CONFIG_WIFI_RMT_TX_BA_WIN
@@ -78,7 +78,7 @@ CONFIG_ESP_WIFI_AMPDU_RX_ENABLED -> CONFIG_WIFI_RMT_AMPDU_RX_ENABLED
 ```
 
 > ⚠️
-> All WiFi remote configuration options are available, but some of them are not directly related to the **host side** configuration and since these are compile time options, wifi-remote cannot automatically reconfigure the **slave side** in runtime.
+> All Wi-Fi remote configuration options are available, but some of them are not directly related to the **host side** configuration and since these are compile time options, wifi-remote cannot automatically reconfigure the **slave side** in runtime.
 > It is important to configure the options on the slave side manually and rebuild the slave application.
 > Make sure that the **host side** configuration corresponds to the **slave side**, e.g. `CONFIG_WIFI_RMT_TX_BA_WIN` on the host side is equal to the `CONFIG_ESP_WIFI_TX_BA_WIN` on the slave side.
 
@@ -94,10 +94,10 @@ Here are the reasons you might prefer some other implementation than `esp_hosted
 * Your slave (or host) device is not an ESP32 target and you want to use some standard protocol:
   - choose `eppp`: it uses PPPoS protocol and works seamlessly with `pppd` on linux.
   - choose `at`: it uses standard AT commands and integrates nicely with `esp-at` as a slave device.
-* You prefer encrypted communication between host and slave device, especially when passing WiFi credentials.
+* You prefer encrypted communication between host and slave device, especially when passing Wi-Fi credentials.
 * You might need some customization on the slave side.
 
-To choose the backend solution, go to the WiFi Remote component configuration menu and select the preferred one by:
+To choose the backend solution, go to the Wi-Fi Remote component configuration menu and select the preferred one by:
 
 ```
 $ idf.py menuconfig
@@ -116,27 +116,27 @@ idf.py add-dependency "espressif/wifi_remote_over_at"
 
 #### Comparison of backend solution components
 
-This section compares backend solutions, focusing on how different methods marshall (i.e., encode and transmit) WiFi commands, events and data to the slave device.
+This section compares backend solutions, focusing on how different methods marshall (i.e., encode and transmit) Wi-Fi commands, events and data to the slave device.
 
 **Principle of operation**
 
 
-**`esp-hosted`** uses a plain text channel to send and receive WiFi API calls and events. It uses other plain text channels for data packets (WiFi station, soft-AP, BT/BLE). The TCP/IP stack runs only on the host side and esp-hosted passes Ethernet frames (802.3) from host to slave, where they are queue directly to the WiFi library.
+**`esp-hosted`** uses a plain text channel to send and receive Wi-Fi API calls and events. It uses other plain text channels for data packets (Wi-Fi station, soft-AP, BT/BLE). The TCP/IP stack runs only on the host side and esp-hosted passes Ethernet frames (802.3) from host to slave, where they are queue directly to the Wi-Fi library.
 
 {{< figure
     default=true
     src="hosted.webp"
     >}}
 
-**`wifi_remote_over_eppp`** creates a point to point link between host and slave device, so each side have their IP addresses. WiFi API calls and events are transmitted using SSL/TLS connection with mutual authentication. The data path uses plain text peer to peer connection by means of IP packets. Both host and slave device run TCP/IP stack. The slave device runs network address translation (NAT) to route the host IP packets to the WiFi network -- this is a limitation, since the host device is behind NAT, so invisible from the outside and the translation has a performance impact (to overcome this, you can enable Ethernet frames via custom channels, so the data are transmitted the same way as for `esp-hosted` method, using 802.3 frames).
+**`wifi_remote_over_eppp`** creates a point to point link between host and slave device, so each side have their IP addresses. Wi-Fi API calls and events are transmitted using SSL/TLS connection with mutual authentication. The data path uses plain text peer to peer connection by means of IP packets. Both host and slave device run TCP/IP stack. The slave device runs network address translation (NAT) to route the host IP packets to the Wi-Fi network -- this is a limitation, since the host device is behind NAT, so invisible from the outside and the translation has a performance impact (to overcome this, you can enable Ethernet frames via custom channels, so the data are transmitted the same way as for `esp-hosted` method, using 802.3 frames).
 
 {{< figure
     default=true
     src="eppp.webp"
     >}}
 
 
-**`wifi_remote_over_at`** uses `esp-at` project as the slave device, so the host side only run standard AT commands. It's implemented internally with `esp_modem` component that handles basic WiFi functionality. Note that not all configuration options provided by *esp-wifi-remote* are supported via AT commands, so this method is largely limited.
+**`wifi_remote_over_at`** uses `esp-at` project as the slave device, so the host side only run standard AT commands. It's implemented internally with `esp_modem` component that handles basic Wi-Fi functionality. Note that not all configuration options provided by *esp-wifi-remote* are supported via AT commands, so this method is largely limited.
 
 {{< figure
     default=true
@@ -154,16 +154,16 @@ The best throughput is achieved with `esp_hosted` implementation.
 | wifi_remote_over_eppp | up to 20Mbps      | [eppp-link](https://github.com/espressif/esp-protocols/blob/master/components/eppp_link/README.md#throughput) |
 | wifi_remote_over_at | up to 2Mbps     | [esp-at](https://github.com/espressif/esp-at) |
 
-### WiFi Remote internals
+### Wi-Fi Remote internals
 
-The `esp-wifi` component interface depends on WiFi hardware capabilities. `esp-wifi-remote` follows these dependencies based on the slave WiFi hardware. Some wireless and system capability flags are replaced internally with `SOC_SLAVE` prefix. Host-side config options are prefixed with `WIFI_RMT` for use in `esp-wifi-remote` headers. See [WiFi remote](https://github.com/espressif/esp-wifi-remote/blob/main/components/esp_wifi_remote/README.md#dependencies-on-esp_wifi) documentation for details.
+The `esp-wifi` component interface depends on Wi-Fi hardware capabilities. `esp-wifi-remote` follows these dependencies based on the slave Wi-Fi hardware. Some wireless and system capability flags are replaced internally with `SOC_SLAVE` prefix. Host-side config options are prefixed with `WIFI_RMT` for use in `esp-wifi-remote` headers. See [Wi-Fi remote](https://github.com/espressif/esp-wifi-remote/blob/main/components/esp_wifi_remote/README.md#dependencies-on-esp_wifi) documentation for details.
 
 > 📝
 > These options and flags are only related to the host side, as `esp-wifi-remote` is a host side layer. For slave side options, please refer to the actual backend solution implementation.
 
 ## Other connectivity options
 
-This blog post focuses on WiFi connectivity solutions, specifically *esp-wifi-remote* only. We are not going to cover other wireless connectivity options like `esp-extconn` or custom implementations, nor do we cover Bluetooth or BLE. Below is a brief overview with references and links for those interested in exploring these alternatives.
+This blog post focuses on Wi-Fi connectivity solutions, specifically *esp-wifi-remote* only. We are not going to cover other wireless connectivity options like `esp-extconn` or custom implementations, nor do we cover Bluetooth or BLE. Below is a brief overview with references and links for those interested in exploring these alternatives.
 
 ### esp-extconn
 
@@ -182,19 +182,19 @@ You can also implement your own Wi-Fi connectivity using these components:
 
 ## Summary
 
-**esp-wifi-remote** bridges the gap between WiFi-enabled and non-WiFi ESP32 chipsets, providing a seamless development experience that maintains API compatibility while extending WiFi functionality to previously WiFi-less devices.
+**esp-wifi-remote** bridges the gap between Wi-Fi-enabled and non-Wi-Fi ESP32 chipsets, providing a seamless development experience that maintains API compatibility while extending Wi-Fi functionality to previously Wi-Fi-less devices.
 
 The below tips emerge from this exploration:
 
 **1. Use `esp-hosted` as your backend solution** -- Provides optimal performance, mature integration, and comprehensive support.
 
 **2. Consider alternative backends** for specific scenarios:
-- If sending WiFi commands between *host* and *slave* unencrypted is not acceptable: Checkout `wifi_remote_over_eppp` backend or [esp-extconn](https://github.com/espressif/esp-extconn/).
+- If sending Wi-Fi commands between *host* and *slave* unencrypted is not acceptable: Checkout `wifi_remote_over_eppp` backend or [esp-extconn](https://github.com/espressif/esp-extconn/).
 - If you need to use some standard communication protocol (e.g. using non-ESP slave): Checkout `wifi_remote_over_eppp` for PPPoS protocol, or `wifi_remote_over_at` for AT commands.
 
-**3. Mind the WiFi slave configuration** -- `esp-wifi-remote` operates as a compile-time configuration system. Developers must manually configure slave-side WiFi options and rebuild the slave application. When migrating from WiFi-enabled devices, configuration options must be prefixed with `WIFI_RMT_` instead of `ESP_WIFI_`.
+**3. Mind the Wi-Fi slave configuration** -- `esp-wifi-remote` operates as a compile-time configuration system. Developers must manually configure slave-side Wi-Fi options and rebuild the slave application. When migrating from Wi-Fi-enabled devices, configuration options must be prefixed with `WIFI_RMT_` instead of `ESP_WIFI_`.
 
-**4. Bootstrap your experience with WiFi chips** -- To get started **without** the actual ESP32-P4, just connect your two *common* ESP chips with three wires and run [the two station](https://github.com/espressif/esp-wifi-remote/tree/main/components/esp_wifi_remote/examples/two_stations) example (using dual WiFi interfaces).
+**4. Bootstrap your experience with Wi-Fi chips** -- To get started **without** the actual ESP32-P4, just connect your two *common* ESP chips with three wires and run [the two station](https://github.com/espressif/esp-wifi-remote/tree/main/components/esp_wifi_remote/examples/two_stations) example (using dual Wi-Fi interfaces).
 
 
 ## References
