How to Set the Poll Cycle for a Radio Network

Back to Blog

Budget the Per-Remote Poll Time

Start by understanding where the time goes for a single remote. Each poll costs the airtime to send the request, the remote's processing time, the airtime for the reply, and the radio turnaround time as each end switches between transmit and receive. On a slow-baud telemetry channel the message airtime dominates and depends on how many registers you read, so a remote polled for a large block of data takes proportionally longer than one polled for a handful of points. Measure or estimate this per-remote time honestly, because the whole cycle is built from it.

Multiply the per-remote time by the number of remotes to get the base scan-cycle time with no retries. This is the floor: even if every remote answers first try, the cycle cannot complete faster than this sum on a shared channel where only one exchange happens at a time. If that floor already exceeds your data-freshness requirement, no amount of timeout tuning will save you - you need fewer points per poll, a faster channel, or the network split into parallel sub-networks. Knowing the floor first prevents chasing timing that is physically impossible.

Account for the transport's inherent delays. A network with a repeater adds hop and store-and-forward time to every remote behind it, and protocol overhead adds bytes to every message. These are covered in the reference on store-and-forward telemetry; for poll-cycle budgeting, the point is that the real per-remote time includes the transport's delays, not just the ideal airtime.

Tune Timeouts and Retries

Set each remote's timeout just longer than its normal reply time, with a small allowance, so a healthy but slightly slow response still lands inside the window while a truly failed remote is declared missing quickly. A timeout set too short flags good remotes as failed and triggers needless retries that bloat the cycle; a timeout set too long makes the master wait pointlessly on every dead remote, so a single failed site drags out the whole scan. The timeout is the knob that most directly controls how gracefully the cycle handles a silent remote.

Bound the retries so a missing remote cannot hold the network hostage. A sensible pattern is a small number of retries per remote within the cycle, after which the master marks the remote failed and moves on, retrying it fully next cycle. This lets a transient miss - a momentary fade - recover on the retry without letting a genuinely dead site consume the airtime that other remotes need. Too many retries per remote can, in the worst case, let a couple of dead sites blow the entire cycle budget; too few can flag a merely fading remote as dead too readily.

Enable channel-access etiquette where the radios support it. Listen-before-talk lets the master and remotes defer to an in-progress transmission instead of colliding, which matters most on a busy shared channel where collisions otherwise force retries and inflate the cycle. Collisions are self-inflicted airtime loss, so etiquette that avoids them directly protects your poll-cycle budget.

Prioritize Critical Points

Not every point needs the same freshness, and treating them all equally wastes airtime. A safety-relevant pressure or a fast-moving level may need updating far more often than a slowly-drifting temperature or a daily total, so rather than speeding up the whole cycle to satisfy the few urgent points, poll those on a faster sub-cycle. Many masters let you define a fast scan for a small critical set that runs several times within each full scan of everything, which concentrates airtime where it earns its keep.

Match the polling rate to what the process and the operators actually use. Polling a slow-changing value every few seconds produces mountains of redundant data, burns shared airtime, and drains the batteries of solar-powered remotes with power budgets to respect. Polling a fast-changing critical value too slowly means an alarm arrives late. The right rate for each point is the rate at which its data is genuinely acted upon, which is usually a spread of rates across the network rather than one number.

Consider report-by-exception where the radios and protocol support it, as an alternative or complement to strict polling. A remote that reports only when a value changes beyond a deadband, rather than answering a poll every cycle, frees airtime for the points that do change, which can dramatically improve effective freshness on a busy channel. The trade is that you must still confirm liveness of quiet remotes, typically with a periodic integrity poll, so silence means healthy rather than dead.

Verifying the Result

Confirm the tuned cycle meets its target by measuring the actual scan time in operation, not just the calculated budget. Watch several full cycles and check that the master completes each within your data-freshness requirement including the normal rate of retries, and that every remote's data updates within its own required interval. A cycle that meets the target on a quiet day but blows past it whenever a couple of remotes fade is under-provisioned and needs tighter timeouts or fewer retries.

Check the poll-success rate per remote, because a healthy cycle time hides trouble if it is achieved by a remote quietly failing every cycle. Every remote should answer reliably, and any site with a chronically low success rate is a marginal link to fix at the antenna or the budget, not a timing problem to paper over with more retries. The trend tells the same story: gap-free trends at the intended cadence mean the cycle is working; regular gaps on one remote mean that link, gaps on all remotes at once mean the master or the cycle itself.

Re-verify after any change to the network. Adding remotes lengthens the base scan, adding points per poll lengthens per-remote time, and adding a repeater adds hop delay, so a cycle tuned for the old network may miss its target on the new one. Treat the poll cycle as something you re-budget whenever the network grows, using the same per-remote-time-times-count arithmetic you started with.

Common Mistakes

The most common mistake is tuning for the fastest possible cycle instead of the freshness the process needs. Polling everything as fast as the channel allows burns shared airtime and solar-remote battery, increases collisions, and produces redundant data, while delivering no benefit the operators use. Size the cycle to the real data-freshness requirement, and poll only the genuinely urgent points faster.

A second mistake is setting timeouts and retries carelessly. A timeout too short flags good remotes as failed; too long makes every dead remote drag out the scan. Too many retries let a couple of dead sites blow the whole budget; too few flag fading remotes as dead. These knobs interact, so tune them together against the measured per-remote reply time.

The third is forgetting to re-budget after the network grows. Because the base scan is per-remote time times the number of remotes, adding sites or points silently lengthens the cycle, and a network that met its freshness target at commissioning can drift out of spec as it expands. Re-run the arithmetic whenever the network changes rather than assuming the original tuning still holds.

Frequently Asked Questions