AJapps

Serial Line & Polling Cycle Calculator (Modbus RTU, RS-485)

How long does it take to poll every device on an RS-485 line or a radio link? Character time from the baud rate and framing, the Modbus RTU inter-frame gap, the time per transaction and the full polling cycle — compared with the scan time the SCADA or gateway needs.

Serial line

Polling

ms
ms

Requirement and failures

s
ms
Polling cycle
2.13 s — slower than required

Line

Bits per character11
Character time1.15 ms
Modbus t1.5 / t3.51.72 ms / 4.01 ms

Transaction

Request 8 bytes9.17 ms
Response 45 bytes51.56 ms
Per transaction88.75 ms

Cycle

Polling cycle vs required2.13 s / 2 s ✗
Full updates per second0.47
Line busy sending data68 %

Notes

  • The cycle (2.13 s) is longer than the required scan time (2 s). Raise the baud rate, read more registers per request, poll slow-changing data less often, or split the devices over more ports.
Tool guide · know before you use

What this tool is, how it works and how far to trust it

A calculator for the polling time of serial SCADA links: character time, Modbus RTU gaps, transaction time and the full polling cycle for N devices.

Read this before relying on a result. Every method, formula, assumption and limit is stated here, so you can check the answer yourself instead of accepting it blindly.

What it can do

  • Compute the character time from baud rate, data bits, parity and stop bits.
  • Give the Modbus RTU t1.5 and t3.5 gaps and the request and response lengths for function 03/04.
  • Add device turnaround and radio or WAN delay, and give the polling cycle, updates per second and line utilisation, including time-outs of offline devices.

Why you need it

  • Slow updates on serial lines are usually a polling-budget problem, and adding 'just one more device' can push the cycle past the required scan time.
  • The calculation shows which term dominates — baud rate, number of requests, turnaround or link delay — so the fix targets the right one.

Understand this first

  • Each character carries a start bit, data bits, an optional parity bit and stop bits: 11 bits per byte for Modbus RTU.
  • Many small requests cost more than one large one, because every request pays the gaps, the turnaround and the link delay.
  • An offline device costs a full time-out on every poll until it is taken out of scan.

What you need before you start

  • Line settings (baud, data bits, parity, stop bits), number of devices and requests per device, registers per request or frame sizes.
  • Device turnaround time (from the manual or a line analyser) and the link delay of radios or modems.
  • A current browser (Chrome, Edge, Firefox or Safari). Nothing is installed and your data is never uploaded; it is processed on your own computer.

How to use it

  • Set the line parameters and choose Modbus RTU (or enter frame sizes for another protocol).
  • Enter the number of devices, requests per device and registers per request, the device turnaround and any link delay.
  • Enter the required scan time and the time-outs you expect from offline devices.
  • Read the cycle against the requirement and the notes on what to change.

What you get

  • Character time, t1.5/t3.5, request, response and transaction times, the polling cycle against the required scan time, updates per second and line utilisation.

How to read the results

  • Cycle longer than the scan time: read more registers per request, poll slow data less often, raise the baud rate, or split devices over more ports.
  • Low line utilisation with a long cycle means delays (turnaround, radio latency) dominate, not the baud rate.

Technical basis

  • Character time = (1 + data + parity + stop bits) / baud.
  • Modbus over Serial Line V1.02: t1.5 = 1.5 characters and t3.5 = 3.5 characters, fixed at 0.75 ms and 1.75 ms above 19 200 baud.
  • Function 03/04: request 8 bytes; response 5 + 2 × registers bytes; at most 125 registers per request.
  • Transaction = request + t3.5 + link delay + turnaround + response + link delay + t3.5; cycle = transactions × polls + time-outs.

Limits: when not to rely on it

  • Turnaround times vary by device and request; measure them for an exact budget.
  • Does not model collisions, retries after CRC errors or report-by-exception protocols (DNP3 unsolicited, IEC 101 balanced mode).

For preliminary engineering use. Results must be checked by a qualified engineer against the project's standards. How results are checked · Terms & disclaimer · Build 424d8a2 · 2026-11-12