LoRa radios are very good at picking out weak signals, so even small handheld units can often communicate over several miles in open, flat areas. Like most UHF radios, they work best when there are few obstacles between them, but LoRa can often keep working after other common radio systems would have already lost the signal.
So ordinarily, a handheld Meshtastic radio might get 2-3 miles over flat, open, unobstructed terrain. More if the receiving radio is higher or lower in elevation than the transmitter, less if there are obstructions such as hills, buildings, or other interference sources. Two home stations with rooftop or treetop radios may get a reliable link over 4-6 miles or more. And that's just the distance to the next mesh station. Packets will continue to be repeated by progressively more distant stations -- often well beyond the range of the originating station -- until the hop limit is reached.
A hop occurs when one Meshtastic radio receives a packet and rebroadcasts it so that nodes farther away can hear it. A message sent with a hop limit of three may be repeated by as many as three intermediate nodes before it stops propagating. Each relay reduces the remaining hop limit by one; when a node receives a packet with no hops remaining, it may process the packet but will not retransmit it.
Meshtastic does not select one fixed path in advance. Instead, it uses managed flood routing. Packets are broadcast to all stations in range. Nearby nodes hear the broadcast, and eligible nodes may relay it while the protocol uses timing and duplicate suppression to reduce unnecessary retransmissions. As a result, the same message may arrive by more than one route, although duplicate copies are discarded.
Nodes can relay packets even when they cannot decrypt the channel contents, provided they use compatible LoRa radio settings and their rebroadcast configuration permits it.
Additional hops can extend coverage around hills, buildings, and other obstacles, but every retransmission consumes airtime on the shared LoRa channel. Excessive hop limits can therefore increase congestion, collisions, and delivery delays without meaningfully improving coverage. Meshtastic permits a maximum hop limit of seven and currently defaults to three, which its documentation recommends as sufficient for most networks.
If Meshtastic's flood routing and hop counter concepts sound familiar, it's similar to how packets are repeated across APRS networks.
The Meshtastic network in Richmond is primarily made up of portable, mobile, and low-altitude fixed stations like residential rooftop nodes. We currently have no (or very few) high-altitude nodes positioned on top of tall buildings or on towers. There are lots of mesh users in the area, and if you're within about a 5-10 mile radius of downtown Richmond, there's a good chance you'll find at least one other node in your community.
While communication within a neighborhood may be reliable, you'll have a harder time getting a message to pass over greater distances. Here are some examples of what you might expect:
Often works well:
► Families and friends keeping in contact at a concert or outdoor event; hiking/camping, etc.
► Messaging throughout the neighborhood, subdivision, apartment complex
► Locally clustered communication with stations all located within a couple miles of each other
Examples: Museum District to Downtown, Manchester to Church Hill, East End to Mechanicsville
More difficult or not happening:
► Indoor coverage without another nearby node
► Sending a message across town or beyond
► Long distance communication in rural areas and less-dense suburban neighborhoods
Examples: Mechanicsville to Short Pump, Manchester to Northside, Chesterfield to East End
Communication over greater distances will get easier as more high-coverage nodes join the network. You can help! Put a node up in a tree, on your roof, or in your attic to increase mesh density and reliability.
Mesh users will quickly discover that the network coverage and performance at any given location varies over time. This can be due to things like:
► Seasonal foliage changes. With fewer leaves on trees in the late fall through early spring, cool season coverage may be better than during the summer months.
► Weather-related foliage attenuation. Leaves that are wet from recent rain or trees that are covered in snow or ice can attenuate signals and reduce range. Treetop nodes may be particularly impacted. 900 MHz signals are not especially susceptible to "rain fade" though heavy rain in-progress can adversely impact performance indirectly through foliage attenuation.
► Daily, seasonal visitor patterns. There tends to be more portable user activity -- and at least somewhat improved mesh coverage -- in and near recreation areas during the day and with favorable weather.
► Weekend and nighttime reductions in interference. The 900 MHz ISM band is full of non Meshtastic noise sources from a variety of commercial and industrial users that tend to be less active overnight and on weekends. This can reduce interference and improve reliability of service on the mesh.
► Network congestion. Your packets may be able to reach a node, but if that part of the network is too busy with other chatter, your message might not be able to squeeze through. Keeping hop limits low (3-5) and limiting broadcast traffic like telemetry and position beacons will help reduce congestion.
It's not uncommon for airborne nodes to make transient appearances on the network, bridging distant meshes that are hundreds of miles apart. Node operators often call out for contacts in the default #LongFast channel. Ham radio operators in particular may find these contacts enjoyable as they provide a fleeting opportunity to make quick long-distance contacts similar to working amateur satellites. If you can see them, they can probably see you (subject to hop count settings).
Meshtastic uses the MQTT protocol, which allows bridging of distant networks over the Internet. Meshtastic provides a limited public MQTT broker (server). Various alternate public servers are also available, and deploying a private MQTT broker is fairly straightforward for someone with a basic knowledge of Docker and network firewall configuration. Nodes received over MQTT will show (MQTT) as part of the node name. For more information, see our MQTT page.