The Last Byte Is Always Corrupted: A Field Engineer’s Guide to RS-232 vs RS-485

Differential vs single-ended, why ±15 V loses to ±1.5 V, and the six wiring mistakes that only surface after commissioning — plus what to look for in an industrial 4G/5G router with an RS-485 serial port

Written by E-Lins Engineering Team

A technician calls. The Modbus poll works for nineteen registers and then returns garbage on the twentieth. Every twentieth read. Not the nineteenth, not a random one — always the last byte of the frame. He has swapped the cable, swapped the meter, swapped the PLC. Nothing changes. Fifteen minutes into the call you ask one question — “how are you driving the transmit enable?” — and the problem evaporates. It was never the cable. It was never the meter. It was two microseconds of timing.

That story is the reason this article exists. Most RS232 vs RS485 comparisons are a table of numbers — voltage levels, distance, node count — and the table is not wrong. It is just useless at the moment you need it, because the failure you are debugging is not in the table. The failure is in the gap between what the standard guarantees and what your specific installation does.

So we are going to do both. We will cover the numbers properly, including where they actually come from rather than treating them as commandments. And we will cover the half-dozen ways these interfaces fail in the field, most of which have nothing to do with the number you were comparing.

Two Standards, Two Completely Different Questions

The single most useful thing you can know about these two interfaces is why each was written, because every specification difference that follows is a consequence of that original brief.

RS-232 was published in 1962 to connect a terminal to a modem. One device at each end. They sit on the same desk. They are plugged into the same mains strip, so they share a ground that is, for practical purposes, the same ground. The engineering question was: how do I get a teletype to talk to a modulator-demodulator across two metres of cable? The answer that fell out was single-ended signalling — measure the voltage on one wire relative to a shared reference — because when both ends share a ground, that works perfectly and it is cheap.

RS-485 was published in 1983 to connect equipment across a factory floor. Many devices on one pair of wires. They are tens or hundreds of metres apart. They are fed from different distribution boards, their earths are at different potentials, and there are variable-speed drives and contactors throwing noise into everything nearby. The engineering question was completely different: how do I move data reliably between boxes whose grounds I cannot trust and whose environment is electrically hostile?

The answer to that question cannot be single-ended, because single-ended signalling has no way to distinguish “the signal changed” from “the reference moved.” That contrast — differential vs single-ended signalling — is the whole ball game. So RS-485 is differential: the receiver does not look at a voltage against ground, it looks at the difference between two wires, and any noise that couples into both wires equally — which is what real electromagnetic interference does to a twisted pair — cancels out.

The one-line version

RS-232 assumes the two devices agree about what zero volts is. RS-485 refuses to make that assumption. Everything else in the comparison follows from that.

There is also a naming note worth getting right, because it comes up in procurement. “RS” stood for Recommended Standard and was the EIA’s original designation; the standards are now maintained as TIA/EIA-232 and TIA/EIA-485-A. Nobody in the field says “TIA-485,” and this article will not either — but if a tender document is pedantic about it, that is why.

Why ±15 V Loses to ±1.5 V

Here is the fact that surprises people first time they see it side by side: RS-232 swings a much larger voltage than RS-485, and reaches a fraction of the distance.

An RS-232 driver puts out somewhere between ±5 V and ±15 V, measured on a single wire against signal ground. A logic 1 (“mark”) is anywhere from −3 V to −15 V; a logic 0 (“space”) is +3 V to +15 V. The receiver switches at ±3 V, and anything in the −3 V to +3 V band is explicitly undefined — a deliberate dead band so that a slowly-slewing signal does not chatter.

An RS-485 driver, by contrast, is only required to produce 1.5 V of differential voltage across a 54 Ω load. The receiver only needs 200 mV to decide which way the bit went.

So RS-232 is shouting at more than ten times the amplitude, over a wire with a shared reference, and it stops working at fifteen metres. RS-485 whispers two hundred millivolts across a pair and works at twelve hundred. How?

Because distance is not limited by amplitude. It is limited by how much noise lands on top of your signal before the receiver cannot tell the difference any more, and the dominant noise source in a real installation is not faint electromagnetic pickup — it is the fact that the ground at one end of the cable is not at the same potential as the ground at the other end.

