Evaluate the AutomationView desktop suite free for 30 days. No credit card required. Claim trial key →
arrow_back Back to Articles

Inside Modbus RTU Latency: Calculating Transmission Times

calendar_month
person Carvalho Raphael

Inside Modbus RTU Latency: Calculating Transmission Times

Calculator
%%{init: {'theme':'dark', 'themeVariables': { 'background': '#001c38' }}}%%
flowchart LR
    A[Start Bit] --> B[8 Data Bits]
    B --> C[Parity Bit]
    C --> D[Stop Bit]
    D --> E[t1.5 Delay]
    E --> F[Next Char]
    style A fill:#003366,color:#ffffff,stroke:#001f3f,stroke-width:2px
    style B fill:#00509e,color:#ffffff,stroke:#003366,stroke-width:2px
    style C fill:#0074d9,color:#ffffff,stroke:#00509e,stroke-width:2px
    style D fill:#4da6ff,color:#000000,stroke:#0074d9,stroke-width:2px
    style E fill:#e6f2ff,color:#000000,stroke:#80bfff,stroke-width:2px,stroke-dasharray: 5 5
    style F fill:#00509e,color:#ffffff,stroke:#003366,stroke-width:2px
AutomationView Icon AutomationView

Key Takeaways

  • The standard Modbus RTU character consists of 11 bits.
  • Baud rate determines the raw character transmission time.
  • Inter-character (t1.5) and inter-frame (t3.5) delays are mandatory for message framing.
  • For baud rates above 19200, strict timers switch to fixed intervals (750µs and 1.75ms).

When dealing with high-speed polling across a daisy-chained RS-485 network, ignoring the strict timing rules of Modbus RTU will result in CRC errors and dropped packets. Understanding the exact latency introduced by the physical layer is critical before optimizing SCADA update rates or configuring PLC timeout settings. A reliable Modbus RTU transmission time calculator relies heavily on standard formulas for character timing, t1.5, and t3.5 delays.

Understanding Modbus Character Framing

In Modbus RTU, the most common byte transmission format utilizes 11 bits per character. This typically includes one start bit, eight data bits, one parity bit (Even or Odd), and one stop bit. When parity is disabled, the standard dictates replacing it with a second stop bit to maintain the 11-bit constraint.

The time required to transmit a single character on the bus is dictated entirely by the baud rate. For instance, at 9600 baud, 9600 bits are pushed across the copper per second.

Character Time Formula

To establish the baseline latency, divide the total bits per character by the baud rate, then multiply by 1000 for milliseconds.

Character Time (ms) = (11 bits / Baud Rate) × 1000

If we apply this to a standard 9600 baud link: (11 / 9600) × 1000 = 1.146 ms per byte.

The t1.5 and t3.5 Timing Constraints

Unlike ASCII protocols that use specific start and end characters, Modbus RTU relies on absolute silence to delimit messages. The receiver measures the time between consecutive bytes to determine if the frame is ongoing or complete.

sequenceDiagram
    participant Master
    participant Bus
    participant Slave
    Master->>Bus: Byte 1
    Note over Bus: Inter-character >Bus: Byte 2
    Note over Bus: End of Transmission
    Note over Bus: Silent period >= t3.5
    Slave-->>Master: Process & Reply

Inter-Character Delay (t1.5)

The t1.5 delay specifies the maximum allowed gap between two bytes within the same message. If the delay exceeds 1.5 times the character time, the receiving device will assume the message is corrupted, flush its buffer, and prepare for a new frame. At 9600 baud, this timeout is strictly 1.719 ms.

Inter-Frame Delay (t3.5)

The t3.5 delay acts as the end-of-message marker. A silent period equal to or greater than 3.5 character times indicates to all nodes on the network that the previous transmission is complete and the bus is idle. At 9600 baud, the minimum silent time is 4.01 ms.

The High Baud Rate Exception

A frequent mistake when designing a Modbus RTU transmission time calculator is applying the t1.5 and t3.5 multipliers to high baud rates. According to the official Modbus over Serial Line specification, hardware timers become difficult to manage accurately at speeds above 19200 bps.

To solve this, the protocol enforces fixed timing intervals for any baud rate exceeding 19200 (such as 38400, 57600, or 115200 bps).

Baud Rate t1.5 (Max gap between bytes) t3.5 (Min gap between frames)
9600 bps 1.719 ms 4.010 ms
19200 bps 0.859 ms 2.005 ms
> 19200 bps 750 µs (Fixed) 1.75 ms (Fixed)

Field Realities: Processing and Turnaround

Calculated transmission latency represents only the physical wire time. In practice, you must account for the slave device’s processing latency (the turnaround time). Many older PLCs or low-power field devices require anywhere from 10 ms to 50 ms to parse a read request, fetch the internal register data, format the response frame, and toggle the RS-485 transceiver direction pin.

Always incorporate a safety margin when configuring SCADA polling cycles. A common engineering practice is configuring the master’s timeout to at least double the calculated round-trip wire time plus the known slave turnaround time.

