Second question. As I understand it any of the nodes will help to grow the mesh and will propagate a message as long as the number of hops is greater than 0 correct? So a “Router” is not specifically needed? And the only main difference is the router will sleep the screen and will turn off the Bluetooth after a short amount of time to save power but the device does not enter any kind of sleep mode correct?
If we want to experiment with Store and Forward does the device need to be configured to be a Router or will it work with regular nodes?
Number of hops: As I understand it the max number of hops is 7 currently. Doesn’t that severely limit the distance to which the mesh can grow? For example say you wanted to communicate across a distance of say 100 miles and you have nodes spaced every 10 miles that can hear each other. If you send a message starting at mile 0 and have number of hops set to 7 the furthest the packet would be carried would be to the 7th node.
If that is in fact how it works what about maybe having the ability for devices configured as routers to “reset” the number of hops between routers. Enabling multiple smaller meshes (each talking to their respective router) to be connected together.
That documentation is for the new 1.3 routing a 1.2 a router is only a power saving option, and the router feature has been removed in favor of roles in 1.3.
The mesh is inherently constrained by working on free shared spectrum we have no story for networks with hundreds or thousands of nodes other than bridging a number of networks over IP via MQTT. This is why companies in this space have all gone to paid spectrum as soon as they took investment money.
We have a 32 node max in 1.2 and are testing 64-80 in 1.3. Increasing number of hops creates a lot more mesh activity and does not necessarily get you a lot more range.
If any mesh node sees a packet with a HopLimit other than zero, it will decrement that HopLimit and attempt retransmission on behalf of the original sending node. In order to promote letting nodes that are further away flood the message, such that the message eventually reaches farther, the contention window (see Layer 1) for a flooding message depends on the Signal-to-Noise Ratio (SNR) of the received packet. The CW size is small for a low SNR, such that nodes that are further away are more likely to flood first and closer nodes that hear this will refrain from flooding.
We have two limits … bandwidth and memory on the Meshtastic node.
Based on a calculation on the number of devices available with the bandwidth available for the previous default, a decision was made to limit the number of devices to 32.
With 1.3, we’ve changed the default modem configuration and implemented compression of text messages. With that and additional measurement of the on device memory, we’ve increased the limit to 80 devices.
We’ll be constantly monitoring total stability and tweak that if needed. It’s safe to say that we have a limit of between 64 and 80 nodes.
The hard part of all this is that we really don’t know how much your network is going to be used. We made a lot of assumptions. It’s very likely that even with our new defaults and data compression, you may end up not having a good user experience with 80 nodes. If that happens, please write back and let us know.
I guess my question about the node limit is more about where the limiting is done from a software point.
I understand about limited bandwidth and collisions and such.
For example if there are 90 users in my network will node 0 talk to 80 other nodes and store their ID locally so that once 80 unique IDs are reached it can no longer communicate with any additional unique IDs? If that is what happens does the list get reset on a power cycle?
It would be unlikely that there would be that many users all online using their device at the same time. At least until it reaches a high level of adoption. So if a node list of unique IDs is stored but half of them don’t even have their devices turned on then more unique nodes should be allowed to be communicated with.
Hopefully you get what I mean. Not sure I explained it the best.