Modbus RTU over TCP vs Modbus TCP: which does your converter speak?

The same read, twice

Reading two registers from address 0 on unit 1:

Modbus TCP    00 01 00 00 00 06 01 03 00 00 00 02
RTU over TCP  01 03 00 00 00 02 C4 0B

The Modbus TCP frame starts with a 6-byte header and then the Unit ID. The RTU frame starts with the unit address and ends with a CRC. The middle, the PDU, is identical.

Check the CRC yourself: paste the second line into the frame decoder.

	Modbus TCP	RTU over TCP
Header	MBAP, 7 bytes	Unit address, 1 byte
Integrity	TCP only	CRC-16 as well
Transaction ID	Yes	No
Requests in flight	Several, by specification	One at a time
Used by	PLCs, gateways, direct devices	Transparent serial converters

The Modbus specification doesn’t define RTU over TCP. Vendors adopted it as a practice, so each product names it its own way: “RTU over TCP”, “serial tunnel”, “transparent mode”, “raw TCP”.

Two converter modes

Transparent (raw). The converter copies bytes between TCP and RS-485 without reading them. It doesn’t understand Modbus. Your client has to send RTU frames, with the CRC.

Modbus TCP gateway. The converter parses MBAP, builds an RTU frame, waits for the answer and returns it as Modbus TCP. Your client sends standard Modbus TCP, and the gateway deals with timing and CRC.

Many Wi-Fi and Ethernet converters, such as Elfin EW11, USR and Waveshare models, offer both as a configuration option. Check the web page or the vendor tool. Baud rate, parity and stop bits are set in the converter and have to match the device.

How to tell which one you have

If you can’t see the configuration:

1. Open a TCP connection and send one Modbus TCP read.
2. A valid answer or an exception means it speaks Modbus TCP.
3. On a timeout, send one RTU over TCP read of the same register on a new connection.
4. A valid answer now means transparent mode.
5. Silence from both points to the serial side: Unit ID, baud rate, parity, or A/B wiring.

This is the sequence FieldKit offers after a timeout, as Try RTU over TCP. It sends one read and no writes.

Traps with RTU over TCP

No transaction ID. A late response can look like the answer to your next request. A careful client closes the connection after a timeout, so it can’t take a late answer for the next one.

One master. An RTU response doesn’t say which registers it holds. With two masters on the bus, you can receive values meant for someone else, and they’ll look valid. This is the most dangerous failure in the setup, because nothing reports an error.

Echo. Some adapters echo what they transmit. For function 05 and 06, a normal response equals the request, so an echo looks like a confirmation, and a later exception can go unseen. Read the value back after a write.

Broadcast. Unit 0 is broadcast on serial lines, and devices don’t reply to it. A client that waits for an answer will time out.

Vendor protocols. Some solar data loggers listen on 8899 but wrap Modbus in their own protocol, such as Solarman V5. Neither framing works on them without support for that protocol. FieldKit doesn’t support V5.

Which one to choose

If the converter offers both, gateway mode is the safer default: you get a transaction ID, the gateway handles serial timing, and it can report 0A and 0B. Transparent mode has its uses when a tool requires raw serial access, or when you need to see the bytes that cross the line.

Sources

• Modbus Application Protocol Specification V1.1b3, sections 4.1 and 7
• Modbus Messaging on TCP/IP Implementation Guide V1.0b, section 3.1
• CRC checked with the frame 01 03 00 00 00 02 and result C4 0B