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.

Packet Capture of ESP-NOW data being sent and the resulting acknowledgement packets

Code was written to test the effects of the following parameters on the throughput of ESP-NOW:

1. Wi-Fi Data Rate
2. Broadcast or Unicast:
   1. Sending packets directly to a peer identified by their MAC address results in the peer sending an Acknowledgement packet back
   2. 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):

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.

Examining Requirements

At our meeting with Prof Benoit today for possible applications of our project, it was suggested that we look into infra-sound and pressure sensors.

While these are interesting sensors, their sampling rate requirements of 80Hz or more are problematic.

Initially, we envisioned applications like monitoring of temperature, sampling once every minute at most. Assuming 12 bits per sample, over one week, this works out to 7 days * 24 hours * 60 minutes * 12 = 118kbit~ of data collected. With the SX1262 supporting LoRa speeds of up to 62.5kbit/s, this is easily transferred within a few seconds.

However, sampling (even just one) sensor at 80Hz is almost two orders of magnitude larger than what we planned for!

If we were to consider even just 12 bits per sample again (a higher resolution is likely necessary for audio/pressure), we are looking at 7 days * 24 hours * 3600 seconds * 80 * 12 = 553Mbit~ of data.

Transferring 553Mbit of data at 62.5kbit/s will take over 9000s of continuous transmission. When considering that we could be receiving data from multiple sensors at the same time, together with how far a LoRa signal reaches (and duty cycle limits we should respect), its clear that our existing design cannot scale to this level. We have not even considered protocol overheads for ensuring data integrity.

Alternatives

The next easily accessible protocol that comes to mind is Wi-Fi. We take a close look at the ESP32, a microcontroller from Espressif Systems that comes with a 2.4GHz radio. We have a quite a few options here:

Wi-Fi

Espressif’s documentation claims a maximum in-air throughput of 30Mbit/s over UDP. However, these are lab conditions and real-world performance will likely be lower. We also have to consider the overheads of joining a network.

Raw Packets/ESP-NOW

The ESP32 supports transmitting raw 802.11 packets, which can lead to some interesting possibilities like receiving packets over a distance of kilometres. Our application is slightly different – we cannot carry such a large antenna on a UAV, we don’t need 10km of range, but we do need a higher data transfer rate than what was achieved in the video.

ESP-NOW has been empirically tested to achieve rates of up to 460kb/s, but is assumed to be using the default Wi-Fi bit rate of 1Mbit/s. The bit rate is configurable.

Moving Forward

It is quite clear that LoRa will not support such high data transfer rates. Alternatives like Wi-Fi on a ESP2 will support much higher data transfer rates in theory, but we will still need to benchmark the different options and evaluate whether the theoretical performance is achievable in our setup.