Serial Device Server

What is a Serial Device Server

A serial device server is a network appliance that makes one or more serial ports accessible over Ethernet. On its serial side it exposes RS-232, RS-422, or RS-485 connectors that wire directly to field equipment; on its network side it exposes one or two 10/100BASE-T or Gigabit Ethernet ports. Internally it runs an embedded operating system that buffers serial characters, packs them into TCP or UDP segments, and forwards them, then unpacks return traffic back onto the serial line. The result is a transparent pipe: a serial device that was designed for a 15 m cable run in the 1990s can now be reached from anywhere on the plant network, or across the internet through a VPN.

The need for these devices arises from a simple mismatch of installed base. Decades of industrial instruments, controllers, weighing scales, power meters, fire panels, card readers, and CNC machines ship with serial ports and will remain in service for many more years. Ethernet, meanwhile, became the universal plant backbone. Rather than replace every legacy device with a native Ethernet model, an operator drops a serial device server next to the equipment and brings it onto the network in minutes. This is far cheaper than firmware redevelopment and avoids requalifying a working machine.

Three terms appear in catalogs and are largely interchangeable, with subtle emphasis. A "serial device server" stresses field-instrument connectivity. A "serial-to-Ethernet converter" or "serial server" stresses the conversion function. A "terminal server," the older name carried over from dial-up and console-management history, stresses aggregating many serial console lines, and rackmount 16 and 32-port units are still sold under that label for data-center and control-room console access. All three encapsulate serial data into IP packets in the same fundamental way.

It is important to separate a device server from a protocol gateway. A device server is protocol-transparent: it neither understands nor alters the bytes it carries, so both ends must still speak the same serial protocol, whether that is Modbus RTU, DNP3, a proprietary instrument protocol, or plain ASCII. A protocol gateway, by contrast, actively parses one protocol and re-encodes it as another, such as Modbus RTU to Modbus TCP or Modbus to PROFINET. The distinction blurs in higher-end hardware: the Moxa NPort 6000 line, for example, runs as a transparent device server in Real COM or TCP modes and as a Modbus RTU-to-TCP gateway when that operating mode is selected. SpecForge classifies a true gateway under the separate Protocol Gateway category.

The market is mature and concentrated. Moxa, founded in 1987, has built the reference portfolio with its NPort families and lists hundreds of serial connectivity products. Lantronix popularized the embedded approach with the XPort module and the compact UDS1100. Advantech, Digi, and ATEN cover industrial, console-management, and secure niches respectively, and a tier of Chinese suppliers including USR IOT and Hi-Flying serves cost-sensitive OEM integration. Because the function is well defined, selection turns less on novelty and more on the four engineering axes covered below: interface, operating mode, electrical robustness, and serviceability.

Serial Interface Types

The serial side of a device server speaks one of three electrical standards: RS-232, RS-422, or RS-485. They differ in signaling scheme, distance, speed, and the number of devices a single bus can carry. Choosing the wrong interface is the most common field error, and unlike the network side, a device server cannot paper over the cable physics: the serial run from the server to the field device still obeys the rules of whichever standard is in use. The table below compares the three.

RS-232, standardized as TIA/EIA-232-F, is single-ended: each signal is referenced to a common ground, with a logic mark below minus 3 V and a space above plus 3 V at the receiver. This ground reference and the relatively large voltage swing limit it to about 15 m and to point-to-point links between one driver and one receiver. It carries full modem-control handshaking (RTS, CTS, DTR, DSR, DCD, RI) and remains the standard for console ports, desktop instruments, and short cabinet-internal runs. On a device server it is normally presented on a DB9 male connector.

RS-422, standardized as TIA/EIA-422-B, uses balanced differential signaling: each signal travels on a dedicated pair, and the receiver reads the voltage difference rather than an absolute level, which rejects common-mode noise. This raises the usable distance to roughly 1,200 m and the data rate to as high as 10 Mbit/s, though not at the same time. RS-422 is point-to-multipoint: one driver can fan out to up to ten receivers, which suits one master broadcasting to several listeners. Its specified driver output range is roughly minus 6 V to plus 6 V.

RS-485, standardized as ANSI/TIA/EIA-485-A, extends the differential idea to a true multidrop bus. Up to 32 unit loads share one twisted pair (two-wire half-duplex) or two pairs (four-wire full-duplex), and the bus reaches about 1,200 m at 100 kbps. The standard guarantees correct receiver operation across a wide common-mode window of minus 7 V to plus 12 V, with a 120 ohm characteristic impedance and termination at each cable end. Because two-wire RS-485 is half-duplex, only one node may drive the bus at a time, so the device server must perform automatic direction control, switching its transceiver between transmit and receive without a handshake line. The distance-versus-speed tradeoff is fundamental: at the full 10 Mbps a differential bus runs only about 12 m, while the kilometer-class runs require dropping to roughly 100 kbps.

Most industrial device servers offer a software-selectable RS-232/422/485 port so one part number covers all three, with the mode set in the web console. Many also include configurable pull-up, pull-down, and termination resistors (commonly 120 ohm termination plus 1 kilo-ohm or 150 kilo-ohm bias) so the installer can match the bus electrically without external components. For long multidrop RS-485 runs, verify that biasing and termination are present and correctly enabled, because a floating idle bus produces random framing errors.

