Although factors like bandwidth, power usage, and the number of (kilo)meters reach are important considerations with wireless communication for microcontrollers, latency should be another important factor to pay attention to. This is especially true for projects like controllers where round-trip latency and instant response to an input are essential, but where do you find the latency number in datasheets? This is where [Michael Orenstein] and [Scott] over at Electric UI found a lack of data, especially when taking software stacks into account. In other words, it was time to do some serious benchmarking.
The question to be answered here was specifically how fast a one-way wireless user interaction can be across three levels of payload sizes (12, 128, and 1024 bytes). The effective latency is measured from when the input is provided on the transmitter, and the receiver has processed it and triggered the relevant output pin. The internal latency was also measured by having a range of framework implementations respond to an external interrupt and drive a GPIO pin high. Even this test on an STM32F429 MCU already showed that, for example, the STM32 low-level (LL) framework is much faster than the stm32duino one.
After a bit more checking for overhead within the MCU itself with various approaches, the actual tests were performed. The tests involved modules for SiK, LoRa, nRF24, Bluetooth SPP (ESP32, HC-5), Bluetooth LE (Bluedroid & NimBLE on ESP32, as well as the nRF52), ESP-NOW (ESP32), 802.15.4 (used by Zigbee, Matter, Thread, etc.) and of course WiFi. The software stack used had a big impact on some of these, such as for BLE, but WiFi differed a lot on the ESP32, whether using TCP or overlaying Websockets (about 10x slower).
Support the originator by clicking the read the rest link below.
