Meshtastic configuration planner

Meshtastic: range vs. airtime

Meshtastic runs on one shared LoRa budget of airtime. Every setting below - radio mode, relaying, position interval - spends that budget on either reach or fresher positions, and the budget has a legal ceiling. This tool works out where your settings land.

These numbers are still being tuned against real field data, not just the model. If your settings, your ATAK CoT rate, or your own airUtilTx readings tell a different story, I want to hear it - open to any feedback or suggestions.

info@pls3d.store

Radio mode

Pick a row. Each step up reaches further and doubles the airtime.

ModeAirChan

Starting points

Sets radio and position config. Your node count stays put.

7 nodes

Everyone sharing the channel, including teammates out of sight.

0 (all RBaken)

Non-RBaken nodes keep the firmware defaults, so they broadcast every 300 s whatever you set above.

0 (all muted)

CLIENT relays, CLIENT_MUTE does not. The most expensive setting here.

1 (all in earshot)

A Client node cancels its own rebroadcast the moment it overhears another one, so a mesh where the relays hear each other emits a single copy. Raise it only if the team splits into pockets that are deaf to each other.

7 phones

Each one pushes its own CoT stream on top of Meshtastic positions, and no position interval can reduce it.

25 s

Throttle on how often a moving node broadcasts. Default 300 s.

120 s

position_broadcast_secs. A hard ceiling: if it is shorter than the interval above, it wins.

20 m

How far you move before a new fix is worth sending. Default 100 m.

5 s

Above 10 s the GPS powers down between fixes, so each one is a cold start.

1.4 m/s (5.0 km/h)

Walking is about 1.4 m/s.

12 per hour

Each glance lights the display for 60 s before it times out.

Position lag

Tight

42 m

while moving

Every RBaken refreshes at the interval above, if all configured the same.

Positions still send, but telemetry and node names are held back.

Duty cycle - your own radio3.2%
5%10%

10% aborts sends. 5% holds back telemetry.

Channel - everyone's traffic22.2%
20%25%

25% defers Client broadcasts. Trackers get to 40%.

Airtime

559 ms

per packet

Updates

25 s

timer

Traffic

1,428

packets / hour

Estimated range

169 dB link budget

Open field

14 km

Forest

2.7 km

Urban

1.6 km

Nothing relays, so anyone past this is invisible and nobody can bridge them.

Operation time

3000 mAh · bench estimate

2.1 days

at 48 mA

GPS

22.0

100%

Idle

20.0

always

Screen

2.4

20%

TX

3.7

bursts

The three presets

Same radio, three different trade-offs

Universal

Your RBaken node (gold) joins a team already on standard Meshtastic gear (green). It talks directly with any device on the same radio mode and channel, and shares the air politely with devices nearby on a different channel (grey). It stays muted, so it never relays and never asks anyone else to change a setting.

Long Range

The whole team is on RBaken and spread out further than one radio can reach. Every node relays, so an update can hop from node to node until it reaches everyone. The cost is a slower update rate, since each hop repeats the message on the same shared air.

Fast Update

A tight RBaken team that stays close together. Every node talks straight to the others at the fastest safe rate, so the position on screen stays current. Nothing relays here - a node that drifts out of range just drops off the map until it's back.

The trade-offs

What each setting costs

What does Meshtastic's radio mode (modem preset) do?

Range vs. speed

Longer range means slower updates. Each step up roughly doubles the airtime per message.

How many nodes can share one Meshtastic channel?

More traffic

Each node adds its own updates. Relaying doesn't multiply this - only one copy goes out per hop, no matter how many nodes relay.

How does relaying affect Meshtastic's duty cycle?

Reach vs. safety net

Relaying lets far-apart nodes hear each other, cheaply. Muted nodes skip this - anyone out of range just disappears.

What does Meshtastic's position broadcast interval do?

Freshness vs. airtime

How often a moving node may send an update. Lower is fresher, but costs more airtime.

What does Meshtastic's position minimum distance do?

Freshness vs. airtime

How far you must move before a new position is worth sending. Whichever throttle is slower - this or the interval - wins.

How does GPS update interval affect battery life?

Freshness floor

No update can be fresher than the GPS fix behind it. Keep it at 10 s or under, or the GPS cold-starts each time and drains the battery faster.

Why does movement speed matter for position lag?

Scales the lag

Not a setting - just how far a stale position drifts. The same lag looks worse the faster you move.

Does TX power or antenna gain cost airtime?

Free range

Both add reach for free, no extra airtime. Keep them maxed - EU868 caps power at 27 dBm.

Assumes the whole team moving at once - real load is usually about half that. Check airUtilTx and channel usage on your own device rather than trusting this model.

