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.
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.
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)
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
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 both metrics are measured in a browser using sites such as speedtest.
And this is very visible here, for example with NRF24 having both low latency and low bandwidth, compared to ESP32 which has a high bandwidth but a high latency.
Yes, very interesting – thanks. No mention of wi-sun though, perhaps it’s part of one of the above-mentioned protocols?
Pointless comparison of the incomparable.
Why’s that?
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 to look at it, even through I only send a very few BLE/Wifi packets I have to be listening for them continuously, and if I am not listening they get dropped.
BTW, this is the same reason you can’t build a border router on the C6. You need to use an external C2. By using the external C2 you get a second radio to listen with.
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.