That difference is called ground potential difference, and in an industrial site it is routinely a few volts. It comes from motor starts, from earth faults on other circuits, from lightning-induced surges kilometres away, and from nothing more exotic than a long cable run sharing a tray with a 400 V feeder. If your receiver is measuring “+8 V relative to ground” and the ground at the far end has drifted 4 V, your ±3 V threshold has just been moved halfway to the wrong answer. This is the single most common cause of intermittent RS-232 failures, and it is why the fix is almost never “buy a better cable.”

RS-485 survives it because the receiver is measuring the difference between two wires that both moved together. The 4 V of ground shift pushed A and B up together, the difference between them is unchanged, and the bit still decodes correctly. Standard RS-485 transceivers tolerate the whole bus being shifted from −7 V to +12 V relative to their local ground — a nineteen-volt window of “I do not care where your ground is.”

There is one caveat that catches people out, and it belongs in the same section: RS-485’s common-mode range is ±7 V to +12 V, not infinity. If you run 1,200 metres between two buildings with genuinely independent earths, the differential pair will save you from noise but not from a common-mode voltage outside that window. The fix is a third wire — a signal ground reference, usually connected through a 100 Ω resistor to limit ground-loop current — run alongside the pair. It sounds like a contradiction: “differential means I do not need a ground.” Differential means you do not need a ground for the signal. You still need one to keep the transceiver inside its common-mode limits. Almost every “RS-485 works on the bench and fails in the field” story is this.

Distance Is Not About Voltage Either

The headline numbers everyone quotes are 15 m for RS-232 and 1,200 m for RS-485. Neither is a physical law, and knowing where they come from lets you break them intelligently instead of accidentally.

The RS-232 figure is a capacitance limit, not a length. TIA-232 specifies that a driver must be able to drive a load of 2,500 pF. Typical serial cable is somewhere around 40–100 pF per metre, and at the low end of that range 2,500 pF is reached somewhere between 25 and 60 metres — but the standard states 15 m because the same document also caps the data rate at 20 kbps, and the two numbers were written for a particular combination of cable and speed that nobody uses any more. In practice, an RS-232 link at 9,600 bps over good low-capacitance cable will happily run 50 m or more. It will also fail at 5 m next to a large drive, for the ground reasons in the previous section.

The RS-485 figure is a RS-232 vs RS-485 distance and cable length trade-off, not a wall. The standard’s 1,200 m is specified at 100 kbps, and the relationship is roughly reciprocal: distance times bit rate stays roughly constant. Push 10 Mbps and you are down to about 12 m. The mechanism is that a long cable is a low-pass filter — its resistance and capacitance round off your square edges, and once the edges are rounded enough the receiver cannot find the bit boundaries, which is usually expressed as a jitter budget of about 0.3 unit intervals.

Data rate	RS-232 practical reach	RS-485 practical reach	What actually limits you
1,200 bps	~60 m	~1,200 m (cable resistance)	Cable capacitance (232) / DC loop resistance (485)
9,600 bps	~30–50 m	~1,200 m	Capacitance / ground noise
115,200 bps	~10–15 m	~800–1,000 m	Edge slew and jitter
1 Mbps	Not usable	~100 m	Transmission-line effects, termination
10 Mbps	Not usable	~12 m	Same, but unforgiving

Note the practical consequence for the 1,200 m number: at that distance you are not limited by the standard, you are limited by DC resistance in the copper and by how much common-mode shift has accumulated. A 1,200 m run of thin cable may simply not deliver 200 mV to the far receiver. If you genuinely need that distance, specify the cable by loop resistance and check the voltage budget, rather than trusting a number copied from a datasheet summary.

Once the cable becomes electrically long relative to your edges — roughly, when the propagation delay exceeds a bit time or so — it stops being a wire and becomes a transmission line. That is when RS-485 termination resistor 120 ohm starts to matter, and it is the subject of section 06, because terminating it wrong is worse than not terminating it at all.

One Talker or Many: The Topology Difference

The second great divide, and the one that actually decides most designs, is not distance at all — it is how many things can be on the wire.

RS-232 is point to point. One driver, one receiver, two data wires plus ground plus whatever handshaking lines you choose to use. There is no addressing, no arbitration, no bus arbitration protocol, because there is nothing to arbitrate. That simplicity is a genuine advantage in the cases where it fits, and section 07 covers one of them.

