Coverage Planning Tools

• Coverage Planning Tools Overview
• MeshMapper Wardriving Guide
• Meshtastic Range Testing Guide
• RF Coverage Prediction Tools
• Field Testing and Coverage Verification
• Mesh Network Capacity and Congestion

Coverage Planning Tools Overview

Coverage Planning Tools Overview

Before deploying hardware, use these tools to estimate coverage, find line-of-sight paths, and identify gaps in your network. Most are free and browser-based.

MeshCore-Specific Tools

Tool	URL	What It Does
NoDakMesh Node Planner	nodakmesh.org/tools/node-planner	Satellite + topographic map with line-of-sight analysis and live MeshCore node visibility. Best starting point for North American planning.
MeshCore Live Map	map.meshcore.io	Live worldwide visualization of MeshCore nodes that have reported their location.

Meshtastic Tools

Tool	URL	What It Does
Meshtastic Site Planner	site.meshtastic.org	Estimates theoretical RF coverage from a location using terrain data. Enter coordinates and antenna height.
Meshtastic World Map	meshmap.net	Real-time map of Meshtastic nodes worldwide that report to the public MQTT broker.

General RF Planning Tools

Tool	URL	What It Does
HeyWhatsThat	heywhatsthat.com	Radio horizon visualization using terrain elevation data. Enter a location and see what is visible from that point.
Radio Mobile Online	radiomobileonline.pe1mew.nl	Advanced RF propagation modeling with configurable transmit power, antenna gain, and receiver sensitivity. Supports point-to-point and coverage area analysis.
SCADACore RF Line-of-Sight	scadacore.com	RF line-of-sight tool for quick path analysis between two coordinates.

Planning Workflow

1. Check existing nodes: Start with map.meshcore.io or meshmap.net to see what already exists near your target area.
2. Identify candidate sites: Use heywhatsthat.com to find hilltops, buildings, or towers with broad radio horizons.
3. Model the path: Use Radio Mobile or the NoDakMesh node planner to estimate signal strength on key links.
4. Validate with MeshMapper: After deployment, use MeshMapper wardriving to map actual measured coverage (see MeshMapper Wardriving Guide).

MeshMapper Wardriving Guide

MeshMapper Wardriving Guide

MeshMapper is a platform for mapping actual measured RF coverage of a MeshCore network - not just node locations, but real signal coverage at road level. This is the ground truth that theoretical planners cannot provide. MeshMapper is a MeshCore tool (Android, iOS, and web); for Meshtastic coverage mapping see meshmap.net or the Meshtastic Site Planner instead.

Getting the App

• Android: Google Play - search "MeshMapper"
• iOS: App Store - search "MeshMapper"
• Web interface: wd.meshmapper.net
• The app is free.

Connecting Your Radio (BLE)

For wardriving, MeshMapper connects directly to your MeshCore radio over Bluetooth LE (BLE) - it does not require an MQTT connection to collect coverage data. Pair your MeshCore device to the app over BLE before starting a session.

Important: MeshCore devices only support one BLE connection at a time. Disconnect the MeshCore companion app before launching MeshMapper or the connection will fail.

Observer / Region-Admin Setup (Optional)

Separately from the per-user wardriving flow above, an MQTT observer can be configured to aggregate mesh traffic for region administrators. This is not part of normal per-user wardriving. If you are running an observer, connect to one of these brokers:

• mqtt-us-v1.letsmesh.net:443 (WebSocket TLS)
• mqtt.meshmapper.cc:443 (WebSocket TLS)

Operating Modes

Mode	Description	Best For
Hybrid (recommended)	Alternates discovery requests and channel messages. 50% fewer transmissions than legacy Active mode.	General wardriving - balances coverage data quality with network impact
Passive	Discovery requests every 30 seconds; no channel messages.	Minimal network impact; good for densely populated mesh areas
Manual Ping	Single on-demand ping.	Spot-checking coverage at a specific location without driving
Active	Legacy channel-message-only mode.	Backward compatibility - Hybrid is superior in all cases
Trace	Focus on a single repeater identified by its hex node ID.	Antenna alignment, diagnosing a specific repeater's coverage, post-installation validation

Coverage Map Color Meanings

