Message Latency Observations with MQTT and Heltec V3 — Is Firmware Introducing Delay?

[rFronteddu]

Hi all,

I've been running some preliminary experiments using two Heltec V3 boards and both the second-latest and an older version of the Meshtastic firmware (I'll be testing 2.6 next week).

In my setup, I'm polling small messages (~10 characters) from MQTT, routing them through the mesh, and then republishing them to MQTT on the other side. Even with the fastest configuration settings, I'm consistently observing end-to-end delays in the range of 900–3000 ms. These timings match what I see on the LCD screen when the messages are displayed.

To compare, I ran a separate test with a custom barebones "ping-pong" firmware I wrote for the same boards and LoRa settings. In that setup, message round-trip times were consistently subsecond, and I noticed a higher delivery rate overall.

This leads me to wonder:

• Are there known sources of latency introduced by the Meshtastic stack (e.g., encryption, routing logic, task scheduling)?
• Is there anything obvious I might be misconfiguring?

If 2.6 doesn't yield better performance, I'm considering digging into the codebase to deploy a minimal fork that bypasses most of the logic and just sends/receives test messages — though that could be quite time-consuming.

Has anyone else observed or measured similar delays? Any insights or pointers would be much appreciated.

Thanks!
Roberto

[GUVWAF]

Are there known sources of latency introduced by the Meshtastic stack

Yes. Meshtastic adopts CSMA/CA to avoid collisions, which is especially important when multiple nodes try to transmit in a mesh. This will introduce delays. In fact, the closer the two nodes are, the longer their delay is, as nodes with weaker signal quality will rebroadcast first.