I was hoping to read more here about why this limitation exists but the page no longer exists.
When I read LoRa records like this one, I naively imagined that a message could go around the world thanks to a mesh system like Meshtastic.
Obviously with mqtt it’s possible but I think just with LoRa.
But it seems it’s a choice in the algorithm to limit it. If it were just a parameter between 0 and infinity, I’d understand, but why limit it to 7?
If the aim is to avoid transmitting the same packet indefinitely, I’m thinking that we could “easily” integrate a mechanism so that a node to recognize a packet already transmitted. But surely I haven’t understood everything.
In practice I’ve not yet heard that this limit has been a problem. 7 hops doesn’t mean only 7 nodes will rebroadcast, it may be many more depending on which nodes can reach others. If you keep on rebroadcasting even if all nodes already received it, it’s just a waste of channel utilization.
There is already a system in place that prevents rebroadcasting a message twice. However, there needs to be a limit on how long you will check for a certain message ID (FLOOD_EXPIRE_TIME recently got increased to 10 min. because 5 min. was not enough), because they will be reused (there’s only 4 bytes for the ID). Since LoRa is pretty slow, if you allow high hop limits, it might take very long before a message gets circled back. If in the meantime that ID expired, the message will be looped indefinitely.
The image is correct. Nodes that are rebroadcasting don’t know when all nodes are reached and will stop rebroadcasting if the hop limit is 0.
With “there may be many more depending on which nodes can reach others” I meant that the message might also go the other way (e.g. if there are nodes on the left), and the hop limit will be decremented to 0 on that side as well.
I reread the algorithm page (layer 3) and although giving priority to the nodes furthest from the coverage radius avoids using nodes unnecessarily and reduces the hop count, I still don’t see how a message starting from point 0 could reach point 7 in this example whatever direction you take.
If at point 0 max_hop==3, at 2 max_hop==2, at 4 max_hop==1 and at 6 max_hop==0 point 7 will reject it right?
If I understand correctly, unless the max hop is reset at some point for the same packet, this limit imposes a maximum mesh network range given by this formula: r/2 * max_hop
Where r is the range radius and all nodes have the same range.
0 transmits with HL 3 → 2
2 sends with HL 2. → 4
4 sends with HL 1 → 6
6 sends with HL 0 → 7 receives it but will not try to send it.
6 still transmits because the HL is greater than zero when it received the packet.
From the link provided by @GUVWAF second paragraph of section “Layer 3: (Naive) Flooding for Multi-Hop Messaging”
“If any mesh node sees a packet with a HopLimit other than zero, it will decrement that HopLimit and attempt re-transmission on behalf of the original sending node.”
Ok, then I’m short on one step but do not change the problem.
Even if 7 or 8 receive it the HL will be zero and will transmit it no further. Each node can transmit a packet if HL > 0, I understand that.
What I’m trying to say is the starting HL limit, effectively limiting the possible distance for a single packet to travel.
If I still not get it, give me an example where a packet sent from 0 could reach let say node 100 on my example even it will be slow.
Ok, thank you guys, that’s what I wanted to confirm. Now it’s clear.
Back to the original question the “Why”, so the reason is “it might take very long before a message gets circled back.” like you said.
Ok that’s acceptable.
