Getting Started

CLIENT_MUTE is the preferred starting point for mobile nodes because it avoids unexpected relay behavior in an infrastructure-based mesh. Personal or mobile nodes often experience worse SNRs than fixed nodes, which causes them to relay first and potentially stop a better-placed node from relaying. It’s also important if you have two nodes in close proximity, avoiding the “false ack” problem that can hide connection issues.

Smart position is preferred because it reduces the broadcasts if position hasn’t changed. However, it has trouble with altitude so it’s best to disable this—altitude is usually not helpful for mobile nodes. Generally, position doesn’t need to be sent more frequently than 30 minutes.

Telemetry is disabled because we don’t need to know your battery level or channel utilization on a regular basis. Neither are meaningful to the rest of the mesh.

Reducing automatic device info broadcasts avoids the throttling that inhibits the request user info features, and it makes room for more useful packets generally. Also, nodes have the ability to send node info on-demand if the operator needs to advertise their info.

Personal nodes usually need more hops to work through the infill to get to and from the network backbone. The next-gen MediumSlow network relies on this being the maximum of 7 because the network adopts packet-level resiliency instead of link-level, and needs the additional hops to allow for retries and path diversity.

CLIENT is the preferred starting point for fixed personal nodes because they are likely to provide useful conditional relay.

Position is optional, but helpful to understand the physical realities of the mesh. Smart position is not recommended, since the node is not moving. It can have trouble with variations from a GPS fix so it’s best to set an explicit fixed position. Altitude is helpful for understanding coverage.

Telemetry is preferred disabled because others generally don’t need to know your battery level or channel utilization on a regular basis. Neither are meaningful to the rest of the mesh. The node will still relay its battery info regularly when you connect your app to it.

Reducing automatic device info broadcasts avoids the throttling that inhibits the request user info features, and it makes room for more useful packets generally. Also, nodes have the ability to send node info on-demand if the operator needs to advertise their info.

Personal nodes usually need more hops to work through the infill to get to and from the network backbone. The next-gen MediumSlow network relies on this being the maximum of 7 because the network adopts packet-level resiliency instead of link-level, and needs the additional hops to allow for retries and path diversity.

CLIENT_BASE helps differentiate the infrastructure nodes from personal nodes. It also enables handy infrastructure behaviors through favoriting adjacent routers and personal nodes, features that work best when the node is in a static position. CLIENT_BASE is also the recommended starting point even if the node is well sited.

Altitude is useful for line-of-sight estimates. But smart position has trouble with altitude if it changes due to GPS variation and can spam position unnecessarily. 24 hours is sufficient to stay on the map.

Position is highly recommended for infrastructure nodes so users can understand which nodes provide coverage for them. (It doesn’t have to be exact, but should be a useful approximation.) Fixed position is recommended even if there is GPS present. The GPS is still useful for keeping the node's clock accurate, but it can cause unexpected position variations due to errant GPS signal reception. 24 hours is sufficient to maintain the clock without a meaningful drain on the battery of solar nodes.

Telemetry broadcasts are useful to monitor the health of the node, but more frequent than 6 hours is excessive and takes up useful airtime.

Device info is significantly curtailed because it’s not necessary for the nodes to route packets, and takes up airtime.

Hop limit: fixed nodes should focus on advertising to their immediate vicinity. They also should be within direct or single-hop range of infrastructure, and don’t need as many hops to reach through the infill — they are the infill.