Color	Code	Meaning
Green	BIDIR	Two-way confirmed contact - gold standard coverage. Your device and the repeater can hear each other.
Cyan	DISC	Discovery-based two-way confirmation - confirmed via discovery protocol rather than channel message.
Orange	TX	Transmit-only path - your signal reaches the repeater but return path is incomplete (asymmetric link).
Purple	RX	Receive-only - you can hear the repeater but it cannot hear you.
Grey	DEAD	Signal heard but not relayed - marginal contact; unreliable for mesh routing.
Red	DROP	No repeater responded - no coverage at this location.

Wardriving Best Practices

• Mount your device with the antenna as high as practical in the vehicle (dashboard or roof magnet mount).
• Drive at normal road speeds - the app samples frequently enough.
• Cover roads in a grid pattern for systematic area mapping.
• Use Trace mode after installing a new repeater to confirm its actual coverage footprint.
• Share your coverage data back to the community map so others benefit.

Meshtastic Range Testing Guide

Overview

Systematic range testing goes beyond "does it connect?" - it quantifies signal quality, identifies path bottlenecks, and produces evidence you can use to justify infrastructure decisions. This guide covers the four primary tools available for characterizing mesh coverage and a recommended workflow for comprehensive coverage analysis.

Understanding Signal Quality Metrics

Metric	Excellent	Good	Marginal	Likely Failure
SNR	> +10 dB	+5 to +10 dB	0 to +5 dB	< −5 dB
RSSI	> −90 dBm	−90 to −110 dBm	−110 to −120 dBm	< −125 dBm

Key point: SNR matters more than RSSI. LoRa can decode signals well below the noise floor - a weak signal in a quiet RF environment (high SNR) will decode reliably even at very low RSSI. Focus on SNR first.

Note: these bands are practical app-display heuristics, not hard thresholds. LoRa can still decode down to roughly −20 dB SNR at high spreading factors (SF11/SF12), so a low SNR is not automatic failure - a −15 dB packet at SF11/12 can still get through.

Tool 1 - Built-In Range Test Module

The range test module sends periodic test packets and logs which nodes receive them, along with signal metrics. It is the most systematic way to characterize coverage between a fixed location and a node moving through the area.

CLI Setup

On the sender (the fixed/infrastructure node), enable the module and set the sender interval:

meshtastic --set range_test.enabled true
meshtastic --set range_test.sender 30

The second command sets sender interval to 30 seconds. The node will transmit a test packet every 30 seconds. On the receiver (the mobile node), enable range_test.enabled but leave range_test.sender at 0 (off) so it only listens and logs.

App Setup

1. Open the Range Test module settings. On Apple this is Settings > Module Configuration > Range Test; on Android it is Settings > Range Test.
2. Enable the module
3. Set sender interval
4. Activate Sender mode on the fixed node; leave the mobile node in receiver mode (module enabled, sender off)

Procedure

1. Configure the fixed-location node as the sender (range_test enabled, sender interval set) - typically a repeater or infrastructure node. It transmits sequential test packets.
2. Configure a second node as the receiver (range_test enabled, sender off, GPS on) carried by a person or vehicle. The receiver logs each received packet together with its GPS position.
3. Walk or drive away from the sender. The mobile receiver logs each packet with SNR, RSSI, and GPS coordinates.
4. Export logs to CSV for analysis. (Saving the CSV to onboard flash is ESP32-only; app clients export the log separately, e.g. from the Android Debug Log.) The resulting CSV can be imported into Google My Maps to visualize coverage.

Tool 2 - Trace Route

Trace Route reveals the actual path packets take through the mesh and reports per-hop signal quality. Use it to identify which routers packets are traversing and where bottlenecks are.

CLI

meshtastic --traceroute !nodeId

App

Long-press a node in the node list → select Trace Route.

Output

Trace Route shows each hop in the path, with the SNR reported per hop (firmware ≥ 2.5). Per-hop RSSI is not carried in the traceroute payload - only SNR per link is returned. Use this to:

• Confirm which repeaters are actually routing your traffic
• Identify weak links in multi-hop paths
• Verify that a new repeater is being used as expected

Tool 3 - Signal Metrics in Node List

The node list provides a quick snapshot of signal quality for all recently heard nodes - useful for baseline assessment without active testing.

CLI

