How to Commission a Store-and-Forward Repeater

Back to Blog

Verify Each Hop as an Independent Link

A repeater is only as good as its weakest hop, so treat the master-to-repeater path and the repeater-to-remote path as two separate links, each with its own Fresnel clearance and its own link budget. Run the path verification and budget math for both hops before you accept the site, because a repeater that is perfectly placed for the remotes but marginal back to the master simply moves the failure point rather than fixing it. The whole reason you added the relay is that the direct path failed one of these checks; make sure both new hops pass.

At the repeater, aim the antenna facing the master and the antenna facing the remotes separately, peaking each on its own received-signal reading. A repeater often uses a directional antenna toward the master and an omnidirectional antenna toward a spread of remotes, or two directionals for a linear chain. Keep the two antennas physically separated and, where possible, cross-polarized or frequency-separated enough that the repeater's own transmit does not desensitize its own receive, which is a classic self-interference trap on a shared mast.

Confirm each hop's received level against its predicted budget value, and record both. These two numbers are your baseline: if the link degrades later, comparing the live received level on each hop against these commissioning figures tells you which hop moved. This is the same verify-against-prediction discipline used when you first size the link budget, extended across the two-hop relay.

Set the Repeater's Relay Mode

Repeaters relay in one of two broad styles, and you must configure the one your network expects. A simple digipeat, or on-frequency repeat, re-transmits whatever it hears with minimal processing, effectively extending the coverage of a single channel. A true store-and-forward repeater receives a complete message, holds it, and re-transmits it on the outbound hop, which allows different channels or timing on each hop and, crucially, lets the repeater buffer traffic when the onward link is momentarily busy or down. The distinction and its buffering behavior are covered in the reference on store-and-forward telemetry.

Match the relay configuration to how the master polls. In a polled network the master addresses each remote in turn, and the repeater must pass both the outbound poll and the inbound reply without collisions. Set any hold-off or turnaround timers so the repeater is not still transmitting when a reply is due, and confirm the addressing so the repeater forwards to the correct remotes rather than looping messages. Where the radios support it, enable listen-before-talk so the repeater defers to an in-progress transmission instead of stepping on it, a behavior explained under listen-before-talk.

If the repeater serves a group of remotes rather than a single onward site, it is effectively the hub of a point-to-multipoint sub-network, and its timing has to accommodate all of them. Set the poll pacing so the slowest remote behind the repeater still gets its turn within the master's scan cycle, and leave headroom so a retry does not push a later remote out of the cycle.

Test Buffering and Prove End-to-End Polling

With both hops verified and the relay mode set, bring the remotes online through the repeater and confirm the master polls every one of them successfully. Watch a full scan cycle and check that each remote behind the repeater answers within its expected window, with no address it cannot reach. Reliable answers from every remote across several cycles are the baseline proof that the two-hop path is carrying live SCADA traffic, not just a single test message.

The store-and-forward behavior is the part people skip and later regret, so test it deliberately. Briefly interrupt the onward hop - power down a remote, or disconnect its antenna in a controlled way - then restore it, and confirm that buffered data queued at the repeater or the remote is delivered on recovery rather than lost. In a true store-and-forward design the queued readings should arrive in order once the link returns, which you can see as the gap in the trend filling in after reconnection.

Finally, measure the extra delay the relay adds. Each hop and each store-and-forward hold adds latency, and a long polled network behind a repeater can push the round-trip time toward the edge of the master's timeout. Confirm the master's per-remote timeout is set generously enough for the two-hop path so a healthy but slow reply is not mistaken for a failed remote, and note the observed round-trip so future timeout tuning has a real number to work from.

Verifying the Result

Declare the repeater commissioned only when three things are true together: both hops read received levels close to their budget predictions, every remote behind the repeater polls reliably across many cycles, and a forced outage demonstrates that queued data is buffered and forwarded on recovery. Any one of those failing means the relay is not yet trustworthy, however good the other two look.

Let the network run and watch the trends for the remotes behind the repeater. A healthy relay produces clean, gap-free trends with the same cadence as directly-connected remotes; recurring gaps that all the repeater's remotes share point back at the repeater or its hops, while a gap on one remote alone points at that remote. This shared-versus-isolated pattern is the fastest way to localize a future fault to the repeater.

Record the commissioning baselines - both hop received levels, the observed round-trip time, and the timeout settings - in the site documentation. When someone diagnoses this repeater months later, those numbers turn a vague hunt into a direct comparison, and they are exactly what a systematic dropout investigation relies on when the transport is radio rather than cellular.

Common Mistakes

The most common mistake is commissioning only the hop you can easily test and assuming the other is fine. A repeater has two hops and both must independently clear their path and budget; a marginal hop back to the master will drop traffic even when every remote reads strong. Verify both, and record both baselines.

A second mistake is self-interference on the repeater mast. When the repeater's transmit antenna is too close to, or too co-polarized with, its receive antenna, the repeater deafens itself and performance is far worse than either hop's budget predicts. Separate the antennas, use polarization or frequency separation, and confirm the repeater still hears the far end while it is transmitting.

The third is never testing the store-and-forward recovery. A repeater configured for digipeat but expected to buffer, or one whose queue is too small, will silently drop data during the very outages it was meant to ride through. Force an outage during commissioning and watch the trend fill back in, so you know the buffering works before you depend on it.

Frequently Asked Questions