Operating Modes and Protocols

Beyond the electrical interface, the defining feature of a serial device server is its set of operating modes. The mode determines how the serial stream is presented to software on the network. Picking the right mode is what makes integration painless or impossible, so it deserves as much attention as the hardware. The table below summarizes the mainstream modes found across the Moxa NPort, Lantronix, and Advantech families.

Real COM mode is the workhorse for legacy software. A vendor driver installed on the host creates a virtual COM port (for example COM5 on Windows or a ttyrXX device on Linux) that an unmodified application opens exactly as if a physical serial port were present. The driver transparently redirects all reads, writes, and even modem-control line states across Ethernet to the remote port. This is the only practical option when the application source cannot be changed and it insists on a local serial handle, which covers a large share of SCADA, laboratory, and access-control software.

RFC 2217, the IETF Telnet Com Port Control Option, performs the same virtual-port function using a documented open protocol instead of a proprietary driver. It carries baud rate, data format, and modem-control line changes in-band over the Telnet session, and it provides out-of-band signaling for the DTR, DSR, RTS, CTS, DCD, and RI lines. Because the protocol is public, open-source clients such as those in pySerial can talk to any compliant server, which avoids driver lock-in. The tradeoff is marginally higher latency than a tuned vendor driver.

TCP Server and TCP Client modes expose the serial port as a raw TCP socket with no virtual COM layer, which suits new software written to open a socket directly. In TCP Server mode the device server listens on a port and waits for a host to connect, appropriate when the host polls the field device. In TCP Client mode the server initiates the connection outward to a fixed host, appropriate when the field device must push data to a central collector or when the host sits behind a firewall. UDP mode drops the connection overhead entirely for the lowest latency and for one-to-many broadcast, at the cost of no automatic retransmission. Pair Connection mode links two device servers back to back so they jointly emulate a single long serial cable, a clean way to extend a serial link across a campus over existing Ethernet.

On the protocol layer, transparent modes carry whatever the field device speaks, most often Modbus RTU or ASCII, DNP3, BACnet MS/TP, or a vendor protocol. Modbus RTU deserves special care: it frames messages by a silent interval of at least 3.5 character times, so the device server must reconstruct that idle gap when repacking bytes, or use a built-in Modbus gateway mode that understands the frame boundaries. Higher-end units such as the Moxa NPort 6000 add an explicit Modbus RTU-to-TCP gateway that lets a Modbus/TCP master reach serial Modbus slaves, with one published implementation supporting up to 31 serial slaves behind the gateway.

Isolation, Surge, and Standards

The single biggest difference between a consumer USB-to-serial dongle and an industrial device server is electrical robustness. Field serial buses run between cabinets, machines, and separate buildings whose grounds sit at different potentials. That potential difference drives current through the signal common, corrupting data and, in severe cases, destroying the line driver. Lightning-induced and switching transients add fast, high-energy spikes. Industrial device servers address these with two distinct and independently specified defenses: galvanic isolation and transient surge suppression.

Galvanic isolation places a non-conductive barrier (optical or transformer based) between the serial transceiver and the rest of the circuit, so no DC ground current can flow through the signal line. Industrial serial isolation is commonly rated at 2 kV to 3 kV. Breaking the ground loop is what allows a single RS-485 bus to span buildings reliably. Separately, the Ethernet port typically includes 1.5 kV magnetic isolation built into its transformer, a near-universal feature even on entry-level units.

Surge protection is a transient defense, not a steady-state barrier. Transient voltage suppression (TVS) diodes or gas-discharge tubes clamp over-voltage events to a safe level within nanoseconds, then return to high impedance. The relevant immunity is specified against the IEC 61000-4 series: IEC 61000-4-5 for surge, IEC 61000-4-2 for electrostatic discharge, and IEC 61000-4-4 for electrical fast transient or burst. A secure device server such as the ATEN SN3401, for instance, adds surge protection on serial, Ethernet, and power lines and is tested to IEC 61000-4 surge waveform requirements. The table below maps the common immunity standards to what they protect against.

Mechanical and environmental standards round out the picture. Industrial units carry a wide operating-temperature rating, with standard grade around 0 to 55 degrees C and extended grade from minus 40 to 75 degrees C for outdoor cabinets and unheated plants. Power input is usually a wide 12 to 48 VDC range so the unit can share a cabinet supply, and many models accept dual redundant power inputs. Regulatory marks such as UL, CE, and FCC are baseline; specific industry segments add their own, for example hazardous-area certification for oil and gas or marine type approval for shipboard use. Always confirm the temperature grade and certification set on the exact part number, because the same series often spans both standard and extended variants.

Key Specification Parameters

Reading a device server datasheet is a fundamental purchasing skill. A typical sheet lists 20 or more parameters, but only a handful truly drive selection. The list below decodes the ones that matter, with the typical values seen across industrial product lines such as the Moxa NPort 5100 family and comparable Lantronix and Advantech units.

