Transparent Serial-to-TCP vs Protocol Conversion: Which Does Your Device Need?
Choose a transparent serial-to-TCP gateway when the host software will continue speaking the device’s existing serial protocol. Choose protocol conversion when the host expects a different application protocol, such as Modbus TCP instead of Modbus RTU. The first transports bytes; the second interprets and rebuilds messages.
That decision comes before choosing hardware. “RS485 to Ethernet” describes the interfaces, but it does not establish compatibility between the software at each end. A successful design must also account for framing, bus ownership, retries, and security.
What a transparent serial gateway actually does
In raw transparent mode, the gateway forwards serial payload bytes through a TCP connection and writes received TCP payload bytes to its serial port. The application retains responsibility for device commands, checksums, response parsing, and command meaning. Check the selected mode: virtual-COM or serial-control modes can add their own negotiation and require matching host software.
This is a useful starting point for a proprietary binary protocol or an existing serial application that can use a supported virtual COM driver. Confirm whether the application depends on modem-control signals, BREAK, exact timing, or local serial-driver behavior. A gateway that transports ordinary data bytes may not reproduce those features.
For example, if an instrument uses a documented length-prefixed command, the host can accumulate TCP bytes until the complete command response is available. No register mapping is needed, but the host still needs the instrument’s parser.
TCP delivery does not preserve serial message boundaries
TCP provides a reliable, ordered byte stream. A receiver can obtain part of one application message in a read, or several messages together. TCP segments and socket reads are not application records. This follows the transport model in RFC 9293.
Illustrative example: a device sends two eight-byte messages, A and B. A receiving application might read the first five bytes of A, then the remaining three bytes of A plus all eight bytes of B. Those read boundaries are only an example, not a prediction of network behavior. The parser must buffer incomplete data and extract complete messages using the protocol’s length, delimiter, or other framing rules.
Serial timing needs separate treatment. Modbus RTU uses frame-separating silence and has inter-character timing requirements; the serial-line specification, section 2.5.1.1, defines them, including the higher-baud-rate timer recommendation. UART start, parity, and stop bits are also not ordinary TCP payload bytes.
Do not assume network arrival gaps reproduce serial silence. A gateway needs suitable buffering and serial transmission rules. Packetization timeouts alone are not proof that an RTU frame will remain intact at the serial output. Test split input, delayed bytes, and back-to-back requests.
Modbus RTU over a tunnel is different from Modbus TCP
A Modbus TCP request uses a seven-byte MBAP header and a protocol data unit (PDU). Modbus RTU uses a serial address, the PDU, and a CRC. A transparent tunnel can carry the complete RTU bytes, including CRC, inside TCP, but a standard Modbus TCP client expects the MBAP format.
A converting gateway parses MBAP, routes the Unit Identifier to the configured serial destination, builds the RTU request, verifies the response CRC, and associates the reply with the originating TCP transaction. The MBAP length supports message parsing; the transaction identifier pairs requests and responses. See the Modbus TCP/IP implementation guide, sections 3.1.2–3.1.3.
Worked example, invented for illustration: read two holding registers starting at wire address zero from serial device 7. Function 03 and zero-based wire addressing follow the Modbus Application Protocol specification, sections 4.4 and 6.3. These bytes demonstrate encoding, not an Obeita product test or a real device’s register map.
- Request PDU:
03 00 00 00 02. - Modbus TCP request:
00 2A 00 00 00 06 07 03 00 00 00 02. Transaction ID is002A; length0006counts the Unit Identifier plus five PDU bytes. - Corresponding RTU request:
07 03 00 00 00 02 C4 6D. The calculated CRC is transmitted low byte first.
The PDU is unchanged in this example. Converting transport framing does not automatically translate a proprietary command set, infer scaling, or resolve multi-register data ordering. Those requirements need an explicit mapping.
Decide who owns the serial bus and the retry policy
The Modbus serial-line model permits one initiating master and one transaction at a time. Adding Ethernet clients does not create more simultaneous serial capacity. If several hosts need access, require a documented scheduler, queue limits, timeout handling, and response routing. Do not attach another active polling master to the same bus without an engineered arbitration arrangement.
Ask what happens when a queued request expires, a client disconnects, or a late serial response arrives. A transparent server that accepts multiple sockets needs explicit ownership rules; connection acceptance alone does not establish safe multi-client operation.
Failure scenario: a device executes a write, but its reply is lost before the client receives it. An application retry may execute that write again. TCP retransmission within a connection is different from issuing another application request. A Modbus transaction identifier is not, by itself, a persistent duplicate-suppression guarantee.
Classify commands by their effects. Repeating a setpoint assignment may be acceptable; repeating a command that starts a cycle may not be. For consequential writes, define device-supported sequence checking, status reconciliation, or operator recovery rather than unconditional retries.
Define the deployment’s security boundary
Neither plain TCP nor conventional Modbus TCP inherently supplies encrypted, authenticated application access. Confirm what the selected gateway and client actually support. Modbus Security specifies TLS and certificate-based authentication; support must exist at both endpoints, with certificate provisioning and renewal planned.
As a deployment checklist, restrict gateway reachability to approved systems, isolate the control network, protect management access, and avoid direct public-internet exposure. An approved VPN or security gateway may protect a network path, but the remaining local segment and device authorization still require review. Encryption does not decide which authenticated client may issue a write.
A practical selection and acceptance checklist
- Identify both protocols. Record what the device emits and what the host accepts: raw serial bytes, RTU-over-TCP, Modbus TCP, or another documented format.
- Check the electrical prerequisites. Confirm RS232 versus RS485, two- or four-wire wiring, pinout, baud rate, parity, stop bits, grounding, isolation, termination, and biasing against the installation requirements.
- Assign framing responsibility. Name the component that assembles messages and meets serial timing, including maximum frame size and malformed-input behavior.
- Specify access and recovery. Define bus ownership, concurrent-client behavior, command permissions, timeouts, queue limits, reconnect handling, and safe write retries.
- Prove the difficult cases. Use a bench setup to test partial and combined TCP reads, absent devices, late replies, reconnects, queue saturation, and denied access. Set pass criteria before testing.
Choose transparent forwarding when protocol compatibility already exists and framing can be handled reliably. Choose conversion when the host requires a different message format or an explicit data model. If either side is undocumented, gather evidence before committing to a gateway architecture.
Prepare your gateway requirements for Obeita
For a focused technical discussion with Obeita, prepare a redacted device manual, representative request/response frames, serial settings, host protocol, device count, timing requirements, and expected failure behavior. Remove credentials, customer identifiers, and confidential process data. These inputs make it possible to evaluate the required transport, conversion, and validation work.
Explore Obeita’s legacy device connectivity service and the delivered serial-to-Ethernet and cellular DTU adaptation project for related integration work. To discuss your device and host protocols, contact Obeita.
