PULSEMelbourne Meshtastic · by The Clique online

Understand the network

How a message gets from you to Melbourne

You don’t need to understand radio to use Meshtastic, but a few ideas explain why some messages arrive and others don’t, and why the advice on Grow the mesh works.

Messages hop from node to node

When you send a message on the public channel, every node that hears it can repeat it once. The nodes that hear those repeats can repeat it again, and so on. This is called managed flooding.

Before repeating, a node waits a moment and listens. The nodes that heard the message most weakly, usually the ones furthest away, get to go first, which pushes the message outward. Closer nodes that then hear someone else repeat it stay quiet to save airtime. Router roles are the exception: they repeat regardless.

A message travelling from You through two relay nodes to TheClique, counting down the hop limit YouRelay A Relay BTheClique sends, limit 3repeats, 2 left repeats, 1 lefthears: 2 hops hop 1hop 2 received
Each repeat uses up one hop. TheClique works out “2 hops” from the hop limit you started with minus the hops left when it arrived.

Hops and the hop limit

Every message carries a hop limit, which counts down by one each time a node repeats it. When it reaches zero, nobody repeats it again. The default is 3. You can raise it, but please don’t on the public channel: every extra hop means more nodes repeating every message, and the channel fills up for everyone.

When TheClique says it is “receiving you via 2 hops”, it means two other nodes passed your message along. The count is the hop limit the message started with, minus the hops it had left on arrival. A few things make it less exact:

  • Firmware older than 2.3.2 doesn’t record the starting hop limit, so the count can’t be worked out at all.
  • On newer firmware, a hop between favourited routers can be “free”, so the count can be lower than the number of nodes that actually relayed it.
  • A message that came across the internet through MQTT has no meaningful hop count.

What SNR and RSSI measure

RSSI is how strong the received signal was, in dBm. Closer to zero is stronger; around −120 dBm is very weak. SNR (signal-to-noise ratio, in dB) is how far the signal stood above the background noise. LoRa is unusual in that it can still decode messages when the SNR is below zero: an SNR of −10 dB means the signal was 10 dB weaker than the background static, and on the LongFast preset messages can still get through down to about −17.5 dB. That’s a big part of why it reaches so far.

Only the last link, from Relay B to TheClique, is measured by TheClique's SNR and RSSI YouRelay A Relay BTheClique not measurednot measured SNR, RSSI
The signal readings on a received message describe only the final link. For a relayed message they tell you about Relay B, not about you.

That last point catches a lot of people out. A relayed message with a great SNR tells you the last relay is close to the receiver. It says nothing about how well you were heard. That’s why Pulse reports signal strength only for messages it hears directly, and just the hop count otherwise.

Coverage: height, terrain and buildings

LoRa at 915–928 MHz bends a little over obstacles, but not much. Coverage is shaped mostly by what lies between antennas: hills, buildings, trees and the ground itself.

Two pairs of antennas: low ones blocked by a roofline, high ones with the signal zone clear above it roofline blocks the low path raise both ends: the zone clears
The signal needs a zone around the direct line kept mostly clear, not just a thin line of sight. Raising antennas lifts that zone above roofs and trees.

Channel utilisation

All nodes in range share the same channel. Channel utilisation (ChUtil in the app) is the share of the last minute your node heard the channel in use, by anyone, including noise. Airtime (AirUtilTX) is the share of the last hour your own node spent transmitting.

The firmware uses these figures to stay polite. From 25% channel utilisation, nodes skip their routine position broadcasts and most telemetry, and the range test module stops sending. From 40%, they stop answering requests for node information. Melbourne’s mesh is nowhere near that today; the busiest figures we’ve seen are a few percent.

A bar from 0 to 100 percent channel utilisation with a marker at 25 percent where nodes start holding back routine broadcasts 0%25%100% example: 18% busyfrom 25%: routine broadcasts skipped 40%
From 25% channel utilisation, nodes skip routine position and telemetry broadcasts so that messages have room. From 40%, they stop answering node-information requests.

Utilisation is local. A node on a high site may see a busy channel because it hears so many others, while a node in a valley sees a quiet one. Pulse checks TheClique’s own figure and stays silent when it’s over 25%.

Intermittent and reliable nodes

A path through the mesh exists only while every node on it is on. Nodes that come and go create paths that work one evening and fail the next. That’s the main reason keeping a node on is the first suggestion on this site.

What the mesh can’t do

  • It isn’t guaranteed delivery. A message on the public channel shows as delivered as soon as your node hears any other node repeat it. That doesn’t prove anyone further away got it, and silence doesn’t always mean nobody heard you. To test whether you reach somewhere, you need an answer back, such as a direct message or a radio check.
  • Direct messages travel differently. Since firmware 2.6, the first one floods like a broadcast, and after that nodes learn which neighbour to pass it to.
  • It’s slow and small. Messages are short (around 200 characters) and each one takes a noticeable moment of airtime.
  • It doesn’t route around gaps it can’t reach. If no chain of switched-on nodes connects two places, no setting will join them. Only placement will.
  • The public channel is public. Anyone in range can read it.