RS-485 is a multidrop bus. Many transceivers share one pair of wires. One talks at a time; everyone listens. That is exactly the shape of an industrial polling application — one PLC or gateway asking twenty energy meters a question each in turn — and it is why RS-485 became the de facto physical layer for industrial fieldbuses.

The node limit is 32 unit loads, and the unit load is defined by receiver input impedance. A standard RS-485 receiver presents 12 kΩ, which is one unit load; thirty-two of those in parallel is 375 Ω, which is about as much as a driver can be expected to push against while still maintaining 1.5 V. Modern transceivers are commonly rated at ¼ unit load (48 kΩ) or ⅛ unit load (96 kΩ), which is how you get to RS-485 unit load and 32 node limit figures of 128 or 256 devices on a segment.

The trap in that last paragraph

The 128- and 256-node figures assume every device on the bus is a low-unit-load transceiver. One legacy device with a 12 kΩ input, plus one unterminated stub, plus a cheap converter someone added in 2014, and you are back to debugging. Count unit loads, not devices.

There is also a two-wire vs four-wire RS-485 choice that is widely misunderstood. Two-wire is half-duplex: one pair, one talker at a time. Four-wire gives you a dedicated transmit pair and a dedicated receive pair, which sounds like it should double your throughput, and in the specific case of a master that must transmit while a slave replies it does. But the slave side of a four-wire bus is still a single shared transmit pair with one talker at a time — so you have added a pair of wires and kept the same fundamental constraint. Four-wire earns its place in a few genuinely full-duplex applications and is otherwise an extra cable to get wrong.

Half Duplex Is the Default — and It Bites

Now we get to the phone call from the introduction.

In two-wire RS-485, a transceiver is either driving the bus or listening to it, never both. That is controlled by a pin usually called DE (driver enable) or, on older parts, a combination of DE and RE (receiver enable, active low). Your firmware or your USB converter has to assert DE before transmitting and de-assert it after.

The bug is in the “after.”

A UART has two “done” flags, and they mean different things. One says the holding register or FIFO is empty — there is room for more data. The other says the shift register is empty — the last byte has actually finished clocking out onto the wire. These are not the same moment; they are separated by the time it takes to shift one character, which at 9,600 bps with 8N1 framing is about 1.04 milliseconds. That is an eternity in microcontroller time.

If your code watches the wrong flag — or, worse, just delays a fixed number of microseconds that happened to work on the bench — it will de-assert DE while the final stop bit is still in flight. The bus goes high-impedance, the termination resistors pull the pair together, the differential voltage collapses, and the receiver at the far end sees the last character’s final bits dissolve into noise. You get a CRC error, or a truncated frame, or — if the protocol is lenient — a corrupted last byte that only shows up as implausible register values weeks later.

This is the RS-485 half duplex driver enable delay problem, and it has three correct fixes and one fake one:

• Wait for transmit-complete, not transmit-empty. Use the UART’s TC / shift-register-empty interrupt or status bit. This is the correct fix.
• Or add one character time of delay after the last byte before releasing DE. Crude but robust, and it is what most USB-RS485 dongles with automatic direction control approximate.
• Or use a transceiver with automatic direction control. Several modern parts sense the transmit data line and handle the enable in hardware. Convenient, but verify its behaviour at your baud rate — some are unreliable above 115,200 bps.
• The fake fix: tuning the delay until it stops failing. It will fail again at a different baud rate, a different cable length, or a different temperature. Do not ship this.

A related half-duplex detail: after releasing DE, most systems should wait a short turnaround delay before expecting a reply, and — critically — the far device has its own DE delay plus its own response time. Modbus RTU encodes this as the 3.5-character silence that frames a message and the 1.5-character maximum gap allowed between characters within a message. If your master starts polling again before the slave has released the bus, or if your gateway inserts characters slowly enough to exceed 1.5 characters mid-frame, slaves will discard the frame as malformed. This is one of the two big reasons transparent serial tunnelling over IP is harder than it looks, which we come back to in section 10.

The Six Wiring Mistakes That Only Surface After Commissioning

None of these are exotic. All six appear in commissioned sites more often than anyone would like to admit, and all six have the same signature: it worked on the bench, it worked for a week, and now it is intermittent.

