How to Perform a Proper Meshtastic Range Test

A repeatable procedure for measuring practical range without turning one lucky packet into a coverage claim.

Define the question

“How far does Meshtastic reach?” is not a complete test question. Define the two endpoints, modem preset, antennas, antenna heights, terrain and required delivery quality. A record-distance experiment, a mobile-user coverage test and acceptance of a public relay are different exercises.

Control the equipment

Use known, fully charged nodes with the correct regional setting and identical compatible modem parameters. Record firmware, transmit power, antenna model, connector adapters and physical orientation. Place the fixed antenna exactly as it will operate. Keep the mobile node in a consistent position; moving it from a dashboard to outside the vehicle can change the result more than the distance does.

Verify operation at short range before leaving the site. Attach antennas before power-up and avoid transmitting into a disconnected or unsuitable load.

Use numbered transmissions

The Meshtastic Range Test module can transmit GPS-bearing test packets at an interval and receivers can log incoming results to CSV. At least one sender and one receiver are required. Choose a lawful, restrained interval and disable the module after testing because automated traffic consumes shared airtime.

Whether using the module or manual messages, use sequence numbers and record the total sent. At each checkpoint, remain stationary long enough for several transmissions. Record both directions, not merely whether the remote node appears in a list.

Separate direct from relayed packets

A packet delivered through an intermediate node proves mesh connectivity, not a direct link between the endpoints. For a site-specific range test, use a controlled environment or inspect hop information so relayed results can be excluded or labeled. For an end-to-end network test, retain the path because relay availability is part of the service being measured.

Sample beyond the first failure

Start with a known-good short path.
Test along several bearings rather than one convenient road.
Stop at planned distances and terrain transitions.
Send enough packets to calculate a useful delivery ratio.
Continue through the first failure; a local obstruction may create a temporary shadow.
Return through selected points to expose time or orientation effects.

Report a result people can reproduce

Include	Avoid
Endpoints, terrain and antenna heights	Distance alone
Preset, band, power and firmware	“Default settings” without a date
Packets sent, received and direction	Only the best successful packet
Direct or relayed status	Assuming every delivery was direct
RSSI/SNR distribution	One screenshot as proof of service

A defensible result might say that 46 of 50 direct packets were received from A to B and 42 of 50 from B to A at a named checkpoint under documented conditions. That is much more useful than “we reached 18 km.”

Choose an interval responsibly

The interval must provide enough observations without flooding the shared channel or violating regional duty-cycle requirements. Slower LoRa presets give each packet more airtime, and relays may multiply a test packet across the mesh. Coordinate public-network tests, avoid peak periods and use the lowest traffic that answers the question. Record the interval because it affects collision probability and the number of samples.

Treat the return path as a separate result

Do not infer B-to-A performance from A-to-B reception. Swap sender and receiver roles or run a coordinated bidirectional sequence. If acknowledgements are used, understand what they prove and whether they returned through the same path. Report directional delivery ratios separately.

Before publishing a maximum distance, repeat the endpoint, include the failed attempts and describe terrain and antenna height. A repeatable moderate-distance link is more valuable to network planners than a lucky contact produced by exceptional conditions.

Related testing guides

Official sources

Firmware, applications and documentation change over time. Confirm current setting names and applicable regional rules before commissioning or changing live infrastructure.