meshtastic --nodes

Shows

• SNR and RSSI for the last received packet from each node
• Hop count
• Time since last activity
• GPS distance (if both nodes have GPS)
• Battery percentage

Tool 4 - MeshMapper Wardriving (MeshCore)

MeshMapper is a MeshCore wardriving tool (available for Android, iOS, and web), not a Meshtastic module. It combines GPS-tagged signal data into a visual coverage heatmap - ideal for documenting the measured RF coverage of a MeshCore network across a neighborhood, event venue, or service area. If you are mapping a Meshtastic network instead, use the Meshtastic Map view or a community Meshtastic mapper; this tool is included here as the MeshCore equivalent.

Setup

1. Install MeshMapper (Android, iOS, or web).
2. Connect a MeshCore device over BLE. (MeshCore devices support only one BLE connection at a time, so disconnect the MeshCore companion app first.)
3. Drive, walk, or cycle through the area you want to map.
4. MeshMapper logs GPS coordinates with signal strength for each received packet.
5. Upload to generate a coverage heatmap.

Heatmap Colors

Color	Meaning
Green	Strong signal
Yellow	Marginal signal
Red	Weak signal
Blank	No coverage detected

Recommended Testing Workflow

1. Baseline: Check node list (Tool 3) for current signal quality across known nodes.
2. Path analysis: Run trace routes (Tool 2) to all infrastructure nodes - confirm expected routing, identify weak hops.
3. Coverage measurement: Deploy range test module (Tool 1) for systematic point-to-area coverage data from each infrastructure node.
4. Area mapping: Conduct MeshMapper wardriving (Tool 4) for a comprehensive geographic coverage picture of a MeshCore network.
5. Ongoing monitoring: Establish MQTT monitoring to continuously log SNR/RSSI from infrastructure nodes - enables detection of degraded links before users report problems.

RF Coverage Prediction Tools

Why Model Before Deploying

Walking a coverage area with a radio after installing a repeater is valuable ground-truth - but it is expensive if the site turns out to be wrong. Free online tools let you model RF line-of-sight and rough coverage before committing to an installation, saving you a wasted site visit and hardware move.

HeyWhatsThat (heywhatsthat.com)

HeyWhatsThat is the best free tool for quickly visualising the radio horizon from a specific point.

• Enter the coordinates (or click a map) and elevation of your proposed repeater site.
• The tool generates a panoramic view and a map showing all terrain that is geometrically visible from that point.
• Accounts for Earth curvature and terrain elevation using SRTM data.

Limitations: HeyWhatsThat's SRTM data is a digital surface model (coarse ~30 m resolution), so it partially includes building rooftops and tall canopy but cannot resolve individual buildings or trees. Treat its results as terrain-dominated geometric line-of-sight, not true RF coverage - it does not model actual RF propagation, diffraction, or local clutter.

Use case: Quickly screen potential hilltop sites before visiting. A site with a 360° clear horizon is worth investigating; a site blocked by higher terrain in key directions is a red flag.

Radio Mobile (radiomobile.ca)

Radio Mobile is a more advanced free tool aimed at amateur and community radio network planning.

• Point-to-point path profiles: shows the terrain cross-section between two points with Fresnel zone visualisation, so you can see whether the path is truly clear.
• Coverage maps: generate area coverage maps from a repeater site given your TX power and antenna height.
• Supports custom frequency, antenna gain, and receiver sensitivity input - LoRa parameters can be modelled directly.

Radio Mobile has a steeper learning curve than HeyWhatsThat but is much more capable for serious network planning.

SPLAT! (Amateur Radio Propagation Tool)

SPLAT! is an open-source Linux/macOS command-line tool for RF propagation analysis.

• Generates coverage maps using the ITM (Irregular Terrain Model) or ITWOM propagation model.
• More accurate than simple line-of-sight tools - accounts for diffraction over ridges.
• Requires downloading SRTM terrain data files for your region.

SPLAT! is best suited to serious network planners who are building a community mesh from scratch and need repeatable, scriptable coverage analysis.

Meshtastic Signal Mapper

Some community tools (including extras around meshmap.net) allow you to import Meshtastic position data and visualise actual observed coverage on a map. Where real-world data already exists, this is more valuable than any theoretical model. Check your regional Meshtastic community's resources for existing coverage maps before starting your own modelling work.