1. Terminating every device instead of the two ends. The 120 Ω resistor matches the characteristic impedance of the twisted pair so that a signal reaching the end is absorbed rather than reflected. It goes at the two physical ends of the bus — two resistors per segment, total, regardless of how many devices are attached. Put one at each of twenty devices and you have presented the driver with a 6 Ω load, which no RS-485 transceiver can drive. Symptoms: nothing works at all, or works only at very low baud rates.
2. No fail-safe bias resistors. With every driver disabled, the bus is floating, and a floating differential pair will drift through the ±200 mV receive threshold as temperature and noise wander. The receiver interprets that as a start bit and you get phantom characters, framing errors, and log files full of garbage that only appears when nobody is transmitting. The fix is RS-485 fail-safe bias resistors — typically a pull-up on one line and a pull-down on the other, sized around 560 Ω to 1 kΩ, at one point on the bus — so that idle is unambiguously a known state. Many modern transceivers integrate true fail-safe receivers that do this internally; if you have them, you can skip the resistors, but verify which type you actually bought.
3. Star topology. This is the one that kills retrofit designs. Somebody wants to home-run every device back to a panel because that is how you wire power, and the result is a bus with a dozen stubs radiating from a central point. Every stub is an impedance discontinuity that reflects; a dozen of them turn your digital signal into analogue soup. RS-485 wants RS-485 daisy chain vs star topology resolved firmly in favour of a daisy chain: in one side of each device, out the other, on to the next. If you absolutely must have a star, use an RS-485 repeater or hub to break it into proper bus segments.
4. No ground reference. Covered in section 02, repeated here because it belongs on the list: differential signalling does not remove the need to keep common-mode voltage inside a ±7 V to +12 V window. Run a third wire, usually through a 100 Ω resistor, between the devices’ signal grounds.
5. Using the wrong cable. RS-485 wants twisted pair with a characteristic impedance around 100–120 Ω and, for long or noisy runs, a shield. Cat5e works well and is cheap — just be consistent about which pair you use and do not split a pair across signals. What does not work is flat ribbon, parallel untwisted wire, or two random cores from a multi-core control cable. Those have no defined impedance, so your 120 Ω terminators are wrong by construction.
6. No surge or common-mode protection on long outdoor runs. A bus that leaves a building is a lightning antenna. A 1,200 m cable between two structures with separate earths will see large common-mode transients, and those transients destroy transceivers. Gas discharge tubes or TVS arrays rated for the bus, plus proper shield bonding at one end, are not optional on outdoor runs.

RS-422: The Third Option Nobody Orders

RS-422 sits between the two and is worth thirty seconds of your attention, mostly so you can rule it out correctly.

It is differential, like RS-485 — same noise immunity, same 1,200 m reach, same 10 Mbps ceiling. But it uses four wires with a dedicated transmit pair and receive pair, and critically it supports one driver and up to ten receivers, with no multi-point capability on the transmit side. So: full duplex, excellent noise performance, long distance — and no bus.

That makes it the right answer for a small set of problems: a long point-to-point link that must be full duplex and immune to noise, or a broadcast link where one device transmits and several listen but none reply. It is the wrong answer for almost every polling application, because the moment two devices need to share a transmit path you have reinvented RS-485 with extra wires.

Practical note: most modern RS-485 transceivers will interoperate with an RS-422 driver on the receive side, because the electrical levels are compatible. The reverse is not guaranteed. If you inherit a site with RS-422 on it, do not assume an RS-485 device will drive it.

DB9, DB15, or Terminal Block? The Connector Is Not a Detail

Ask an engineer to specify a serial port and the answer is usually “RS-485.” Ask about the DB9 vs terminal block serial connector choice and you get a shrug. But in a cabinet that vibrates, or gets serviced by a contractor in the rain, the connector decides more of your long-term reliability than the electrical standard does.

DB9 (DE-9). The legacy default, inherited from RS-232’s DB25. Rigid, familiar, and easy to plug in blind — which is its main advantage when a technician is working in a dark cabinet. Its disadvantages are real though: it is bulky, it is not designed for vibration without screw locks, and it invites the single worst failure in serial work, which is plugging an RS-232 device into an RS-485 port because the connector fits. Across our range, the H820 exposes its serial port on a DB9, which makes it the natural choice where field technicians expect to plug straight into a meter’s existing DB9 lead.

