This protocol maxes out at 7. But it is really more limited by all nodes only having one radio (which is a fine choice for cost and complexity reasons).
The sending node specifies a Max hops per packet and currently picks 3 for that value. Because given the long range of the radios and the initial use case that makes sense (given that we mostly use naive flood routing).
I’ve promised @CycloMies an updated version of the protocol doc this week. And he will further improve it.
This is an important topic to myself as well. I am curious how the protocol behaves when there are multiple devices between exceeding the 3 hops default and how the design decides routes to provide delivery?
Thanks to @geeksville and @CycloMies please look at documentation that is now provided
I think it helps a lot in explaining what options are available.
My request, when the android app shows a check mark in the ‘cloud’ that the message is acknowledged/received, … I would like to know the ‘name’ of the device that has acknowledged receipt.
The reason… If a nearby device acknowledged receipt… then it might not mean the ‘mesh’ has received the message.
The second reason, once a message is acknowledged, it is no longer in the transmit que. I kinda like the minimum number of re-tries still performed by the original initiating device.