After realising the need for faster data transfer, we started looking at the ESP32 and the various protocols it supports. Although using layer 4 protocols like TCP or UDP is possible, the overheads of handling connections to an ad-hoc network could be problematic. We thus examined ESP-NOW, a protocol defined by Espressif which sends data over raw 802.11 packets directly without the need for devices to be on the same WLAN network.
Code was written to test the effects of the following parameters on the throughput of ESP-NOW:
- Wi-Fi Data Rate
- Broadcast or Unicast:
- Sending packets directly to a peer identified by their MAC address results in the peer sending an Acknowledgement packet back
- Broadcasting packets (send to MAC FF:FF:FF:FF:FF:FF) will not cause Acknowledgement packets to be sent, potentially speeding up transfer.
The test code transmits 250 byte (maximum supported packet length) ESP-NOW packets as fast as possible from a device (henceforth the master) to another device (henceforth the slave) for 3 seconds, sleeps for 10 seconds, then repeats.
The slave device then transmits the number of packets received at 1 second intervals back to the master device, which then prints out this number.
The following data rates have been observed between two ESP32-DevKitC’s approximately 1m apart in a standard household environment (ie with Wi-Fi interference):
Transmission Type | Wi-Fi Data Rate | Max Throughput Observed (bytes) in 1s |
---|---|---|
Unicast | WIFI_PHY_RATE_1M_L |
89250 |
Broadcast | WIFI_PHY_RATE_1M_L |
101000 |
Unicast | WIFI_PHY_RATE_11M_L |
349250 |
Broadcast | WIFI_PHY_RATE_11M_L |
497000 |
Unicast | WIFI_PHY_RATE_54M |
778500 |
Broadcast | WIFI_PHY_RATE_54M |
963000 |
Unicast | WIFI_PHY_RATE_MCS0_LGI |
442000 |
Broadcast | WIFI_PHY_RATE_MCS0_LGI |
502250 |
Unicast | WIFI_PHY_RATE_MCS4_LGI |
756750 |
Broadcast | WIFI_PHY_RATE_MCS4_LGI |
930750 |
Unicast | WIFI_PHY_RATE_MCS7_LGI |
224750 |
Broadcast | WIFI_PHY_RATE_MCS7_LGI |
706250 |
Unicast | WIFI_PHY_RATE_MCS0_SGI |
464750 |
Broadcast | WIFI_PHY_RATE_MCS0_SGI |
535000 |
Unicast | WIFI_PHY_RATE_MCS4_SGI |
771750 |
Broadcast | WIFI_PHY_RATE_MCS4_SGI |
945250 |
Unicast | WIFI_PHY_RATE_MCS7_SGI |
734250 |
Broadcast | WIFI_PHY_RATE_MCS7_SGI |
833500 |
We can observe that sending broadcast instead of unicast packets speeds up data transmissions slightly. Increasing the Wi-Fi bit rate also has a significant impact on data rates, but comes at the cost of significantly more packet loss (packets not acknowledged by peer).
Quick testing in outdoor conditions (ESP32-DevKitC placed at a distance of 20m with line-of-sight visibility) shows similar (or slight better) data rates at WIFI_PHY_RATE_1M_L
and WIFI_PHY_RATE_11M_L
when compared to the results above. Data rates of up to 549250 bytes/s were observed at WIFI_PHY_RATE_24M
. Almost all packets were lost at WIFI_PHY_RATE_54M
.
12 bit data sampled at 80Hz results in 553Mbit or 70875 kbyte of data, which would take approximate 145s to transmit at 500000 bytes/s.
These data rates were also observed using the on-board PCB antenna. An alternative option is to connect an external antenna to ESP32-WROOM-32U modules, which is likely to improve the data rate.
Hi
I have been trying to use your code examples for the esp now protocol.
But I’m having issues not being able to send packages fast enough.
with a package size of only 2 bytes i need a delay in the loop at minimum 35ms to make every package transmission successful. in other words. 28 packages per second. It doesn’t seem like a lot to me, and it’s a bottleneck for my projekt.
I see on your website that you have made a test of the data rate of the espnow.
Is it possible that you can release the code used to create the data rates specified on your website? it would really mean a lot to me. Thanks
link to your website with the espnow article.
Best regards
Max Bursell
Hi,
The code used can be found here: https://github.com/PS9888-2020-Sensors/esp-speed-benchmarks
Do note that the use of a uint16 to track number of packets in transmission is a bad idea – we have observed in later work that there is a potential race condition here. Using a semaphore is a better solution to track this.
Hi Justin, what software did you use to capture ESP-NOW packets?
Thanks
regards,
Enas
Hi, I used Wireshark + an external USB WiFi adapter. Essentially, some setup capable of capturing WiFi packets should be able to capture ESP-NOW traffic too.