Terminal block / terminal socket. Two, three or four screw terminals — A, B, ground, sometimes a bias or shield point. Smaller, cheaper, vibration-proof when done right, and it makes the ground reference wire a first-class citizen instead of an afterthought. It is also the only sensible option when you are terminating a bus with a 120 Ω resistor and bias resistors, because you can put those on the same terminals. The H900, H900f, H900pf, H900t6-W6, H720, H685f and H685frc all expose RS-232/RS-485 on a terminal socket. For permanent installation in a panel, we recommend it over DB9 almost every time.

DB15 or a choice of both. Some devices expose serial on a higher-density connector, or let you choose the physical form at order time. The M400 is the flexible one here: DB9, DB15 (RS232/RS485 optional) or terminal block, plus USB, in an 83 × 53 × 25 mm enclosure. That is the device to reach for when you do not yet know what you will be plugging into.

The ordering gotcha that catches everyone

Read our datasheets carefully and you will see the line “Serial Port RS232 or RS485”. That is not sloppy punctuation — it means one serial port, configured at order time as either RS-232 or RS-485, not a port that does both simultaneously. If your design needs one of each, you need either two devices or a different architecture. Decide before you order.

“Modbus RS-485” Is Not a Thing — and the Distinction Matters

People say “we’re using Modbus RS-485.” They usually mean “Modbus RTU over an RS-485 physical layer,” and the collapse of three layers into two words is the source of a lot of avoidable confusion. The stack, properly:

• Physical layer. RS-232 or RS-485. Defines voltages, wiring, distances. Knows nothing about what the bytes mean.
• Data link / framing. Modbus RTU (binary, compact, CRC-16 error check, framed by silence) or Modbus ASCII (human-readable hex characters, LRC check, framed by explicit start and stop characters). RTU is the default on RS-485; ASCII exists and is sometimes found over RS-232 links to older instruments.
• Application layer. The Modbus register model — coils, discrete inputs, holding registers, input registers — and function codes. Identical regardless of what is underneath.

Why the distinction is not pedantry: because when you move a Modbus system onto IP, the framing layer has to change and the application layer does not. Modbus TCP is the same register model and the same function codes wrapped in an MBAP header, with TCP handling error detection so the CRC disappears. A gateway that converts Modbus TCP on Ethernet to Modbus RTU on RS-485 is translating between framing layers while leaving the application payload untouched. A gateway that does anything else is a liability.

And that is also why the phrase Modbus RTU over RS-485 deserves to be said in full in your design documents. “Modbus over IP” is ambiguous in a way that has cost projects real money — somebody specifies it, and six months later discovers the integrator implemented a dumb byte pipe instead of a protocol-aware gateway. Section 10 explains why that distinction decides whether the system works.

When the Answer Is Neither: Serial over IP

Here is the part that most comparisons miss entirely, and it is the part that changes the decision for most modern deployments.

Suppose you have twelve energy meters on a factory floor and a SCADA server in an office 300 m away, and the site is being refurbished so running new cable is expensive. The textbook answer is an RS-485 bus from the meters to a converter, and then… something. Maybe a long RS-485 run. Maybe fibre with media converters. Maybe you hope someone has already run Ethernet.

The modern answer is different: put a serial-to-cellular gateway next to the meters, run the RS-485 bus its ordinary local 30 m, and let the router carry the data over 4G or 5G to the SCADA server. The bus stays short and well-behaved. The long haul becomes somebody else’s network.

Now the insight that makes this article more than a comparison table:

Moving to IP removes RS-485’s distance advantage — but not its multi-drop advantage

Once the long haul is cellular, you no longer care that RS-485 can reach 1,200 m, because you are not running 1,200 m of copper. But you still care enormously that RS-485 lets twelve meters share one pair of wires and one serial port on the gateway, because RS-232 cannot do that at any distance. The reason to choose RS-485 does not disappear when the network changes. It just changes from “distance” to “node count.”

There is a serious caveat, and it is the same one that has been lurking since section 05. The obvious implementation — take the serial bytes, wrap them in a TCP socket, ship them, unwrap at the other end — breaks Modbus RTU’s timing rules. RTU frames are delimited by silence: 3.5 characters of idle between frames, no more than 1.5 characters of gap within one. A TCP connection has jitter. It will occasionally deliver bytes in two chunks with a 20 ms gap in the middle, and the slave will see that gap as an end-of-frame, discard the partial message, and then see the remainder as a malformed new message. The symptom is exactly the kind of thing that sends people back to swapping cables: intermittent CRC failures that correlate with network load.

The correct implementations are:

