Comparing the latency of various wireless standards

If you’ve ever wondered which wireless standard may deliver the smallest lag (latency) when transmitting small packets, we’ve now gotten an answer thanks to Scott at Electric UI who benchmarked various wireless links in common MCU development boards.

More specifically the following hardware and wireless standards were tested:

  • SiliconLabs 10×0-GM RF+8051 microcontroller with 240–960 MHz EZRadioPRO transceiver running SiK firmware
  • HopeRF RFM95W LoRa module (on an Adafruit Breakout board) connected to an STM32F429 MCU
  • Nordic Semi nRF24L01 2.4GHz transceiver module
  • ESP32 board for ESP-NOW and WiFi testing is shown as ESP32 WS (WebSockets) or ESP32 TCP in the chart below. Raspberry Pi boards were also used for comparison
  • ESP32-C6 board for 802.15.4 transfers (Thread)
  • ESP32 and HC-05 modules for Bluetooth SPP (Serial Port Profile)
  • ESP32 board with NimBLE and Bluedroid stacks and nRF52 for Bluetooth LE testing

Here are the results for 12 bytes, 128 bytes, and 1024 bytes data transfers.

Wireless Latency
Source: Electric UI

nRF24 offers the lowest lag for 12-byte and 128-byte payloads with only 0.26 ms (rounded up to 300 microseconds in the main body of the article?) and 1.9 ms. That’s another story with the larger 1024-byte payload since nRF24 breaks it into multiple 32-byte packets, and instead, ESP32 TCP (WiFi) gets the upper hand here. Unsurprisingly, LoRa and SIK have really long latencies since those protocols are optimized for long-range low-power connectivity rather than fast transfers. We also learned that the Bluedroid stack has a lower latency than NimBLE on ESP32.

ESP32 Protocol Latency Comparison
Distribution of results on ESP32. Source: Electric UI

It’s quite tricky to measure latency between different wireless platforms since many factors have to be taken into account. For example, bare metal code will be faster than an Arduino sketch, and compilation flags may also impact performance with, for instance, the -Os flag (optimization for size) delivering better results than the -O3 flag (optimization for speed). The method to measure the lag and validate the results needs to be carefully selected and Scott goes over all those in great detail in his blog post (that’s a long read).

Via Hackaday (and somewhere on LinkedIn)

Share this:

Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress

ROCK Pi 4C Plus
Notify of
The comment form collects your name, email and content to allow us keep track of the comments placed on the website. Please read and accept our website Terms and Privacy Policy to post a comment.
2 months ago

That’s super interesting, thanks! Actually the term “latency” is misused here, it’s in fact transfer time, because latency is what is mostly incompressible and does not depend on bandwidth. That’s typically the transfer time of tiny objects (such as the 12B one here) since the total transfer time is essentially made of protocol exchanges and speed of light. The transfer time of larger objects is instead dominated by the link bandwidth and aims at amortizing latency. In short, latency is what you measure with ping while bandwidth is what you’d measure with wget on a large object for example. Or… Read more »

2 months ago

Yes, very interesting – thanks. No mention of wi-sun though, perhaps it’s part of one of the above-mentioned protocols?

2 months ago

Pointless comparison of the incomparable.

Upgrade pi-top [3]
Upgrade pi-top [3]
2 months ago

Why’s that?

Jon Smirl
2 months ago

An interesting addendum would be to measure the impact of shared multi-protocol radios. For example BLE and Wifi share the same radio on the ESP (and many other chips). I have recently been bitten by not clearly understanding the issues behind shared radios. Simply put it, if the radio is listening for a Wifi packet then it is not listening for a BLE one and vice versa. This results in a lot of dropped packets. My mistake was in thinking that since I hardly use Wifi and BLE this would not be a a problem. That is the wrong way… Read more »

Ray Knight
Ray Knight
1 month ago

Thanks Jon! That is something I had not thought about. Based on that analysis if both Bluetooth and WiFi are important to your application you should be considering separate radios for each protocol.

Khadas VIM4 SBC