meshtastic
[Feature Request]: Merge HopLimit and HopStart into a Single TTL Variable
Platform
Cross-Platform
Description
Hello, Team,
Currently, the system utilizes 6 bits - 3 for HopLimit and 3 for HopStart - which ultimately serve a similar purpose to TTL (Time to Live). I propose merging these two 6-bit variables into a single variable, and renaming it as TTL, to better reflect its intended purpose, similar to how TTL is used in Ethernet networks.
This change would allow the sender to manage packet lifespan in a more familiar way, as TTL is a well-understood concept in computer systems. Additionally, by using a single variable, we could support a larger range of hop counts—up to 64 hops, improving the system's flexibility and scalability.
I believe this modification would make the system more intuitive and align it with common networking practices. Looking forward to your feedback!
"HopStart" was introduced such that we can determine how many "hops away" a node is. When changing it to a single TTL value that counts down, while you can still configure it, we loose this information. When you let it count up, it's not the transmitter anymore that decides how far it can travel, but the nodes that receive it. And of course changing this will be a breaking change, so it cannot be done easily.
When changing it to a single TTL value that counts down, while you can still configure it, we loose this information
That's is true but not exact.
- When using the default settings, the original value can be determined. Only a single bit is required to signal that a node is using the default settings. This approach is advantageous, as it provides a method for conveying a significant amount of information, which can be valuable in the context of network analysis.
- Introducing hop limitations at the low level by design results in the creation of additional scenarios where developers may circumvent these limitations by utilizing unpredictable and poorly monitored features.
Using only one bit to denote whether the default is used would still lead to an unknown amount of hops in many cases.
I agree maybe a higher hop limit can be considered for Meshtastic 3.0, but in any case it will be a breaking change. If then we have another way to determine the hops used, we could indeed get rid of "HopStart".
If then we have another way to determine the hops used
Could you please highlight the key considerations for which, or indeed the reasons why, in your view the hop count traversed by a packet should be preserved?
It is used in several places in the firmware now, for example to determine whether we should re-transmit a repeated message (when it comes from the original transmitter): https://github.com/meshtastic/firmware/blob/61e41a8beb3add9a5acd1e7e45701a6f16692075/src/mesh/NextHopRouter.cpp#L67-L68
Furthermore, it's just a very useful metric for network analysis, and it is also used to determine "unknown nodes" (e.g. those that do not have the channel key) in a traceroute.
network analysis
Exporting data to MQTT from multiple locations within the same area can be considered a more powerful option for analysis.
p->hop_start == p->hop_limit;
An additional consideration arises regarding source determination: this can be achieved by comparing packets with the source (SRC) address. However, in the current Meshtastic implementation, information about the immediate sender is unavailable; only the originator is known. This limitation exists because Meshtastic nodes operate as switches rather than routers. Introducing explicit SRC and destination (DST) addresses at the packet level, while representing the physical-layer sender via its MAC address, would address this issue.
With such information available, multicast groups and a simplified IGMP-like mechanism could be implemented. Nodes would advertise the groups (=channels) they wish to join through their node information. Each node would maintain a small in-RAM table of subscribed groups in case a peer announces participation in a non-default channel. If no node subscribes to a given group, the message should not be relayed further unless it is explicitly broadcast."
Exporting data to MQTT from multiple locations within the same area can be considered a more powerful option for analysis.
True, but I think you would agree that this is not always practical or even feasible.
Introducing explicit SRC and destination (DST) addresses at the packet level, while representing the physical-layer sender via its MAC address, would address this issue.
Indeed, I would consider such an addition part of "another way to determine the hops used". But this is also Meshtastic 3.0 material.
The behavior varies by deployment context, which is acceptable. Before continuing the discussion, the following reference is provided to illustrate the broader analytical background motivating this topic: Processing the World — PostGIS Day 2025.
At present, the intended functionality can only be approximated by adding all nodes to the “favorites” list. This approach is operationally viable but suboptimal, which motivates the current discussion.
For analytical purposes, a more appropriate solution is to transmit telemetry on a separate RF channel to a dedicated collector linked to the MQTT backend. This would enable acquisition of metrics such as packet-forwarding counts and other operational parameters characterizing node behavior and local radio conditions.
The feasibility of this approach increases when a controller hosts multiple radio modems. In such a configuration, one modem can maintain primary mesh communications, while an auxiliary modem operates on an alternate frequency to support statistical reporting and out-of-band management. Given current hardware costs - approximately USD $5 for an additional modem and a marginal cost for a secondary antenna - this architecture is technically and economically practical.
At present, I prefer to treat the system’s objectives as distinct domains. The firmware functionality responsible for packet delivery constitutes one domain, while statistical observability - valuable for engineering analysis - constitutes another. Combining these concerns into a single operational path produces an undesirable coupling in which secondary components can interfere with the primary data-delivery objective. A more effective approach is to optimize routing and packet transmission independently, while enabling statistical collection only when required. Such telemetry functions may be selectively enabled or disabled, although this may conflict with other, unspecified stakeholder interests that favor extracting detailed information directly from the network without additional hardware support.
Based on the instability observed during network evaluation, I increasingly conclude that routing and packet-transport mechanisms should be strictly goal-oriented. If the goal is data delivery, the architecture should prioritize transport performance. If the objective is data analysis, that should be addressed as a parallel task that can be integrated where feasible. In practice, MQTT has proven to be the most effective method for analytical data handling. Deploying nodes in locations where analysis is required is generally manageable.
However, the absence of an out-of-band management capability is a significant limitation when the default channel cannot provide sufficient range. A secondary channel - operating at a less congested frequency with configuration parameters optimized for maximum link distance and minimal bandwidth consumption - would provide a robust out-of-band management path.
Taken together, these considerations suggest a clearer architectural model: the node’s primary function is reliable packet delivery, while any analytical or telemetry functions are optional and context-dependent. Several mechanisms are viable: MQTT transmission when Internet access is available; a separate RF channel dedicated to telemetry and diagnostics; or opportunistic transmission of statistical data within unused timeslots on the primary channel, where spectrum utilization permits deferred reporting.
Regarding channel utilization, the attached graph illustrates that the default channel often lacks sufficient available timeslots for statistical data. This highlights the need to focus on traffic-flow organization to achieve more efficient channel utilization. (another topic).
Consider the volume of traffic generated solely due to unsuccessful packet delivery resulting from collisions or hop-count limitations. Such packets are retransmitted by the sender and then relayed repeatedly by multiple nodes, producing avoidable load on the network. Conversely, if mechanisms are implemented to ensure confirmed delivery and to track delivery status, the system can significantly reduce unnecessary retransmissions and thereby eliminate superfluous traffic that provides no operational value.
To avoid diverging from the primary subject, it is important to reiterate that the original topic concerns hop limits and maximum TTL, as these parameters fundamentally determine whether a packet can be delivered over extended distances without introducing auxiliary workarounds. However, the network ultimately carries heterogeneous traffic classes, each with distinct reliability requirements.
Telemetry data is generally non-critical; occasional loss of intermediate measurements is acceptable and does not affect system integrity. In contrast, certain classes of events—such as door-state sensors or motion detection in high-priority areas—require timely and reliable delivery. Similarly, user-generated messages exhibit stringent expectations: a human sender anticipates that the message will reach the recipient promptly. If no response is observed, the sender may retransmit the message, inadvertently increasing network load. When the user transmits from a handheld device, the system should prioritize such traffic, delivering it with minimal latency and with confirmation mechanisms that reduce user uncertainty. This assumes, of course, that the user does not generate excessive traffic or occupy an unfair proportion of channel capacity.
Ensuring dependable and predictable delivery for user messages increases user confidence in the communication system. Higher confidence contributes to broader adoption, larger node populations, and expanded coverage. As the network scales, the supporting technical architecture must be capable of handling substantially higher traffic volumes. This is particularly relevant in deployments utilizing multiple modems and directional antennas for spatial segmentation and increased overall capacity.