• Protocol-aware gatewaying. The router speaks Modbus TCP on the IP side and generates proper Modbus RTU frames locally on the serial side, with correct inter-frame timing because it is physically adjacent to the bus. This is what our Modbus and DTU (serial-to-cellular) feature does, and it is the right default.
• Framing-aware transparent tunnelling. If you must pass raw bytes, configure explicit framing — packetise on idle time or byte count at the serial side and reassemble deliberately at the host — rather than relying on TCP’s stream semantics to preserve byte spacing. It works, but it is fragile and it needs tuning per baud rate.
• Virtual COM port on the host. Convenient for legacy software that insists it owns a COM port, but it hides all of the above rather than solving it. Fine for configuration access; do not build a polling system on it.

One more benefit worth naming: SSH to serial. When the router is the serial gateway, remote console access to the equipment behind it comes for free — an engineer can open a CLI session to a device on the serial bus from anywhere, without a site visit. On a distributed estate, that is frequently the single most valuable feature in the whole design.

How to Specify It: A Decision Worksheet

Stop asking “which is better.” The RS232 vs RS485 decision is not a preference, it is a consequence — of five questions, asked in this order. Get through them and the answer is usually immediate.

Question	If the answer is…	Then
1. How many devices must share the wire?	More than two	RS-485. RS-232 physically cannot do it. End of analysis.
	Exactly two	Either works — keep going.
2. How far apart are they?	Under ~10 m, same cabinet, same power	RS-232 is fine and simpler.
	10–50 m indoor	RS-232 usually works; RS-485 if there is any noise nearby.
	Over 50 m, or between buildings	RS-485, with a ground reference and surge protection.
3. Do they share a clean ground?	No / unknown / different distribution boards	RS-485. This is the decisive question in retrofit work.
4. Do you need hardware flow control?	Yes (old modems, some instruments)	RS-232. RTS/CTS and DTR/DSR exist there and have no RS-485 equivalent.
5. Is the long haul going over IP anyway?	Yes	Stop optimising distance. Size the bus for node count, keep it short, gateway at the router.

And the specification lines that belong in the document regardless of which you choose:

• Baud rate, data bits, parity, stop bits — written explicitly. “9600 8N1” not “default.” More serial faults trace to a parity mismatch than to anything in sections 02 through 06.
• Cable type and characteristic impedance, not just “screened twisted pair.”
• Termination and bias — who supplies them, where they go, and the fact that there are exactly two terminators.
• Topology drawing showing the daisy chain order. If the drawing shows a star, the design is already wrong.
• Ground reference and surge protection for anything leaving a building.
• Which flavour of serial the device ships with — RS-232 or RS-485 — because on most industrial routers, including ours, that is an order-time choice.

E-Lins Devices with Serial — and Where Each Fits

All of the routers below carry the same serial software feature set — Modbus and DTU (serial to cellular), plus SSH to serial for remote console access — so the differentiator is the physical form factor, the connector, and the environment.

Model	Serial interface	Connector	Where it fits
H820	RS232 or RS485	DB9	Segment cabinet with 5× GbE LAN/WAN and PoE PD or PSE. The DB9 makes it the plug-and-go choice where the field device already has a DB9 lead. −35~75 °C.
H900f	RS232 or RS485	Terminal socket	Panel-mounted gateway. H900 is 4G, H900f is 5G with dual SIM. Terminal socket is the right call for permanent, properly terminated bus wiring.
H900pf	RS232 or RS485	Terminal socket	Same, plus PoE PSE 802.3af/at/bt on two LAN ports — one device to gateway the bus and power a camera or sensor alongside it.
H900t6-W6 / H720	RS232 or RS485	Terminal socket + console port	Sites that need separate management access. A dedicated console port means you can recover the box without unplugging the bus.
H685f / H685frc	RS232 or RS485	Terminal socket	Where space is the constraint — 100 × 60 × 21 mm, 220 g. H685frc is the 5G RedCap variant for large fleets.
M400	RS232 / RS485 / USB	DB9, DB15 or terminal block	The flexible one, and the smallest at 83 × 53 × 25 mm. GNSS/BeiDou on board. Choose this when you do not yet know what you will connect.

Two honest exclusions, because they matter in planning: the H820QO (our IP68 outdoor unit) and the M300 do not have a serial port. If you need serial in an outdoor, pole-mounted or unsheltered location, the architecture is an H820 or H900 inside a sealed cabinet, not an H820QO on a pole.

