ESP-NOW is Espressif's connectionless Wi-Fi protocol for direct device-to-device communication, and its headline feature is low latency: no association, no DHCP, no TCP handshake, just packets fired straight at a peer's MAC address. In practice, real-world latency depends on a stack of details, from callback handling to Wi-Fi coexistence, and remote control systems live or die on those details. This article covers what determines ESP-NOW latency and how to keep it tight.
What ESP-NOW latency actually consists of
A round trip breaks into several stages. The sender's application hands a packet to the ESP-NOW layer, the radio transmits it, the receiver's radio captures it, the receive callback fires, and the application acts. On a quiet bench setup, one-way delivery typically lands in the low single-digit milliseconds. That number grows with packet size, channel congestion, retransmissions, and anything else competing for the radio, including the ESP32's own Bluetooth or a parallel Wi-Fi station connection.
The biggest hidden cost is usually in software, not the radio. A receive callback that does heavy work, writes to flash, or blocks on a mutex can add tens of milliseconds of jitter. Keep callbacks minimal: copy the payload into a queue and return immediately, letting a task do the real processing. Latency you can measure and latency your application feels are different things, and the callback is where they diverge.
Keeping the radio path clean
ESP-NOW rides on Wi-Fi hardware, so it shares the radio's fate. Pin both devices to the same Wi-Fi channel explicitly; channel scanning or auto-selection introduces delays and dropouts. Keep packets small, well under the protocol's maximum payload, since airtime scales with size and small packets also survive interference better. Send at the lowest data rate that meets your range needs only if range is the priority; higher rates mean shorter airtime and lower latency, at the cost of range.
Avoid running a Wi-Fi station connection and ESP-NOW simultaneously on the same radio unless you must. The radio time-slices between the two, and station traffic, especially DHCP renewals and background scans, injects latency spikes into ESP-NOW delivery. If the remote node needs internet access, consider a gateway architecture: ESP-NOW between field nodes and one gateway that handles the Wi-Fi uplink, so the time-critical links stay clean.
Acknowledgment and retry behavior
ESP-NOW supports delivery callbacks that confirm a packet reached the peer's radio. Use them, but understand their limits: an acknowledgment means the radio received the packet, not that the application processed it. For control systems, design the protocol so that state is idempotent, meaning repeated or reordered packets produce the same result, rather than relying on perfect delivery.
Retries need a policy. Blindly retransmitting on every missed acknowledgment can flood a congested channel and make latency worse for everyone. A common robust pattern is: send state updates at a fixed rate regardless of acknowledgments, so a lost packet is simply superseded by the next one, and reserve acknowledged retries for rare critical commands. This keeps the channel quiet and bounds the worst-case staleness of the receiver's state.
Measuring what you actually get
Do not guess at latency; measure it. Timestamp packets with the sender's microsecond clock, echo them back, and compute round-trip times over a few thousand packets in the real deployment environment, not just on the bench. Plot the distribution, not just the average: remote control cares about the tail, the 99th percentile spikes that make a robot lurch or a relay chatter.
Test under load and interference. Run the system with the microwave on, with other Wi-Fi networks active, and at the actual installation distance with the actual antennas. Latency measured in an empty room tells you the floor; latency measured in the deployment tells you whether the system works.
Designing the control loop around the latency
Every remote control system should be designed for its measured latency, not for zero latency. That means the receiver must fail safe: if packets stop arriving for longer than a timeout, the remote system should stop motors, hold last-known-safe state, or shut down, never continue blindly on stale commands. The timeout should be a small multiple of the normal update interval, tuned from measured data.
Prefer sending absolute state over incremental commands. A packet that says "throttle is at 40 percent" is self-healing; a packet that says "increase throttle by 5" corrupts state if one packet is lost. Combine absolute-state updates, a fixed send rate, receive timeouts with safe defaults, and minimal callbacks, and ESP-NOW delivers the responsive, robust link it promises.
ESP-NOW's low latency is real but not automatic. Pin the channel, keep packets small and callbacks lean, separate it from Wi-Fi station traffic, measure the tail latency in situ, and design the protocol for loss. Do that and you get a remote control link that feels instantaneous and degrades gracefully instead of failing mysteriously.
Related Guides
- Packet Serialization Rates in ESP-NOW Long Range: ESP-NOW's long-range mode trades speed for reach, and that trade shows up directly in how fast you can serialize and send packets. A remote control
- Heartbeat Failsafe Timing for ESP-NOW Controllers: ESP-NOW makes ESP32 boards talk to each other directly, fast, and without a router, which makes it ideal for remote control: a handheld controller
- FreeRTOS Task Pinning for Low Latency ESP32 RC: An ESP32 remote-control link lives or dies on latency: the delay between moving the stick and the servo responding. The ESP32 has two CPU cores, but
- Antenna Diversity Switching on ESP32 Drone Nodes: A drone's radio link is its lifeline, and antenna orientation is the link's weakest variable: as the aircraft banks, pitches, and yaws, the antenna's