• Serial standard and port count: RS-232, RS-422, RS-485, or a software-selectable combination, in 1, 2, 4, 8, 16, or 32-port configurations. The selectable type is the most flexible for a stocked spare.
• Baud rate: entry models run 110 bps to 230.4 kbps; higher-end ports reach 50 bps to 921.6 kbps. Confirm your field device's exact rate is on the supported list, including any non-standard rate.
• Data format: 5, 6, 7, or 8 data bits; 1, 1.5, or 2 stop bits; parity none, even, odd, mark, or space. Mismatched framing is a frequent cause of garbled data.
• Flow control: hardware RTS/CTS and DTR/DSR (RS-232 only) and software XON/XOFF. For two-wire RS-485, automatic direction control replaces handshaking.
• Serial isolation: none, or 2 kV to 3 kV galvanic. Required for inter-building and heavy-machinery service.
• Surge and ESD rating: compliance level against IEC 61000-4-5 and IEC 61000-4-2, ideally on serial, Ethernet, and power lines.
• Ethernet interface: 10/100BASE-T(X) or Gigabit, RJ45, with 1.5 kV magnetic isolation; some models add a second port for daisy-chain or redundancy.
• Operating modes: Real COM, RFC 2217, TCP Server, TCP Client, UDP, Pair Connection, Reverse Telnet, and any Modbus gateway mode. Map these against your software before buying.
• Power input: commonly 12 to 48 VDC, with current draw of roughly 100 to 200 mA at 12 VDC for a small unit; dual-input models add resilience.
• Operating temperature: standard 0 to 55 degrees C or extended minus 40 to 75 degrees C. Pick by cabinet environment, not by ambient room temperature.
• Management and security: web console, Telnet, SSH, SNMP, HTTPS, and IP filtering; secure series add encrypted tunnels for internet-facing access.

Two parameters that are easy to overlook deserve emphasis. The first is packing control: the delimiter character or force-transmit timer, often adjustable down to about 1 ms, that decides when a partial serial buffer is flushed onto the network. Set it too long and latency rises; set it too short and a single logical message fragments into many small packets. The second is added latency and jitter: on a quiet local network the conversion adds only a few milliseconds, but TCP retransmission on a congested link can inject tens of milliseconds of jitter, which matters for timing-sensitive Modbus RTU and rules out tunneling hard real-time motion loops.

Datasheets also vary in how honestly they state accuracy of timing reconstruction. For Modbus and other gap-framed protocols, prefer a unit that documents a dedicated framing or gateway mode rather than relying on a generic byte timer, and where possible bench-test the actual field device through the server before committing to a fleet rollout.

Selection Decision Factors

To turn the preceding five chapters into a concrete part number, follow the decision sequence below. Most selection mistakes come not from one wrong answer but from deciding a later step before an earlier one is settled. These eight steps double as a fixed RFQ template.

1. Serial interface and port count: First confirm whether the field devices are RS-232, RS-422, or RS-485, and how many lines must be served. Prefer a software-selectable RS-232/422/485 port for stocking flexibility, then choose 1-port localized units versus a multi-port consolidator per the topology.
2. Operating mode and software fit: Decide whether existing software needs a virtual COM port (Real COM or RFC 2217) or can open a raw socket (TCP Server, TCP Client, UDP). This single choice often eliminates half the candidate models.
3. Protocol handling: If the bus carries Modbus RTU or another gap-framed protocol, require a documented framing or Modbus gateway mode rather than a generic byte timer, and verify slave-count limits.
4. Electrical robustness: Specify serial isolation (2 kV to 3 kV) and surge or ESD rating (IEC 61000-4-5 and IEC 61000-4-2) for any inter-building, outdoor, or heavy-machinery run. Skip isolation only for benign in-cabinet links.
5. Environment and power: Match the operating-temperature grade (standard 0 to 55 degrees C versus extended minus 40 to 75 degrees C) to the cabinet, pick a power input compatible with the available supply, and require dual inputs for critical loops.
6. Network and redundancy: Choose 10/100 or Gigabit Ethernet, single or dual ports, and any ring or redundancy protocol the plant network requires for fault tolerance.
7. Management and security: Require the management interfaces your operations team uses (web, SNMP, SSH) and, for any internet-facing or shared-network deployment, encrypted tunnels, HTTPS, and IP filtering rather than plain Telnet.
8. Total cost of ownership: Weigh purchase price against blast radius and serviceability. A multi-port unit lowers cost per port but takes every attached device offline if it or its breaker fails, so critical loops may justify per-device 1-port units or redundant models.

One last commonly overlooked dimension is manufacturer serviceability: local spare-part availability, the longevity of the virtual COM driver across operating-system updates, firmware patch cadence for security fixes, and the clarity of the configuration tooling. A device server installed today may run for ten years on a production line, so a vendor that still supports and patches an aging series is worth a premium. Moxa, Lantronix, Advantech, Digi, and ATEN maintain long-lived product lines and driver support, while lower-cost suppliers such as USR IOT and Hi-Flying can be the right answer for high-volume OEM designs where the integrator controls the software stack.