ESP32-Based Wireless Communication Link Latency Test Results

English | 中文

By RichJ233

The tested solutions include:

• ESP32-S3 UART ↔ Wi-Fi UDP
• ESP32-S3 ↔ ESP32-C3 ESP-NOW
• ESP32-S3 native USB local loopback
• Dual ESP32-S3 ESP-NOW
• A pair of nRF24-like wireless UART transparent-transmission modules

Hardware

Experiments

1. ESP32-S3 UART ↔ Wi-Fi (UDP) ↔ PC

Test Path

Serial device/PC
→ UART
→ ESP32-S3
→ Wi-Fi UDP
→ PC

Configuration:

• UART RX: GPIO18
• UART TX: GPIO17
• UART baud rate: 115200
• UDP port: 2333
• PC Wi-Fi IP: 192.168.0.233
• ESP32 IP: 192.168.0.2
• PC serial port: COM4
• Wi-Fi router: TP-Link 5626
• Data sent: 32 bytes

Results

Bidirectional transparent transmission worked reliably, with a latency of approximately 29 ms. The reverse UDP→ESP32-S3→UART path produced a similar result.

2. ESP32-S3 ↔ ESP32-C3 ESP-NOW One-Way Test

Test Method

The program alternated between the two directions:

S3 → C3
C3 → S3

• ESP-NOW channel: 6
• Wi-Fi power saving disabled
• The two directions were not transmitted continuously at the same time.

Results

• S3→C3: typically about 3.3–3.5 ms
• C3→S3: typically about 3.1–7 ms
• TIMEOUT events occurred during the test

S3↔C3 ESP-NOW stop-and-wait RTT:

3. ESP32-S3 ↔ ESP32-C3 Bidirectional Communication Test

Test Path

→ C3 UART
→ ESP-NOW
→ S3 native USB
→ PC
→ S3 native USB
→ ESP-NOW
→ C3 UART

All later tests used fixed 32-byte binary frames containing a frame type, sequence number, and CRC16.

100 Hz Results

The target period was 10 ms, with 1000 measured samples.

Comparison of 50, 75, and 100 Hz Results

The 75 Hz test produced many ESP_ERR_ESPNOW_NO_MEM, pending overwrite, and retry events. The results may be affected by the ESP-NOW queue and transmission state.

Active + Latest Test

When newer data arrives, the old waiting packet is replaced to prevent stale data from continuously accumulating.

One submitted active packet
+
One waiting latest packet

Results at 100 Hz with 2000 samples:

The board-side submit count matched the peer-side radio receive count.

4. ESP32-S3 Native USB Local Loopback Latency Test

Test Path

→ PC
→ S3 native USB
→ Echo
→ S3 native USB
→ PC

Results

5. Dual ESP32-S3 ESP-NOW RTT Test

Test Path

→ S3-A firmware
→ ESP-NOW PING
→ S3-B firmware
→ ESP-NOW PONG
→ S3-A firmware

Timing was measured on the boards using esp_timer_get_time and excludes Windows, Python, and USB.

Results

Board-side statistics:

• A: 2100 transmissions, 0 timeouts, 0 send errors
• B: 2100 receptions, 2100 replies, 0 send errors

6. Dual-S3 Host-Triggered RTT Test

Test Path

→ Python
→ USB
→ S3-A
→ ESP-NOW
→ S3-B
→ ESP-NOW
→ S3-A
→ USB
→ Python

Results

7. Dual-S3 Single-USB Stop-and-Wait Test

Test Path

→ Python
→ USB A
→ S3-A
→ ESP-NOW
→ S3-B
→ ESP-NOW
→ S3-A
→ USB A
→ Python

S3-B's USB connection was not included in the timed path.

Only one transaction was allowed in flight at a time. The test recorded the complete host RTT, internal ESP-NOW RTT, and host+USB overhead.

Results

The board-side statistics for both tests recorded 3100 complete wireless round trips:

• A submitted 3100 packets and B received 3100 packets
• B replied 3100 times and A received 3100 replies
• No radio queue drops
• No NO_MEM events
• No callback failures
• No loop timeouts
• Python recorded 589 and 547 host timeouts

8. Dual-S3 Asynchronous Bidirectional Communication Test

Test Method

• State data was transmitted continuously at 100 Hz without waiting for the previous command to return
• Python used two independent reader threads to continuously read both USB ports
• A command was calculated and sent immediately after receiving state data
• The controller processed only the latest state in each received batch

Results

9. nRF24-Like Wireless UART Transparent Module: 12-Byte Sequential Round Trip

Serial Configuration and Frame Format

• 115200 baud
• 8 data bits
• No parity
• 1 stop bit
• 12-byte frame

A5 5A | uint32 sequence | PING | CRC16-CCITT

Test Path and Timing

The same PC was connected to two USB serial ports:

t0: PC writes to serial A
→ Module A
→ Wireless link
→ Module B
t1: PC receives the complete frame from serial B

t2: PC writes the validated frame back to serial B
→ Module B
→ Wireless link
→ Module A
t3: PC receives the returned frame from serial A

Calculations:

• A→B visible latency = t1 - t0
• PC forwarding = t2 - t1
• B→A visible latency = t3 - t2
• Full RTT = t3 - t0

Results

Sample statistics:

• Planned: 3000
• Valid: 2973
• Failed: 27
• Success rate: 99.100%

For 12-byte data at 115200 8N1, the theoretical total transmission time across four UART legs is approximately 4.167 ms.

10. nRF24-Like Wireless UART Transparent Module: Simultaneous Bidirectional Transmission

Test Method

Two Python workers used threading.Barrier to start as close to simultaneously as possible:

Serial A sends frame A while serial B sends frame B
Both endpoints wait for data from the opposite side

Each frame was 12 bytes and contained a header, source, sequence number, payload, and CRC.

Results

Many communication failures occurred. No stable latency statistics or accurate failure rate were produced.

This result alone does not prove that the product is half-duplex by specification. It may also be caused by simultaneous-transmission collisions, contention, or a radio that cannot transmit and receive at the same time. However, the link is not suitable for designs that rely on simultaneous bidirectional transmission.

11. nRF24-Like Wireless UART Transparent Module: 10-Byte Python Echo RTT

Configuration

• Main port: COM9
• Echo port: COM10
• 115200 8N1
• 10-byte packet
• Warm-up: 50
• Formal measurements: 1000
• Send interval: 20 ms
• Packet timeout: 100 ms

Frame format:

AA 55 | uint32 sequence | uint16 data | CRC16-MODBUS

Test Path

Python main thread
→ COM9
→ Module A
→ Wireless link
→ Module B
→ COM10
→ Python echo thread writes the same data back to COM10
→ Module B
→ Wireless link
→ Module A
→ COM9
→ Python main thread

Results

The actual test frequency was approximately 24.2 Hz.

Results Comparison