On a poll-response protocol, the single most important number is often not bandwidth but how long each request takes to come back. That number is the round-trip time, and it quietly sets the ceiling on a SCADA channel.
Round-Trip Time (RTT) in one line: Round-trip time (RTT) is the elapsed time from when SCADA sends a poll to when it receives the response - the full there-and-back delay of one request. It includes transmission time, propagation through the network, and the device's turnaround time to process and reply. On request-response protocols, RTT is usually the limiting factor for how many devices a channel can poll in a given scan cycle, more than raw bandwidth.
RTT is the sum of several delays. First, the time to actually transmit the request bits, which on a slow serial link at 9600 baud is significant. Second, propagation and network delay, which on satellite can be over half a second just for the signal to travel up and back. Third, the device's turnaround time - how long the RTU or PLC takes to receive the request, prepare the data, and start replying. Then the same path back for the response.
On a fast wired link RTT is a few milliseconds and barely noticed. On cellular it is hundreds of milliseconds; on geostationary satellite it can approach a second. Because a poll cannot be considered complete until the response returns, RTT is a hard, per-request cost that the SCADA pays on every poll regardless of how little data is involved.
A polling SCADA usually reads devices sequentially on a channel - it sends a poll, waits for the response, then moves to the next device. The total scan cycle is therefore roughly the number of polls multiplied by the average RTT. If each round trip takes 400 milliseconds and a channel serves 30 devices, one pass takes at least 12 seconds before RTT overhead and retries are even counted.
This is why RTT, not bandwidth, is the usual constraint. The payloads are tiny; the cost is waiting for each turnaround. It is also why poll grouping matters so much - combining many points into one request means one RTT instead of many. And it is why report-by-exception is attractive on high-RTT links: eliminating routine polls removes the round trips entirely, letting devices report only when something changes.
Field SCADA channels frequently carry many remote sites over a single high-RTT medium - licensed radio, cellular, or satellite. Understanding RTT tells an engineer how many sites a channel can realistically serve at a target update rate, and whether that update rate is even achievable. A design that ignores RTT and simply adds devices will find its scan cycle stretching past the interval operators expect.
RTT also drives timeout and retry settings. The comms-fail timeout and the driver's per-poll timeout must be set longer than the worst-case RTT, or normal slow responses will be misread as failures, producing nuisance alarms and needless retries. On satellite in particular, timeouts tuned for a wired link will fail constantly.
When RTT makes straight polling too slow to cover a growing field, operators shift strategy: enable unsolicited or report-by-exception reporting so devices push changes instead of being polled, tighten poll groups to cut round trips, or split sites across additional channels. All three are responses to the same underlying constraint - the unavoidable cost of the round trip.
No. Bandwidth is how much data per second a link can carry; RTT is how long one request takes to come back. On SCADA polling with small payloads, RTT is usually the binding constraint - the channel spends its time waiting for turnarounds, not moving large amounts of data.
A geostationary satellite sits about 36,000 km up, so a signal must travel up and back down for the request and again for the response. That distance alone adds roughly half a second per one-way trip, pushing RTT toward a second before any processing delay.
Cut the number of round trips: group many points into single poll requests, and switch from routine polling to report-by-exception so devices report only on change. You can also spread sites across more channels. All of these attack the per-request round-trip cost rather than bandwidth.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.