Connecting an RS232 or RS485 field device through a 4G LTE modem is not simply a matter of attaching the serial cable and entering an IP address. The modem has to carry the existing serial exchange across a cellular session without changing the communication behaviour that the PLC, RTU, meter or instrument already expects.
A typical retrofit starts with a PLC, RTU, meter or instrument that already works over RS232 or RS485 locally, while the remote SCADA or server needs to reach it over LTE. The safest approach is to preserve that working serial exchange, then extend it across the cellular path without changing more variables than necessary.
Treat cellular as the transport layer around the existing serial protocol. First establish a known-good serial baseline. Then match the modem to that interface, choose TCP client, TCP server or UDP from the real connection direction, and validate packet handling and recovery with the same traffic the site will use in production.
The modem is one link between the serial device and the remote application
A modem can be online while the application still cannot exchange useful data. Read the path from left to right and troubleshoot the stage where the transaction stops.
1. Establish the serial baseline before adding LTE
If the device already communicates locally, preserve that working state before changing anything. One of the fastest ways to make a retrofit difficult to diagnose is to alter the field wiring, serial parameters and cellular configuration at the same time.
Before configuring the modem, verify the actual wiring from the equipment documentation rather than assuming that connector shape tells the whole story.
For RS232 equipment
Confirm the device pinout and identify the transmit, receive and signal-ground connections required by the two devices. A familiar connector does not guarantee that every manufacturer’s pin assignment is identical.
For RS485 equipment
Confirm the manufacturer’s A/B or equivalent terminal naming, the existing two-wire or four-wire arrangement where applicable, and the bus topology already used by the field installation. Do not infer polarity from connector shape alone.
Once these requirements are known, they become meaningful hardware-selection criteria. This is the right point to compare a 4G LTE modem with the field requirement instead of choosing hardware merely because the product name contains “4G” or “serial.”
2. Choose TCP client, TCP server or UDP from the connection direction
The serial device itself may know nothing about TCP or UDP. The network session exists around it, so the correct mode depends primarily on which endpoint can initiate the connection and which endpoint is reachable.
TCP client
The field modem opens an outbound TCP connection to a known server address and port. This is often the first architecture to evaluate when the central server is reachable from the cellular network.
Check first Server address, destination port, reconnect behaviour and how the server distinguishes different remote devices.TCP server
The modem listens for an incoming TCP connection. This only works when the remote application has a valid network path back to the field modem.
Check first Cellular addressing and inbound reachability before designing the project around a server mode that cannot be reached.UDP
UDP can fit applications designed around connectionless datagrams, but it does not create the same persistent session or delivery behaviour as TCP.
Check first How the application handles delivery, message boundaries and recovery when no persistent TCP session exists.3. Map the complete serial-to-cellular transaction
Cellular registration is not the same as successful serial communication. A modem can be attached to the mobile network while the application still fails because the destination address is wrong, the socket mode is reversed, the RS485 parameters do not match or the receiving software is waiting on another port.
The response must make the reverse trip successfully. The useful acceptance result is a complete application transaction, not merely an “online” modem.
Document the remote address, destination port, connection direction and expected request-response pattern. If the field equipment sends unsolicited data instead of responding to polls, record that too; the server must be prepared for the communication behaviour the device actually uses.
4. Plan for reconnect behaviour and packet framing
A bench test that works immediately after power-up proves very little about an unattended site. Cellular sessions change state. Servers restart. Sockets close. A usable installation has to return to normal communication after those events.
Establish a normal application exchange
Send the actual request and confirm that a valid response reaches the remote application through the cellular path.
Force a controlled interruption
Close the server connection or interrupt the communication path deliberately. Do not wait for a random field outage to discover how recovery behaves.
Restore connectivity
Verify how the modem and application detect the broken session and how the connection is re-established.
Repeat the real serial transaction
Recovery is proven only when valid field communication resumes—not when the modem status simply reports cellular connectivity again.
Packet framing needs a similar test. A serial port produces a stream of bytes, while the receiving application may expect meaningful messages. Depending on the implementation, a serial cellular modem can use timing, data length or other packetisation rules to decide when data is sent into the network session.
Test those rules with the production protocol rather than a short text string. The correct configuration for a meter polling application may not be the same as the configuration for a device that sends periodic event messages.
5. Validate Modbus with real field traffic, not network status alone
For Modbus RTU over RS485, do not stop after proving that arbitrary bytes can cross the cellular link. Reproduce the same polling and response sequence that the final system will use.
A useful acceptance test
- Prove the device locally before inserting the modem.
- Match the modem to the confirmed serial parameters.
- Establish the intended TCP or UDP path.
- Send real application requests and validate responses.
- Interrupt the session and verify recovery behaviour.
- Repeat several transactions after reconnection.
Evidence that is not enough
- A cellular signal indicator alone.
- A successful ping with no serial transaction.
- A text string unrelated to the production protocol.
- One successful request immediately after power-up.
- Assuming every RS485 device uses identical wiring.
- Assuming TCP server mode is always externally reachable.
For an RS485 network with several devices, test the intended bus arrangement as well. A single meter on a bench does not fully represent a multidrop installation with the same wiring, timing and polling behaviour expected at the site.
6. Choose the modem from the communication requirements
Product selection becomes much simpler once the communication path is documented. The key question is no longer “Which modem has the longest feature list?” It becomes “Which modem configuration matches this interface, protocol behaviour and network session?”
E-Lins M400 4G Modem
E-Lins lists the M400 in its industrial 4G LTE modem range. For a serial retrofit, the important step is to confirm the exact ordered interface and communication functions against the field requirement rather than assuming every configuration is identical.
7. Complete an end-to-end check before go-live
The final acceptance question is simple: can the real remote application communicate with the real field device, survive a controlled interruption and return to normal operation without an undocumented manual workaround?
What a successful deployment should prove
- The RS232 or RS485 interface and wiring have been verified from documentation.
- Baud rate, data bits, parity and stop bits are confirmed.
- The protocol and request-response relationship are understood.
- TCP client, TCP server or UDP matches the real connection direction.
- The intended server is reachable through the planned network path.
- Real protocol traffic has completed a full end-to-end exchange.
- A controlled session failure has been introduced and communication recovered.
- Packet handling has been checked using realistic production messages.
- The exact modem configuration has been matched to the project before ordering.
Frequently asked questions
Can RS485 Modbus data be sent over a 4G LTE modem?
Should a serial modem use TCP client or TCP server mode?
Do I need a serial modem, a gateway or an industrial router?
How should reconnect and packet-boundary behaviour be tested?
Prepare the serial requirement before asking for a modem recommendation
Sending a supplier only the words “RS485 modem” leaves too many design decisions unresolved. A useful project request describes the field equipment, existing serial settings and the way the remote application needs to communicate.
With these details available, E-Lins can confirm the modem configuration against the actual project instead of relying on an interface name alone.
