How to Test Direct and Relay Paths in a LoRa Mesh Communicator

Prepared by the ChatField Editorial Team. Evidence reviewed August 18, 2026.

A mesh communication test becomes difficult to interpret when the team does not know whether two endpoints exchanged information directly or through an intermediate device. The result may look successful in both cases, but the deployment decision is different.

A useful field test separates direct and relay paths, records every device position and repeats the same supported task under controlled conditions. It does not turn one route into a universal range promise.

This article is a general test framework. It does not state how many relays, hops or devices a future ChatField product supports.

Define the two path types

A direct path uses the tested communication path between two equipped endpoints without an intended intermediate relay. A relay path adds one or more supported intermediate devices according to the product design.

Do not infer the actual route from physical distance alone. Use product indicators, logs or a documented method where available. If the product cannot expose the path, label the result as observed communication with an unverified route.

The phone-to-mesh workflow and technology overview help identify system stages, but the exact relay behavior must be verified for the tested model.

Start with a direct baseline

Use two terminals and paired phones at close range. Record hardware, firmware, app, phone and operating-system versions. Confirm repeated supported exchanges in both directions.

Then move to planned checkpoints while keeping device position, carrying method and test script consistent. Record distance, elevation, buildings, vegetation, weather and movement.

Stop before the link becomes entirely unusable and preserve the last stable, marginal and failed checkpoints.

Add one intermediate device deliberately

Place the intermediate device at a documented checkpoint where the product instructions allow it to participate. Record whether the device is stationary, carried by a person or powered from another source.

Repeat the same endpoint task without changing more variables than necessary. If the result improves, it suggests the intermediate position helped under the tested conditions; it does not prove the same result everywhere.

If the product supports automatic route selection, note that the test may not be able to force a specific path without suitable diagnostic evidence.

Map every device

Create a simple route diagram with endpoint and intermediate positions, approximate spacing, elevation and obstructions. Add timestamps when people move.

A statement such as “three devices covered the route” is incomplete without positions. The same quantity can perform differently when one device is inside a vehicle, behind a ridge or carried near the ground.

Photographs can support the record if they do not reveal sensitive customer locations.

Repeat the same communication tasks

Choose a short supported test for each communication mode. Repeat it a defined number of times at each checkpoint and in each direction.

Record attempts, acknowledgements, delay, missing results, duplicates and recovery. Do not combine PTT, text, image and location into one pass/fail result.

If a mode is not supported by the tested product, remove it from the plan rather than assuming it will be added later.

Move the intermediate device

After a stable relay test, move the intermediate device gradually or between planned checkpoints. Observe when the route changes, becomes marginal or fails.

NIST’s archived research on rapidly deployable mesh networks discusses time-varying links and relay placement as test problems. The page states that it is no longer updated, so it should be treated as historical research context—not as a current product standard or ChatField evidence.

Record the effect of movement rather than claiming an automatic handoff unless the product exposes and supports that behavior.

Power the intermediate device off

During a safe controlled exercise, power off the intended relay and observe endpoint behavior. Record whether communication stops, falls back to a direct path, uses another available device or recovers after restart.

Do not create a real-world safety dependency for this test. Use non-emergency messages, an approved location and a separate communication method for exercise control.

Repeat the recovery procedure and identify what users must do.

Test more than one route shape

A straight route is only one geometry. Where relevant and safe, test around a structure, across elevation change or with endpoints moving in different directions.

Keep the scope manageable. A new geometry should answer a defined buyer question, not produce a collection of incomparable screenshots.

Attach every observation to the exact route and configuration.

Control phone and app variables

A phone-paired system can appear to have a radio problem when the actual issue is Bluetooth, app background behavior, phone permissions or battery settings.

Verify the phone-to-terminal connection at each device before interpreting the mesh result. Record screen lock, airplane mode, Bluetooth and data settings.

The current J25 product path and J25 documentation are model-specific references. They do not establish relay behavior for a future model.

Separate range from reliability

The farthest successful attempt is not the same as a reliable operating boundary. A buyer needs repeated results, failure rate, recovery and route variation.

Define the acceptable outcome before testing. A field team may prefer a shorter repeatable route over an occasional maximum.

Do not claim a guaranteed minimum or maximum without appropriate model-specific evidence and stated conditions.

Use an after-action review

CISA’s communications exercise methodology emphasizes objectives, participant roles, evaluation and corrective actions. After the test, identify which result was expected, what actually happened, the likely cause, the owner and the retest.

Separate confirmed causes from hypotheses. “The ridge blocked the link” should remain a hypothesis unless the test design supports that conclusion.

Direct and relay test checklist

• Exact terminals, phones, firmware and app versions
• Direct-path baseline and repeated attempts
• Endpoint positions, movement and carrying method
• Intermediate device identity and position
• Route diagram, elevation and obstructions
• Same task repeated in each direction
• Each supported mode tested separately
• Intermediate movement test
• Intermediate power-loss and recovery test
• Phone-to-terminal connection verified
• Stable, marginal and failed checkpoints preserved
• Corrective actions and controlled retest

ChatField evaluation boundary

Use the ChatField contact page to request current relay and evaluation information. This article does not promise a relay count, hop count, automatic routing behavior, range or field result for a future ChatField product.

Sources reviewed

• CISA: Communications-Specific Tabletop Exercise Methodology
• CISA: Emergency Communications Guidance
• NIST archived research: Real-Time Deployment of Mesh Networks
• NIST: Wireless Systems Metrology

CISA and NIST do not endorse ChatField or its products. The NIST mesh page is archival and is cited only for historical testing context.