CloudRF / ORCA (Cloud-Based RF Planning)

CloudRF is a commercial service with a free tier that generates RF coverage maps using the ITM/Longley-Rice model.

• Can account for clutter (buildings, forest) in some calculation modes.
• Easy web interface: enter site coordinates, antenna height, frequency, TX power, and antenna gain to get a shaded coverage map.
• The free tier allows a limited number of calculations per month - sufficient for planning a handful of repeater sites.

CloudRF is a good middle ground between the simplicity of HeyWhatsThat and the complexity of SPLAT! for planners who want clutter-aware coverage maps without installing local software.

Field Testing and Coverage Verification

Why Field Test?

Even the best RF prediction tools are only as good as their terrain models. Buildings, vegetation, and local obstructions can significantly degrade predicted coverage. Field testing confirms what the models predict - and reveals the surprises they miss.

Basic Field Test Procedure

1. Deploy the repeater at the proposed site, even temporarily on a tripod.
2. Walk or drive the coverage area with a second device (phone running the Meshtastic app, or a handheld node).
3. Record signal metrics at known locations: SNR (signal-to-noise ratio) and RSSI (received signal strength indicator).
4. Note locations where packets stop getting through - this defines your coverage boundary.
5. Compare results to your predicted coverage map and identify gaps or surprises.

Understanding SNR and RSSI for LoRa

RSSI is received signal power in dBm. For mid-range spreading factors, useful values run roughly −90 to −120 dBm and reliability degrades below about −120 dBm. But −120 dBm is not a hard floor: at high spreading factors (SF11/SF12, the Long Fast and Long Slow presets) the SX1262 decodes reliably down to roughly −131 to −137 dBm (BW 125 - 250 kHz). The usable RSSI floor depends on the active modem preset, so don't reject an otherwise-usable high-SF link just because RSSI dipped past −120 dBm.

SNR is signal-to-noise ratio in dB. LoRa's key advantage over conventional radios is its ability to decode packets at negative SNR values, and how far negative depends on the spreading factor. The theoretical demodulator SNR floor is about −7.5 dB at SF7, about −17.5 dB at SF11, and about −20 dB at SF12. So the SNR at which a link fails is preset-dependent: a Long Slow (SF12) link decodes well below where a fast, low-SF (SF7) link would already be failing.

Rule of thumb (these bands are preset-dependent - treat them as a rough guide and interpret SNR against your active modem preset, not as universal thresholds):

• SNR > 0 dB - strong signal on any preset.
• −5 to −10 dB - marginal on fast/low-SF presets (e.g. ShortFast), but still solidly decodable on Long Fast (SF11) or Long Slow (SF12).
• Below −15 dB - near the noise floor and likely to lose packets on low-SF presets, but long-range high-SF presets routinely decode down toward −20 dB SNR, so −15 dB is still usable on Long Fast / Long Slow.

For planning purposes it can help to adopt a single conservative marginal-SNR floor (around −15 dB) across the book, while remembering the true decode floor is lower at high SF (SF11 ≈ −17.5 dB, SF12 ≈ −20 dB).

Reading Signal Data in Meshtastic

The Meshtastic app shows RSSI and SNR for each received packet in the message details view. This is real link-quality data from your actual deployment - use it as your primary signal source during field testing. For multi-hop paths, the Meshtastic traceroute feature reports the SNR per hop (not RSSI), which is useful for finding the weakest link in a chain of repeaters.

Recording a Coverage Map

Simple approach: note GPS coordinates alongside SNR and RSSI values in a spreadsheet while driving, then export the data to Google My Maps or another mapping tool.

Automated approach: enable the Meshtastic Range Test module (Config → Module → Range Test). It automatically logs positions with signal data to a CSV file as you walk or drive the area. In a range test the fixed node acts as the Sender and the mobile node acts as the Receiver - the Receiver is the one that logs the CSV with GPS.

Visualisation: import the CSV into Google My Maps or QGIS to produce a signal-strength overlay map that you can compare directly against your predicted coverage.

What to Look For

