How to Commission a Point-to-Multipoint Radio Network

Back to Blog

Stand Up and Verify the Master

The master is the common element in every link, so a weak master penalizes the entire network. Mount and peak the master antenna first, usually an omnidirectional antenna so it can hear remotes in all directions, and confirm its height clears the local horizon toward the sites it must reach. Because the master's gain and coax loss appear in every remote's link budget, spend the effort here: a few dB lost at the master is a few dB lost on every single link at once.

Configure the master radio's channel, power, and network identity to the values your frequency plan and, for licensed operation, your license specify. Set the master as the polling controller so it, not the remotes, initiates each exchange, which is what keeps a shared channel collision-free. The architecture and roles are described in the reference on the point-to-multipoint radio network; commissioning turns that architecture into a working, addressed set of radios.

Before adding any remote, confirm the master is healthy on its own: it powers cleanly, its antenna reads a sensible standing-wave or return-loss figure, and it is transmitting on the intended channel at the intended power. A master with a bad connector or a wrong channel will make every remote look broken, so proving the master in isolation saves hours of chasing phantom remote faults later.

Add Remotes One at a Time

Resist the urge to energize every remote at once. Bring them online individually, and for each one verify the link the same way you would a point-to-point path: confirm Fresnel clearance, close the link budget, aim the remote's directional antenna on RSSI, and record the received level at both ends. Adding remotes one at a time means that when something misbehaves you know exactly which new site introduced it, instead of facing a network where any of a dozen radios could be the culprit.

Give every remote a unique address in the master's poll list, and double-check for duplicates, because two remotes sharing an address will collide and corrupt each other's replies in a way that looks like intermittent noise. As each remote comes up, confirm the master polls it and gets a clean reply before you add the next. Peak each remote's antenna carefully, following the antenna-aiming procedure, since a marginally-aimed remote is the kind of fault that hides until weather or foliage tips it over.

Watch the received level each new remote presents at the master. On a shared channel a remote transmitting far louder or far softer than its peers can be a symptom of a power-level or antenna problem, and grossly mismatched levels make the master's receiver work harder to follow the network. Bringing each site up to a sensible, consistent received level keeps the whole network balanced rather than lopsided toward whichever remote happens to be closest.

Tune Poll Pacing and Timeouts

The master polls remotes in sequence, so the total scan-cycle time is roughly the sum of each remote's poll, reply, and turnaround times. Set the per-remote timeout long enough that a healthy but slow or retried reply still lands inside its window, but not so long that one silent remote stalls the whole cycle waiting for a response that will never come. This balance is the heart of tuning a polled network, and it is developed further in the guide to setting the poll cycle for a radio network.

Size the scan cycle against your actual data-freshness requirement, not an arbitrary fast number. If operations need each remote's data updated every minute, the cycle must complete within a minute including retries; polling faster than the process needs just wastes airtime and battery on solar-powered remotes. Where a few points matter more than the rest, many masters allow polling critical remotes more often than the routine set, which concentrates airtime where it counts.

Set retry behavior deliberately. A remote that misses a poll should be retried a bounded number of times and then skipped for the rest of the cycle so it cannot hold the network hostage, with the master flagging it as failed. Too many retries per remote can blow the scan-cycle budget; too few can flag a merely fading remote as dead. Tune retries alongside timeouts so a transient miss recovers next cycle without one bad site starving the others of their turn.

Verifying the Result

The network is commissioned when every remote answers reliably across many consecutive scan cycles and the full cycle completes within your data-freshness target. Run the network for an extended period and confirm the poll-success rate is high for every remote, not just on average, because an average can hide one chronically weak site. A remote that answers most cycles but misses occasionally is a marginal link to fix now, before weather turns the occasional miss into a persistent outage.

Read the trends the way you read the poll log. Healthy remotes produce steady, gap-free trends at the scan cadence; a remote whose trend shows regular small gaps is telling you its link or its timing is marginal. Because the master is common to all, a fault that appears on every remote at once points at the master or its antenna, while a fault on one remote points at that site - the same shared-versus-isolated logic that localizes faults in any hub topology.

Capture baselines for every link: each remote's received level at the master and at the remote, the scan-cycle time, and the timeout and retry settings. These numbers are what a future dropout investigation compares against, adapted to a radio transport, and they turn a later performance complaint into a quick before-and-after comparison rather than a from-scratch survey.

Common Mistakes

The biggest mistake is under-investing in the master. Because its antenna gain and coax loss sit in every remote's budget, a mediocre master antenna or a lossy master feedline degrades the entire network uniformly, and no amount of work at the remotes recovers it. Peak and verify the master first and best.

A second mistake is energizing all remotes at once and then trying to sort out the resulting mess. Duplicate addresses, one weak site, and a timing problem all look similar in a fully-loaded network. Adding remotes one at a time keeps each new fault isolated to the site that caused it, which is dramatically faster to debug.

The third is tuning poll pacing for speed instead of for the process. Polling far faster than operations need burns airtime and solar-remote battery and increases collisions, while polling too slowly leaves data stale. Size the scan cycle to the real data-freshness requirement, set bounded retries so one silent remote cannot stall the cycle, and give critical points a faster sub-cycle only where it is genuinely justified.

Frequently Asked Questions