Field note

“We spent two weeks on a meter that returned bad values once an hour. New cable, new converter, new meter firmware. In the end it was the USB-to-485 adapter on our laptop the whole time — automatic direction control that couldn’t hold the bus at 38,400. The site was fine. Our test equipment was the fault.”

Commissioning engineer, water utility telemetry upgrade — shared with permission, details withheld

Frequently Asked Questions

Q1:Can I connect an RS-232 device directly to an RS-485 port?

No, not directly. The voltage levels and the signalling method are fundamentally incompatible: RS-232 is single-ended at ±3 to ±15 V referenced to ground, RS-485 is differential at a minimum of 200 mV across a pair. You need a converter, and you need the right kind — a cheap passive adapter that just rewires pins will sometimes appear to work at short distance and will fail unpredictably. Use an active isolated converter, and confirm whether it handles direction control at your baud rate.

Q2:Is the 15 m RS-232 limit a hard rule?

No. It comes from a 2,500 pF maximum load capacitance in the standard, combined with the 20 kbps cap in the same document. With low-capacitance cable at 9,600 bps, runs of 50 m or more are common in practice. What will stop you well before capacitance does is ground potential difference, which is why the honest answer is “measure, and prefer RS-485 if you are not sure.”

Q3:Why do I need a ground wire if RS-485 is differential?

Because differential signalling removes ground from the signal path but not from the transceiver’s absolute limits. Standard RS-485 receivers tolerate the bus sitting between −7 V and +12 V relative to their local ground. On a long run between buildings with separate earths, common-mode voltage can easily exceed that, and the transceiver will misread or latch up. A third reference wire — usually through a 100 Ω resistor to limit ground-loop current — keeps you inside the window.

Q4:How many 120 Ω terminators does a bus need?

Exactly two, one at each physical end of the segment, regardless of how many devices are attached. Terminating every device puts the resistors in parallel and presents the driver with an un-drivable load. If your bus is short and slow you can sometimes get away with no termination at all, but you should never have more than two.

Q5:What causes phantom characters on an idle RS-485 bus?

A floating bus. With every driver disabled, the differential voltage wanders through the ±200 mV receiver threshold, and the receiver interprets crossings as start bits. The fix is fail-safe bias resistors — a pull-up on one line and a pull-down on the other, typically 560 Ω to 1 kΩ, at one point on the bus — or transceivers with true fail-safe receivers built in.

Q6:Can RS-485 do full duplex?

Yes, but only in 4-wire form, and the benefit is narrower than it looks. You get a dedicated transmit pair and receive pair, so a master can transmit while a slave replies. But the slave side is still one shared transmit pair with one talker at a time, so you have added cable without removing the core constraint. For most polling applications, 2-wire half duplex is correct and simpler.

Q7:Why does my device’s datasheet say “RS232 or RS485” rather than “RS232/RS485”?

Because it is a choice, not a capability. Most industrial routers — including every E-Lins model with a serial port — provide one serial interface that is built as either RS-232 or RS-485 according to the order code. If your design needs both simultaneously, you need two ports or two devices, and you should resolve that before ordering rather than after delivery.

The comparison table is the easy half.

RS-232 and RS-485 were written twenty-one years apart to answer two different questions, and every number in the comparison — the voltage swing, the distance, the node count, the topology — is a consequence of that original brief. RS-232 assumes two devices that agree about ground, close together, and gives you a simple full-duplex link with hardware handshaking. RS-485 refuses to assume anything about ground, gives up full duplex in the common 2-wire form, and buys you noise immunity, 1,200 metres, and thirty-two devices on one pair.

But the failures that actually cost you a site visit are not in the table. They are the driver enable released one character too early. The terminator on every device instead of on two ends. The bus with no bias resistors, floating through its own threshold. The star topology that reflected every edge. The 1,200 m run with no ground reference and no surge protection. And the transparent TCP tunnel that silently violates Modbus RTU’s inter-frame timing every time the network gets busy.

Get the table right, and then go and check the six things in section 06. That is the difference between a serial link that works and one you can stop thinking about.

Specifying a serial interface on a router?

Tell us the device, the node count, the distance and the protocol. We will confirm whether you need RS-232 or RS-485, which connector, and whether a Modbus gateway or a transparent tunnel is the right call.