Conclusion

Proper serial network optimization requires precise calculations. Relying on default polling rates often leads to saturated bandwidth or frequent communication faults on RS-485 segments. By applying the correct formulas for character timing, t1.5, and t3.5 delays, engineers can push their networks to the maximum theoretical throughput without compromising reliability.

Are you looking to optimize your industrial communication setups further? Explore our HMI Templates to integrate precise diagnostic dashboards directly into your operator interfaces.

FAQ

Why does Modbus RTU use 11 bits per character?

The standard ensures a consistent data envelope. It includes 1 start bit, 8 data bits, 1 parity bit, and 1 stop bit. If parity is set to ‘None’, the standard requires an extra stop bit to maintain the 11-bit structure.

What happens if the t1.5 timer is exceeded?

The receiving device considers the current frame incomplete or corrupted, flushes its reception buffer, and assumes the next byte received is the start bit of a new message.

Why are the t1.5 and t3.5 timers fixed above 19200 baud?

At high baud rates, the character times become so brief that many microcontrollers cannot accurately service the UART interrupts fast enough. Fixed timers (750µs and 1.75ms) provide a predictable, easily implemented tolerance.

Share this article

Stay Updated with Calculator

Get the latest articles and news delivered directly to your inbox.

Log in to Subscribe

You must be registered and logged in to manage subscriptions.

Recommended for you

Inside Single Pair Ethernet (SPE): Architecting 10BASE-T1L for PLC Networks

Learning
%%{init: {'theme':'dark', 'themeVariables': { 'background': '#001c38' }}}%%
flowchart LR
    A[Main PLCnStandard Ethernet] --> B(SPE Switch / PSE)
    B -- "10BASE-T1L + PoDL" --> C[SPE Field Sensor]
    B -- "10BASE-T1L + PoDL" --> D[SPE Actuator]
    style A fill:#2e5b8e,color:#fff
    style B fill:#e67e22,color:#fff
    style C fill:#27ae60,color:#fff
    style D fill:#27ae60,color:#fff
AutomationView Icon AutomationView
calendar_month

Inside Single Pair Ethernet (SPE): Architecting 10BASE-T1L for PLC Networks

Replacing legacy 4-20mA systems with IP-based networks has always been a challenge in the process industries due to distance limits. Single Pair Ethernet (SPE), specifically the IEEE 802.3cg 10BASE-T1L standard, fundamentally changes this by delivering power and 10 Mbps Ethernet over a single twisted pair up to 1,000 meters. This shifts the automation paradigm from […]

Read Article arrow_forward

Mastering OPC UA PubSub over MQTT: A Practical Guide

Learning
%%{init: {'theme':'dark', 'themeVariables': { 'background': '#001c38' }}}%%
flowchart LR
    subgraph ot_network ["OT Network"]
        PLC["Legacy PLC"]:::blue
        Edge["Edge Gateway"]:::green
    end
    subgraph it_network ["IT Network"]
        Broker["MQTT Broker"]:::red
        Cloud["Cloud Analytics"]:::blue
    end

    PLC -->|Modbus/TCP| Edge
    Edge -->|"OPC UA PubSub over MQTT"| Broker
    Broker -->|Subscribe| Cloud

    classDef blue fill:#2563eb,stroke:#fff,stroke-width:2px,color:#fff;
    classDef green fill:#16a34a,stroke:#fff,stroke-width:2px,color:#fff;
    classDef red fill:#dc2626,stroke:#fff,stroke-width:2px,color:#fff;
AutomationView Icon AutomationView
calendar_month

Mastering OPC UA PubSub over MQTT: A Practical Guide

The gap between the plant floor and the cloud is closing, but moving data reliably remains a core challenge. Integrating OPC UA PubSub over MQTT offers a powerful solution, combining the structured data modeling of OPC UA with the scalable, event-driven messaging of MQTT. This architecture is quickly becoming the backbone of modern IIoT implementations. […]

Read Article arrow_forward

Encoder Pulse Frequency Calculation: A Technical Guide

Calculator
%%{init: {'theme':'dark', 'themeVariables': { 'background': '#001c38' }}}%%
flowchart LR
    A[Motor SpeednRPM] --> B[Encoder ResolutionnPPR]
    B --> C{QuadraturenDecoding}
    C -- x1 --> D[Base FrequencynkHz]
    C -- x4 --> E[Max HSC LoadnkHz]
AutomationView Icon AutomationView
calendar_month

Encoder Pulse Frequency Calculation: A Technical Guide

TL;DR: Specifying an encoder for motion control requires exact math to prevent PLC signal loss. Calculating the baseline encoder pulse frequency calculation ensures your High-Speed Counter (HSC) input card can keep up with maximum motor RPM, particularly when utilizing x4 quadrature decoding. The Physics of Encoder Pulse Frequency Calculation In motion control, mismatched hardware specifications […]

Read Article arrow_forward