Under the hood

How the planner works

Nothing here is measured from your device. The planner takes the settings you pick, runs them through the same formulas the radio and the firmware use, and reports where they land. Seven steps, in order.

1. Airtime per packet

symbol_time = 2^SF / bandwidthairtime = symbols_in_packet × symbol_time

LoRa doesn’t send bytes, it sends symbols. The spreading factor sets both how many bits ride in one symbol and how long that symbol lasts: each step up adds a bit but doubles the duration, which is why a higher SF is always a net loss on speed.

Long Fast is SF11 at 250 kHz, so one symbol lasts 2048 / 250 000 = 8.2 ms and a 40-byte position packet fits into 68 symbols, or 0.56 s on air. Medium Fast is SF9, two steps down, so its symbols are four times shorter at 2.0 ms; the packet needs a few more of them (78, since each carries fewer bits) but still clears in 0.16 s.

The 16-symbol preamble and the error-correction overhead set by the coding rate are counted in that symbol total. Every other figure on this page is built on it.

2. Update rate

interval = min(heartbeat, max(min_interval, distance / speed))

Smart broadcast needs both enough elapsed time and enough movement, so the slower of the two sets the rate. The heartbeat is a ceiling on top of it: the firmware runs the two as one if/else sharing a single timestamp, so if the heartbeat is shorter it wins.

3. Position lag

lag = (interval + gps_interval) × speed

How far behind reality your own marker sits. No update can be fresher than the fix behind it, so a slow GPS interval adds to the gap directly rather than hiding inside it.

4. Load on the channel

air_per_hour = packets_per_hour × airtimechannel % = air_per_hour / 36

First how many seconds of air the whole mesh burns in an hour, then that as a share of the hour. An hour holds 3600 seconds, so one percent of it is 36 seconds, and dividing seconds by 36 turns them straight into percent.

Each group of nodes is its own stream: RBakens on the interval above, stock devices on the firmware’s 300 s, ATAK phones on their CoT rate. Relaying multiplies the total by the number of copies one packet actually produces, which is set by how the team is spread out rather than by how many nodes have relaying turned on.

5. Duty cycle

duty % = own_air_per_hour / 36

The same 36 as above, but counting one node instead of the mesh. The node modelled is the worst-placed one: it originates on every stream and, if it relays, also carries its share of everything it did not originate. EU868 caps this at 10%, and the firmware starts holding telemetry and node names back above 5%.

6. Range

budget = tx_power + 2 × antenna_gain − sensitivityrange = 10^((budget − 31.2) / (10 × n))

The budget is how much signal the link can afford to lose on the way. Both ends of it sit on the same dBm scale, so it is really just the gap between them. The radio pushes out 27 dBm. The receiver on the far side still decodes a signal as faint as −131.5 dBm. Falling from +27 down to −131.5 is a drop of 158.5 dB, and that drop is what the air in between is allowed to eat. The antennas then help at both ends, 5 dBi each, worth another 10 dB, which brings the total to 168.5 dB. That is all the minus sign in the formula does: subtracting a negative sensitivity is how you measure the distance down to it.

The second line asks how far 168.5 dB buys. On 868 MHz the first metre alone costs 31.2 dB, fixed by the frequency; past that, loss climbs with distance at a rate set by n. Free space would be 2, but two radios at chest height do much worse, so this uses 3.3 in the open, 4.0 in forest and 4.3 in a built-up area, fitted to real walks. In forest that solves to 2.7 km.

n matters more than the budget does: the same 168.5 dB stretches to 14 km in the open and shrinks to 1.6 km in town. A relaying mesh chains up to three hops, so the figure shown is three shorter hops rather than one long one.

7. Battery

hours = 0.8 × capacity / average_draw

Average draw is idle current plus the GPS’s share of the hour, the screen, and the radio’s transmit time. GPS dominates: at 10 s or under it never sleeps, and above that every wake is a cold start of roughly 30 s, so a longer interval only pays off once it clears that comfortably.

What it assumes

  • ·Every node moves at the same constant speed, and the whole team broadcasts at once. A real team is usually nearer half that load.
  • ·The same antenna gain on both ends of every link, which is why gain counts twice in the budget.
  • ·Receive sensitivity per mode is the textbook figure: −174 dBm, plus 10 log10 of the bandwidth, plus a 6 dB noise figure, plus the SNR limit for that spreading factor. It lands within 1 dB of Meshtastic's own link-budget table, but a real board with a real noise floor will do worse.
  • ·No retries, no direct messages, no MQTT uplink, and no neighbours on other channels sharing the band.
  • ·No mesh topology is simulated. Relay copies are a number you set, not a graph the tool solves.