• Expected coverage but no packets: interference, antenna issue, wrong modem preset, or an obstruction absent from the terrain model.
• Better-than-expected coverage: diffraction over a ridge, reflections from buildings or open water.
• Unexpected dead zones: metal structures, buildings with metal roofing, or terrain features not captured in SRTM data (SRTM is coarse ~30 m surface-model data, so small obstructions are easily missed).

Iterating on the Design

If field testing reveals coverage gaps, consider: adding a second repeater as a relay node, increasing antenna height, or repositioning the existing repeater. A 10-metre increase in antenna height can eliminate a surprisingly large dead zone - elevation is often more valuable than additional TX power.

Mesh Network Capacity and Congestion

LoRa Channel Capacity

LoRa is a low-data-rate technology. Unlike Wi-Fi, the RF channel is shared by all nodes simultaneously using a CSMA-like approach combined with Meshtastic's managed flooding mesh mechanism (every node rebroadcasts packets that still have hop limit remaining; there is no routing table). Understanding channel capacity helps you design a network that doesn't saturate itself.

Airtime Utilisation Metrics

Meshtastic displays Channel Utilization and Air Utilization percentages in the app. These are your primary indicators of network load. Channel Utilization is measured over a rolling 1-minute window, and the app colour-codes it: green below 25%, orange 25 - 50%, and red above 50%.

• Channel Utilization < 25% (green): healthy. Around the 25% mark the firmware begins to self-throttle - it defers its own transmissions to avoid colliding on a busy channel, so packets are delayed (queued), not dropped outright.
• Channel Utilization 25 - 50% (orange): busy/degrading. Expect added latency as nodes back off and defer.
• Channel Utilization > 50% (red): congested. Sustained load at this level risks queue overflow and real packet loss.
• Air Utilization TX: the fraction of time your node spends transmitting. Keep it low (a few percent is a reasonable target); a high value means your node is contributing a lot of airtime - reduce its broadcast intervals. (There is no documented hard "15%" Air Utilization rule.)

Sources of Traffic in a Mesh

• Position and NodeInfo broadcasts: nodes announce themselves periodically. Position and NodeInfo are separate broadcast types sent at different default intervals (NodeInfo is typically far less frequent than position). As a rough example, 50 nodes each sending a position packet on a 15-minute interval is one position packet roughly every 18 seconds (50 ÷ 900 s) on average - before any user traffic, and before the additional NodeInfo, telemetry, and rebroadcast load. (Verify the exact default intervals against your current firmware/preset, as they vary by role and modem preset.)
• User messages: text traffic generated by operators.
• Telemetry: device metrics (battery, voltage) and environmental sensor readings.
• ACKs and routing overhead: mesh protocol housekeeping packets.

Traffic Reduction Strategies for Dense Networks

• Increase position broadcast interval to 30 - 60 minutes on non-mobile nodes.
• Disable telemetry on nodes where it is not needed.
• Use the Medium Slow or Medium Fast preset - the higher data rate means each packet occupies the channel for less time, even if physical range is unchanged.
• Be deliberate about infrastructure roles. Both ROUTER and REPEATER rebroadcast with elevated priority (they will rebroadcast even after hearing another node do so), so neither is "less aggressive" than the other. The practical difference is that a REPEATER is headless - it does not run the client app or participate in the node database - not that it retransmits less. To actually cut redundant airtime, reduce the number of high-priority infrastructure nodes in range of each other and keep ordinary nodes in the default CLIENT role rather than promoting many of them to ROUTER/REPEATER.
• Limit hop count: most community networks set a maximum of 3 - 5 hops (the firmware default is 3, max 7). Longer hop chains amplify traffic because each hop retransmits every packet.

The Hop Storm Problem

If many nodes retransmit the same packet, a single user message can trigger a burst of dozens of transmissions across the mesh. Meshtastic uses duplicate-packet detection to suppress already-seen packets and prevent routing loops, but in dense networks already near maximum airtime utilisation, a sudden burst of messages can temporarily saturate the channel and cause widespread packet loss. Keeping hop counts low and broadcast intervals long is the primary mitigation.

Monitoring Your Network

Use the Channel Utilization and Air Utilization figures in the Meshtastic app to assess local network load before and after adding new nodes. If deploying a new repeater in a dense area, monitor whether its addition increases congestion - a new high-visibility, high-priority infrastructure node can increase channel load for every other node in range.