In building automation circles, a recurring question comes up: a laptop running CCT or PCT, a BACnet MS/TP device on the bench, and the wish to bridge the two through an RS485 to Ethernet converter (Serial to Ethernet Converter) so the device can be reached over IP. The link does half of that job out of the box. The other half — a protocol layer that sits in the middle — is where things start to fall apart. Below is a walk through what each option actually does, and where the line is drawn between a plain serial gateway and a full BACnet Router.

Three layers that keep getting mistaken for one

The confusion usually starts by collapsing three separate protocols into a single idea. Each layer has a different job:

• RS485is a physical layer. It defines voltage levels, differential signalling, node count, and termination. It carries no opinion about the "raw bytes" on top.

• BACnet MS/TPis a data-link layer that rides on RS485. It uses HDLC framing and a token-passing scheme to arbitrate access on a shared bus. It is a BACnet-native link protocol and is not interchangeable with standard Modbus RTU.

• BACnet/IPis an application layer that rides on Ethernet. It uses UDP port 4789 by default, which is also where CCT and PCT connect.

An RS485-to-Ethernet converter can bridge the physical sides of those wires. What it moves is bytes, not BACnet packets. Whether a BACnet tool on the IP side sees anything depends on the role the converter ends up playing on each side of the bus.

Two usage patterns, two very different outcomes

Usage A — CCT debugs an MS/TP device directly, with no BACnet/IP backbone in the picture.

In this setup, CCT acts as a TCP Client against a transparent serial gateway, and bytes are passed through to the MS/TP device unchanged. Two details matter on the wire:

• An MS/TP bus only supports one active master at any given moment. During the debug session, the original master on the MS/TP segment has to be disconnected, or the gateway's RS485 tap has to be unplugged, so two masters do not collide on the token.

• Once the session ends, the converter comes out and the existing master is restored.

For this kind of use,a plain transparent serial gateway is enough.

Usage B — the MS/TP device joins the building's existing BACnet/IP backbone.

In this setup, CCT sitting on the IP network sends Who-Is, reads Present-Value, and maintains an object list. The expectation is that any device hanging off an MS/TP sub-net is auto-discovered and stays pollable across segments. To make that work, the gateway has to:

• Translate NPDUs at the MS/TP ↔ IP boundary — Who-Is / I-Am, ReadProperty, ReadPropertyMultiple, Confirmed / Unconfirmed services, ConfirmedPrivateTransfer, and the rest of the BACnet service calls.

• Run the MS/TP token schedule on its side of the wire, and answer I-Am on behalf of devices sitting behind it.

• Provide "virtual MAC" proxying and forwarding so traffic can move across segments under a single BACnet network number.

That is not something byte-level passthrough can do. It needs a BACnet Router, or at minimum an industrial gateway with BACnet Routing capability.

Three checks to decide whether a BACnet Router is required

1. The job is to reach a single MS/TP device, with the bus temporarily handed to one PC during the session → passthrough is enough.

1. The MS/TP device needs to live inside a building-wide BACnet/IP monitoring platform, or be reachable from multiple workstations → a BACnet Router is required.

1. Several MS/TP subnets need to interwork, or a non-Ethernet BACnet link (ARCNET, PTP) is in the picture → a BACnet Router is required.

Where PUSR's RS485 to Ethernet converters sit in this picture

The PUSR lineup is positioned on the RS485 ↔ Ethernet transparent-serial and Modbus-gateway side. It does not, on its own, carry BACnet Router functionality. Worth flagging that boundary clearly before any shortlist goes out.

If the project is in Usage A — a single-point debug session on site — the classic USR-TCP232-410s lines up directly:

• Dual serial ports, with one RS485 and one RS232 runnable simultaneously. Baud rate runs 600 to 230.4 Kbps, which covers the common MS/TP rates.

• Working modes cover TCP Server/Client, UDP, HTTP, and MQTT. CCT connecting as a TCP Client is the path that puts MS/TP bytes on the wire transparently.

• Built-in Modbus TCP/RTU conversion plus edge acquisition of up to 128 data points exported as JSON, so the same box can also pull a register snapshot while the session is open.

• Industrial-grade mechanics: metal housing, wide-voltage DC input, operating temperature -40 to +85 °C, hardware plus software dual watchdog, certified to CE / FCC / ROHS / WEEE / RCM. Suited for permanent mounting inside distribution boxes or low-voltage cabinets.

• A wiring note for the bench: during a debug session, either cut off the existing MS/TP master, or unplug the 410s RS485 lead, so two masters cannot collide on the token bus.

When the on-site debug job is done and the next step is pushing data to the cloud, the USR-N720 takes over. It carries two RS485 ports plus one Ethernet port, converts Modbus/DL/T 645 to MQTT plus JSON, supports SSL and SD-card caching, and mounts on either DIN rail or wall. That footprint covers a Modbus/DL data-to-cloud use case — still not a BACnet Router.

If the project drifts into Usage B — MS/TP ↔ BACnet/IP routing, Who-Is forwarding across segments, multi-master scheduling — that path is outside what these two boxes cover. A separate industrial gateway that actually advertises BACnet Routing capability would need to be the first pick. Only after that is the RS485 interface form-factor of the BACnet Router itself worth discussing.

One line to keep in mind

An RS485 to Ethernet converter moves bytes. Making an MS/TP device discoverable by CCT and pollable by a building's BACnet/IP network is a BACnet Router's job, not a byte-gateway's. On the procurement side, those two belong on different lines.