Modbus RTU vs ASCII Transmission Mode
Serial Modbus defines two transmission modes for putting the same protocol on a wire: RTU and ASCII. They carry identical function codes and data but frame and encode them completely differently, which is why a master set to RTU cannot talk to a device set to ASCII even though both are Modbus. This reference explains how each mode frames a message, how their checksums differ, and when an engineer meets ASCII in the field instead of the far more common RTU.
Modbus RTU vs ASCII Transmission Mode in one line: Modbus RTU and ASCII are the two serial transmission modes of the same protocol. RTU sends each byte as compact binary, frames a message by timing (a silent gap before and after), and ends it with a 16-bit CRC. ASCII sends every byte as two printable hex characters, frames a message with a colon start and a carriage-return-line-feed end, and uses a simpler longitudinal redundancy check. Both must match on every device on the bus.
How RTU Frames and Encodes a Message
In RTU mode every value is sent as raw binary, one byte per byte, so an eight-bit register byte takes exactly eight bits on the wire plus start, stop, and parity bits. There are no start or end characters in the data itself. Instead RTU frames a message by silence: the receiver treats a gap of at least three and a half character times as the boundary between one message and the next, and a gap of more than about one and a half character times inside a message as a framing error. This timing-based framing is compact and fast but sensitive to interruptions, which is why RTU turnaround and inter-frame gaps matter on slow links. The detail of that gap timing is covered in the Modbus serial response delay and turnaround reference.
RTU protects each message with a 16-bit cyclic redundancy check appended to the end. The transmitter computes the CRC over the address, the function code, and the data, and the receiver recomputes it and compares. A mismatch means the frame was corrupted on the line and the receiver silently discards it. Because the CRC catches burst errors well and adds only two bytes, RTU is the dominant serial form in the field today.
How ASCII Frames and Encodes a Message
ASCII mode encodes every byte as two printable hexadecimal characters, so the byte 0x2F is sent as the characters '2' and 'F'. That roughly doubles the message length compared with RTU and makes ASCII slower, but it also makes a capture human-readable, which historically eased debugging on simple terminals. Because the payload is printable text, ASCII does not need timing to find message boundaries.
Instead of relying on silence, ASCII marks each message explicitly: a colon character begins the frame and a carriage-return followed by a line-feed ends it. This means ASCII tolerates the timing gaps that would break an RTU frame, so it can survive on links with irregular latency where RTU struggles. Its checksum is a longitudinal redundancy check, a single byte computed by summing the message bytes, which is weaker than RTU's CRC but simpler to compute. The Modbus TCP vs RTU comparison places both serial modes against the Ethernet form.
When Each Mode Is Used
RTU is the default and the overwhelming majority of serial Modbus in service. It is faster on the same baud rate, its CRC is stronger, and every mainstream device and driver supports it. If you are choosing a mode for a new install and both ends support RTU, choose RTU.
ASCII survives mostly on legacy or specialized equipment, on links where the timing discipline of RTU cannot be met, or where a plain-text protocol is desired for easier troubleshooting on constrained hardware. When you meet ASCII, the practical rule is simply that every device on the same serial segment must agree on the mode, the baud rate, the data bits, the parity, and the stop bits. A single device set to a different transmission mode will appear dead to the rest of the bus because it cannot even find the frame boundaries, let alone the data.
Frequently Asked Questions
Can RTU and ASCII devices share the same serial bus?
No. The transmission mode is a property of the whole segment, not of an individual request. A device set to ASCII frames messages with a colon and CR-LF and expects printable hex, while an RTU device frames by timing and expects binary, so neither can parse the other's traffic. Every device on one RS-485 segment must use the same mode, baud rate, and serial parameters.
Why does ASCII use a colon at the start of each message?
Because ASCII does not use timing to find frame boundaries, it needs an explicit marker. The colon (hex 3A) signals the start of a message and the carriage-return line-feed pair signals the end. This is what lets ASCII tolerate the gaps in byte timing that would break an RTU frame, at the cost of roughly doubling the message length.
Is ASCII's checksum weaker than RTU's?
Yes. ASCII uses a longitudinal redundancy check, a single-byte sum-based check, while RTU uses a 16-bit CRC. The CRC catches burst errors far more reliably, which is one reason RTU is preferred despite ASCII being easier to read. If a link is noisy, RTU's CRC gives better protection against undetected corruption.
Sources and verification
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
- Modbus Application Protocol Specification - Modbus Organization
Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.