Planned R*nodes Signal
Very crude diagram of planned signal coverage from R*roles strategically placed. This will be modified after more through signal strength testing.
This page serves as a living working document of the planned network topology in Swansea. If you are interested in networking and heuristics, we recommend familiarizing yourself with the documentation.
Some of the notes and recommendations on this page have been provided by Meshtastic Devs/Admins thorough online discussions and YouTube videos.
There is a common misunderstanding about the device roles in the network. Comprehensive documentation on all roles is available here.
| CLIENT | App connected or stand-alone messaging device. General use for individuals needing to communicate over the Meshtastic network with support for client applications. |
| CLIENT_MUTE | Device that does not forward packets from other devices. Situations where a device needs to participate in the network without assisting in packet routing, reducing network load. |
| CLIENT_HIDDEN | Device that only broadcasts as needed for stealth or power savings. Use in stealth/hidden deployments or to reduce airtime/power consumption while still participating in the network. |
| REPEATER | Infrastructure node for extending network coverage by relaying messages with minimal overhead. Not visible in Nodes list. Best positioned in strategic locations to maximize the network's overall coverage. Device is not shown in topology. |
| ROUTER | Infrastructure node for extending network coverage by relaying messages. Visible in Nodes list. Best positioned in strategic locations to maximize the network's overall coverage. Device is shown in topology. |
The most common roles have been denoted. ROUTER_CLIENT has been removed as it is scheduled for deprecation in later firmware revisions due to abuse.
ROUTER_CLIENT was a role created for testing purposes before converting to the full ROUTER role. Unfortunately, too many national (as in GB) mesh users are using this configuration or leaving their nodes in this role on their standard mobile devices!
ROUTERS and REPEATERS have a slightly different configuration in the Meshtastic firmware. They consume more power due to keeping the LORA radios powered for constant communication and packet routing. Additionally, they have "prioritized" routing, meaning they respond faster than general CLIENT* roles on the mesh.
As the R* roles transmit and rebroadcast LORA network packets, their placement is crucial to the health and distance capabilities of the mesh. There are a few misconceptions which we will address below:
| Hop limits are ALWAYS DECREMENTED on every node in the mesh network. This is to prevent infinite packet routing if there is more than 1x R* role on the network. Any hop saving denoted in the apps is an untrue representation of the actual path travelled of the packet on the network |
| Due to the hop limit mentioned above and the nature of faster routing, misplaced routers can degrade not only the local mesh but also degrade the range of the network and prevent other more remote nodes from joining and participating. |
| Not a fault of the R*roles, but users with incorrect hop_limits will have their packets bounce from R*node-to-R*node or R*node-to-client until the hop_limit of the packet reaches zero (0).Please remember to set an appropriate hop_limit, though this may need to be temporarily adjusted when attempting to reach remote nodes. |
It is generally envisioned that a router/repeater would support a minimum of 20-25 nodes. Therefore, on the Swansea local mesh, we should aim to have running 4-5 routers/repeaters strategically placed on the edge of the local mesh. These edge routers/repeaters purpose is to bridge meshes from other local communities, e.g., East and West South Wales.
Very crude diagram of planned signal coverage from R*roles strategically placed. This will be modified after more through signal strength testing.