Modbus TCP has no specified response time — the specification leaves it open on purpose, because the same protocol has to serve sub-millisecond I/O scanners and multi-second radio links. Put an industrial 4G router in the middle and that one fact decides whether your poll succeeds. This guide picks apart the four ways Modbus actually crosses cellular, who owns the retry at each of the four layers, the timeout ladder you should be setting, and how to tell an RS-485 fault from a cellular one — then shows what an industrial Modbus gateway router does and does not do about it.
Written by E-Lins Engineering Team
Every Modbus-over-cellular project faces a common hidden risk: basic frame validation works during commissioning, but intermittent failures emerge later. The critical question is not whether Modbus can run over 4G, but how to handle rare failed requests and differentiate serial faults from radio faults when both generate identical “no response” logs on the master.
The industrial 4G router at the centre of this guide acts purely as a transport, not a Modbus participant. This distinction defines retry authority and is essential before hardware specification.
Where the Comfortable Answer Stops
Common advice states a cellular router only forwards raw bytes and does not need to parse Modbus. This is true and enables legacy RTUs to operate over cellular without reconfiguration.
However, this simplified view ignores three critical questions: what happens to failed requests, behaviour during multi-minute SIM failover and re-registration, and how to diagnose “no response” errors (slave failure, degraded RS-485, or cellular congestion). The first two can be addressed at design stage; the third drives costly on-site service calls.
| What this guide assumes you already have |
| A working Modbus master, field devices on RS-485 or Ethernet, and a cellular link that comes up and stays up. If those are not true yet, fix them first — nothing in this article will rescue a site that has not got as far as a stable data session. |
Four Ways Modbus Actually Crosses Cellular
“Modbus over 4G” is not one design. It is four, and they fail differently. The variable that separates them is not the protocol on the wire — it is where the master lives, because the master is the only component that knows what a missing answer means.
Path 1 — transparent serial tunnel
The master stays at the control centre and speaks RTU exactly as before; the router presents a serial port at the far end and carries the bytes across a TCP or UDP stream — a very long wire. It is the fastest route from “works” to “works remotely,” and the right answer for one RTU on a legacy loop carried as a Modbus RTU over IP tunnel — and the least forgiving of latency: every round trip the master used to spend on copper is now spent on a radio network, and its Modbus response timeout over LTE was not written with that in mind.
Path 2 — Protocol-aware gateway
The router or gateway is genuinely protocol-aware, speaking Modbus RTU to Modbus TCP on your behalf: it generates the transaction identifier, maps the Unit Identifier onto a serial slave address, strips and regenerates the CRC, and queues requests because RS-485 carries one at a time. This is what most people mean by a serial to cellular gateway — and it is the architecture that hides the most, which is both its value and its risk.
Path 3 — Native Modbus TCP inside a VPN
When field devices already have Ethernet there is no serial link to bridge. The router carries TCP port 502 inside an encrypted tunnel and Modbus TCP runs end to end. The Unit Identifier still travels in every frame, but the network routes on IP addresses and has never heard of slave 17. Cleanest design, fewest moving parts — provided you have solved addressing, which Section 08 covers.
Path 4 — Master at the edge
The poll engine lives at the site — in the RTU, the PLC or a small controller — and what crosses the link is not Modbus at all but registers already read, values already scaled, exceptions already handled. This is the only architecture where an outage produces no data gap, because the thing that knows about time is on the correct side of the network. It is also the only one where sub-second resolution is achievable.
| Architecture | Where the master is | What crosses the air | Who makes the retry decision | Sub-second updates |
|---|---|---|---|---|
| 1 · Transparent serial tunnel | Control centre | Raw Modbus RTU frame in a TCP/UDP stream | The remote master — over the same unreliable path | No |
| 2 · Protocol-aware gateway | Control centre, speaking Modbus TCP | Modbus TCP ADU (MBAP + PDU) | The remote master; gateway can return 0x0B | No |
| 3 · Native Modbus TCP over VPN | Control centre | TCP/502 inside IPsec/OpenVPN/WireGuard | The remote master | Rarely |
| 4 · Master at the edge | At the site | Registers, events, or a higher-level payload | The local poll engine, with the process in front of it | Yes |
| The pattern worth memorising |
| In three of the four architectures, the retry decision is made by a device on the far side of the link that is failing. Only Path 4 puts the decision-maker next to the process. If your application cannot tolerate a gap, that is the argument — not a faster modem. |
Who Retries: Four Authorities and One Legitimate Owner
Modbus has exactly one legitimate retry authority: the master. Every request is numbered by intent — the master asked, so the master decides whether asking again is right. Everything below it that also retries is either fixing a problem or concealing one, and the difference is invisible from the application layer.
Put 4G underneath and you add three more layers that retry, at wildly different time scales:
| 8 ms |
| LTE HARQ round trip at MAC/PHY — first retransmission |
| 50–100 ms |
| RLC ARQ recovery once HARQ gives up |
| 65 s |
| Median idle UDP mapping timeout on cellular CGNAT |
| 1–5 s |
| Typical Modbus TCP client response timeout in the field |
The radio layers are built to target roughly a 10% error rate on the first transmission and then correct it fast: HARQ turns a bad transport block around in about 8 ms, and only when that fails does RLC ARQ take over at 50–100 ms per recovery. Both are desirable — a recovered block never becomes a timeout. The catch nobody budgets for is that the LTE link layer delivers in sequence, so one stubborn block stalls everything behind it and the rare deep recovery shows up as a jitter spike at the worst moment in your sweep.
Above that sits TCP, which retransmits on its own schedule and, by default, will not notice a dead peer for a very long time: the Linux default keep-alive timer is 7,200 seconds. That is two hours of a socket that looks healthy to the application and is talking to nothing — the mechanism behind the most common field report we hear: “it was fine, then it stopped, and a router reboot fixed it.”
| Layer | Trigger | Time scale | What it hides from you | Who should set it |
|---|---|---|---|---|
| Modbus master | No valid response before its timer | 100 ms – 5 s, configured | Nothing — this is the honest one | You |
| TCP | Lost segment or expired RTO | ~200 ms to minutes | Whether the peer is alive at all | Leave it alone |
| LTE HARQ / RLC | Failed transport block | 8 ms / 50–100 ms | How bad the radio really is | The network |
| Router link check + failover | Failed keep-alive probes | Tens of seconds to minutes | How long the link was actually gone | You, from measurement |
| Why tightening the timeout makes it worse |
| The Modbus specification deliberately declines to define a response time, because one protocol has to serve both sub-millisecond I/O scanners and multi-second radio links. What it does require is that the client timeout exceed the worst reasonable response time. Set it shorter and your retries arrive while the original answer is still in flight, congesting the device and the network — and generating precisely the errors you were trying to eliminate. Anyone who has “fixed” a flaky poll by shortening the timeout has met this mechanism from the wrong end. |
The Timeout Ladder You Should Actually Be Setting
Most sites inherit one timeout value from a template and never revisit it. That is tolerable on a serial loop and expensive on cellular, because the ladder spans five orders of magnitude — from four milliseconds of RS-485 silence to ten minutes of stale-data tolerance. Here is the ladder, bottom to top, with the numbers we recommend as a starting point.
| Rung | What it governs | Recommended starting value | Symptom when wrong |
|---|---|---|---|
| t1.5 / t3.5 framing | RS-485 frame boundaries | 1.72 ms / 4.01 ms at 9600; fixed 1.75 ms above 19200 — identical at both ends | Truncated frames, CRC errors that follow no pattern |
| Slave turnaround | Device processing before it answers | Measure it; 10–200 ms typical, VFDs and analysers longer | One device always times out, others never do |
| Serial transaction | Bytes on the wire | ~57 ms for 10 registers at 9600; ~23 ms at 115200 | Sweep time quietly doubles when you add slaves |
| Cellular RTT + jitter | The air hop, both directions | 40–80 ms typical, 150–300 ms loaded, jitter 50–150 ms | Errors that correlate with time of day |
| Modbus response timeout | How long the master waits | 1,000 ms minimum; 2,000 ms if you run a slow slave | Retries that congest the device; or silent data loss |
| Keep-alive interval | Keeping NAT state alive | ≤ 60 s for TCP, ≤ 30 s for UDP | “Works for twenty minutes after a reboot, then stops” |
| Stale-data tolerance | When the HMI admits the value is old | ≥ 3 × your worst measured failover — north of 10 min on a conservative profile | Operators learn to ignore alarms |
The keep-alive rung is the one that only exists once cellular does. Carrier-grade NAT is not an exception in mobile networks — it is the norm, with over ninety percent of cellular autonomous systems relying on it, and measured idle UDP mapping timeouts clustering around 65 seconds with a spread from ten seconds to over three minutes. Idle TCP lasts longer, typically five to fifteen minutes, but both are far shorter than any default. If your tunnel is idle overnight, the state that made it reachable ages out and the first poll of the morning goes nowhere.
| One rule that beats all the others |
| Set the keep-alive interval to comfortably less than half the shortest timeout any device on the path can apply, and set the Modbus response timeout to more than the worst round trip you have actually measured — not the one you hope for. Everything else on the ladder is tuning. |
What Each Architecture Does During a Ninety-Second Outage
A cellular link that never fails is not a design assumption, it is a wish. The useful question is what the outage does to your data — ninety seconds, or the two and a half to three and a half minutes we have measured for detection, SIM switch, re-registration and tunnel re-establishment on a conservative dual-SIM profile. The four architectures answer very differently, and the differences are entirely about where the clock lives:
The differences matter most where they are least visible. In Paths 1 and 2 the failure is honest: a request went out, nothing came back, and the gap in your historian is exactly as long as the outage. Path 3 is the one that should worry you, because TCP can recover the session and deliver an answer to a question the master already gave up on — a value that looks perfectly plausible and carries a timestamp nobody questions.
| Architecture | What the master sees | What the historian gets | Who notices first |
|---|---|---|---|
| 1 · Transparent tunnel | Timeouts, then success | A gap the length of the outage | Nobody, unless you alarm on staleness |
| 2 · Protocol gateway | Exception 0x0B or 0x0A, then success | A gap, but a logged one | The master’s log |
| 3 · Native Modbus TCP | Timeouts, possibly a late duplicate | A gap, or worse, a late value with a plausible timestamp | Nobody — this is the dangerous one |
| 4 · Master at the edge | Nothing unusual | Continuous, with original timestamps | Nobody needs to |
| What we will not claim |
| An industrial router does not store-and-forward Modbus. It will not hold your requests and replay them, and it will not answer on behalf of a slave that is not talking. Buffering with timestamps is the job of the RTU or PLC at the site. Buy the router for the transport and design the buffering where the process knowledge actually lives. |
The Serial Bottleneck: Why TCP Pipelining Flattens on RS-485
Modbus TCP permits outstanding requests. The two-byte transaction identifier exists so a client can have several transactions in flight and match each answer to its question when they come back out of order — a genuine advantage over its serial ancestor.
None of that survives contact with a half-duplex RS-485 loop. The bus carries one conversation at a time, so a gateway must serialise everything arriving on the TCP side into a queue — and the response time your master measures now includes the queueing delay behind every request ahead of it. Ask for more concurrency than the device or gateway can hold and you will be told so, though not in terms you would choose: exception 0x06, which on Modbus TCP usually means no free transaction slots. The practical consequence is that you are queue-bound, not bandwidth-bound: adding bandwidth changes nothing, while reducing the number of transactions changes everything.
| Baud rate | Character time (11 bits) | t3.5 framing silence | 10-register transaction* | 15-slave sweep | Share of the transaction that is overhead |
|---|---|---|---|---|---|
| 9,600 | 1.146 ms | 4.01 ms | ≈ 57 ms | ≈ 0.9 s | 32% |
| 19,200 | 0.573 ms | 2.00 ms | ≈ 33 ms | ≈ 0.5 s | 42% |
| 38,400 | 0.286 ms | 1.75 ms (fixed) | ≈ 23 ms | ≈ 0.35 s | 59% |
| 115,200 | 0.095 ms | 1.75 ms (fixed) | ≈ 17 ms | ≈ 0.26 s | 81% |
| The order-time trap, restated |
| Every model in our range except one gives you a single serial port, configured at the factory as RS-232 or RS-485 — chosen when you order, not switchable in the field. One port means one multidrop loop, which means every device on it shares the sweep. The H700 is the exception: it carries two serial connectors (one DB9, one terminal socket) and can therefore run two independent loops without crosstalk. If your site genuinely needs two baud rates, two loop speeds, or clean separation between a metering loop and a control loop, that is the model to ask about. |
Polling Arithmetic: What One Poll Cycle Actually Costs You
Once Modbus TCP polling over cellular crosses the air, the poll interval you can sustain is no longer set by your baud rate. It is set by the number of transactions multiplied by a round trip, because in a serial-backed architecture each transaction has to wait for the network before the next one can start.
The arithmetic is short and it is worth doing on paper before you argue with a vendor — it gives you the Modbus sweep time that everything else depends on:
| Baud rate | 15-slave sweep, serial only | + one cellular round trip per transaction (60 ms) | Sustainable poll interval |
|---|---|---|---|
| 9,600 | 0.90 s | + 0.90 s | ≥ 2 s |
| 19,200 | 0.50 s | + 0.90 s | ≥ 2 s |
| 38,400 | 0.35 s | + 0.90 s | ≥ 2 s |
| 115,200 | 0.26 s | + 0.90 s | ≥ 2 s |
Read that last column again. Raising the baud rate twelvefold, from 9,600 to 115,200, moves the total sweep from about 1.8 seconds to about 1.16 seconds — a thirty-five percent improvement, because the cellular round trip is now the dominant term and it does not care how fast your serial link is.
This is also where the architecture argument becomes concrete rather than philosophical. If your process genuinely needs one-second updates — pump control, fast level tracking, anything with a control loop around it — then no amount of tuning will get Modbus across the air and back in time. Move the poll engine to the site (Path 4) and let the cellular link carry results instead of questions.
| If you need updates at… | Then… | Why |
|---|---|---|
| < 1 s | Put the master at the edge; do not poll across the air | One round trip per transaction makes it arithmetically impossible |
| 1–10 s | Native Modbus TCP over VPN, few slaves, tight register blocks | Keep the transaction count low; every one costs a round trip |
| 10–60 s | Any architecture works; choose on outage behaviour and addressing | You have time; optimise for the gap, not the latency |
| > 60 s | Optimise for data volume and battery, not for speed | Latency is irrelevant; payload efficiency and keep-alive cost dominate |
| The cheapest optimisation is fewer transactions |
| Reading ten contiguous registers in one FC03 costs 33 bytes on the wire. Reading those same ten values as ten separate requests costs ten round trips. Before you touch a baud rate or a timeout, look at whether your register map lets you read contiguously — it is the only change on this list that is free |
Addressing Across the Gap: Unit ID, IP, Port and Who Dials Whom
On an RS-485 loop a slave is identified by one byte: 1 to 247, with 0 for broadcast and 248 to 255 reserved. The loop is the addressing scheme, and everyone on it hears everyone else. Cellular dissolves that. The Unit Identifier still travels in every Modbus TCP frame, but it is now an application-layer relic — and Modbus Unit ID routing becomes somebody’s job. A gateway receiving a request for a Unit ID it cannot map will say so with exception 0x0A or Modbus exception 0x0B; a slave that simply is not there produces silence instead. Knowing which of those two you are looking at is often the whole diagnosis.
| Identity layer | Who sets it | Visible to the network? | Failure symptom when wrong |
|---|---|---|---|
| Unit ID (1–247) | Device dip switches or firmware | No — it is inside the payload | Exception 0x0A / 0x0B, or silence |
| IP address | Router LAN, DHCP, or VPN | Yes | Connection refused or timeout |
| TCP port 502 | Device; 502 is mandatory and must stay available | Yes | Connection refused |
| VPN interface / tunnel | You, at the router | Yes | Tunnel up but nothing reachable behind it |
Then there is the question that catches projects late: which end initiates the connection? On a public APN the answer is forced. Carrier-grade NAT is the norm in mobile networks rather than the exception, and it blocks unsolicited inbound traffic by design — port forwarding cannot bypass it, because the carrier has no way to know which subscriber an inbound packet was meant for. A cloud master that expects to open a TCP connection to a site router will simply fail, on a plan that looked identical to the one that worked in the workshop.
| Connectivity option | Direction | Works behind CGNAT? | What you must plan for |
|---|---|---|---|
| Standard public APN | Outbound only | Outbound only | Router-initiated tunnels; keep-alive ≤ 60 s |
| Static public IP plan | Both | Yes | Cost, provisioning lead time, per-SIM |
| Private APN / M2M plan | Both, inside the carrier’s network | Yes | Carrier contract; still needs a VPN for encryption |
| Router-initiated VPN (IPsec / OpenVPN / WireGuard) | Outbound establish, then bidirectional | Yes | Our default recommendation for Modbus |
Two details that save an afternoon. Port 502 is mandatory on the server side, but the client’s local port must be above 1024 and unique per connection — worth knowing before someone writes a firewall rule permitting 502 in both directions. And Modbus TCP has no authentication and no encryption of its own; anything that can reach port 502 can write to a coil. The registered security variant on port 802 with mutual certificates exists and is, in our experience, almost never deployed on equipment people already own. In practice the answer is a Modbus over cellular keepalive inside an always-on VPN plus strict firewalling, and keeping Modbus on a segment where no browser has ever been.
Fault Catalogue, Part One: Eight Signatures You Can See From the Router Side
Modbus fault diagnosis over cellular is mostly a problem of instruments in the wrong place. The master logs transactions; the router logs bytes; the serial loop logs nothing at all. Here are the eight signatures we see most often, in the order we check them.
| # | Signature | First thing to check | Likely layer |
|---|---|---|---|
| 1 | CRC error count climbing, round-trip time flat | Termination resistor, bias resistors, cable type, VFD proximity | RS-485 physical |
| 2 | Master logs “no response” several times, then recovers on its own | Cellular jitter during that window; correlate with time of day | Radio |
| 3 | Exception 0x0B on every request to one Unit ID | Whether the Unit ID maps to anything at the gateway | Gateway mapping |
| 4 | Exception 0x06 when you raise concurrency | How many transactions the device or gateway can actually hold | Queue depth |
| 5 | An answer arrives carrying a transaction ID the master already gave up on | Whether TCP reconnected and replayed; look for a duplicate value | TCP session |
| 6 | Works for twenty minutes after a reboot, then stops | Keep-alive interval against the carrier’s idle mapping timeout | CGNAT / NAT |
| 7 | Fails at the same hour every day | Sector congestion, not your equipment; check RSCP/RSRQ history | Radio capacity |
| 8 | Whole sweep fails once, immediately after a SIM switch | Half-open sockets; whether the master re-establishes cleanly | Session state |
Signatures 6 and 8 share a root cause and look nothing alike. A carrier NAT mapping that ages out after a minute of silence kills a tunnel that was idle overnight; a dual SIM Modbus failover taking two to three minutes kills a sweep mid-flight. In both cases the master reports the same useless sentence — “no response” — and in both cases the fix is a keep-alive or a stale timeout, not a new router.
Fault Catalogue, Part Two: Serial Degradation or Cellular Loss?
To settle serial vs cellular disputes, collect three parallel datasets over 30 minutes: master transaction logs, router WAN counters and serial bus tap capture.
| Field result · Regional water utility, 62 lift stations |
| “We spent four months arguing about whether it was our radios or their wiring. The answer was visible in half a day once somebody left a serial tap on the loop overnight: the CRC errors tracked humidity, not signal. Two loops had no termination resistor at the last device and one had the drain bonded at both ends. The cellular link had been fine the whole time.” |
| What changed: 58% of tickets logged as “network fault” were closed as serial faults; mean time to fault attribution fell from eleven days to under two; no hardware was replaced on the carrier side. |
| What you observe | What it means | Where to look first |
|---|---|---|
| CRC errors rise, RTT flat and low | Serial problem | Termination, bias, screen bonding, H2S corrosion on copper, ground loops, VFD noise |
| RTT and jitter rise, CRC count flat | Cellular problem | Signal, band, sector load, failover history, antenna siting |
| Both rise together | Power or earthing | Supply sag during pump starts, shared earth, lightning damage |
| Neither rises, but requests fail at random | Session state | Half-open sockets, NAT expiry, transaction ID exhaustion |
| Errors correlate with pump or VFD starts | Serial or power | Screen termination, cable routing, supply decoupling |
| Errors correlate with shift changes or evenings | Cellular capacity | Sector congestion; consider a second carrier on the second SIM |
One caution about the router’s own counters: they report failed bytes, not failed transactions. A perfectly healthy cellular link can carry a Modbus conversation that fails for reasons the router will never see — a wrong register offset, a byte-order disagreement, a slave busy with its own housekeeping. Instrument only the router and you will conclude the network is fine; you will be right, and you will still not have found the fault.
| Corrosion is a two-year time bomb, not a commissioning fault |
| In wastewater environments, hydrogen sulphide attacks copper slowly. The loop that commissioned perfectly will, eighteen to thirty months later, start producing intermittent faults that correlate with humidity rather than with anything you changed. If your CRC count climbs gradually over seasons rather than stepping up one day, suspect the copper and the terminations before you suspect the router or the carrier. |
What Our Range Actually Gives You for Modbus
Not all E-Lins routers suit Modbus serial polling. Two critical criteria: presence of serial port and Modbus/DTU feature support.
| Model | Serial port | Modbus / DTU | SIM | Notes for Modbus sites |
|---|---|---|---|---|
| H700 | 2 (DB9 + terminal) | Modbus supported | Dual | The only dual-serial unit — two independent loops |
| H720 | 1 · RS232 or RS485 | Modbus and DTU | Dual | Balanced choice for single-loop sites |
| H750 | 1 · RS232 or RS485 | Modbus supported | Dual | DI inputs are 0–3.3 V logic; order the 5–40 V board for 24 V signals |
| H820 | 1 · RS232 or RS485 | Modbus and DTU | Dual | Five Ethernet ports for mixed serial + Ethernet sites |
| H900t | 1 · RS232 or RS485 | Modbus and DTU | Dual | Five Ethernet ports; H900 offers dual-modem dual-SIM online option |
| H685t | 1 · RS232 or RS485 | DTU parameters documented | Single | H685w is 3G WCDMA — not for new builds |
| H820QO | 1 · RS232 or RS485 | Listed as supported | Single (dual option) | The only IP68 unit; confirm the serial configuration before ordering |
Every unit is an IP30 metal case with anti-lightning protection except the H820QO, which is IP68. Operating range is −35 °C to +75 °C at 5–95% relative humidity, non-condensing, with dual power inputs and failover at 5–40 V DC (5–60 V DC optional). Where condensation rather than ingress is the enemy — in water and wastewater it usually is — that non-condensing limit is the specification to design around.
Pre-Commissioning Checklist
Complete before site handover:
- Confirm the serial port type in writing. RS-232 or RS-485, fixed at order time, on every unit in the shipment.
- Set t1.5 and t3.5 identically at both ends and record baud rate, parity, data bits and stop bits on the panel schedule.
- Measure the slave turnaround for the slowest device on the loop with a serial tap, and write that number into the timeout calculation.
- Set the Modbus response timeout from measurement — serial round trip plus turnaround plus twice the worst cellular RTT you have observed, rounded up. One second is a floor, not a target.
- Set the keep-alive interval to 60 seconds or less for TCP, 30 seconds or less for UDP, and confirm it against the carrier’s own idle timeout.
- Set the stale-data tolerance to at least three times your worst measured failover — north of ten minutes on a conservative dual-SIM profile.
- Confirm who dials whom. If the SIM is behind CGNAT, the site must initiate, and the tunnel must be up before any master asks a question.
- Verify the Unit ID map at the gateway, one device at a time, and confirm that an unmapped ID produces an exception you can see rather than silence.
- Pull the primary SIM and time the full recovery with a stopwatch, end to end, with the master running. Record the number on the site record.
- Instrument the master, not just the router. Log transactions, exception codes and round-trip times for thirty days.
Frequently Asked Questions
Q1：Can I run Modbus RTU over 4G without changing my master?
Usually yes, with a transparent serial tunnel: the master keeps speaking RTU at its configured baud rate and never learns a network is involved. What you almost always will change is the response timeout — a value tuned for a few metres of copper is shorter than a round trip over a loaded cell sector, so the master retries before legitimate answers arrive.
Q2：What Modbus response timeout should I use over cellular?
Build it from measurements: serial round trip plus the slowest slave’s turnaround plus twice the worst cellular round trip you have observed, then round up. That lands at one second or more for a 9,600-baud loop, and should never go below 500 ms. The specification sets no response time; it only requires that your timeout exceed the worst reasonable one.
Q3：Does the router buffer Modbus data while the link is down?
No. It is a transport and does not store-and-forward Modbus. For an unbroken record across an outage, buffering has to happen at the site, in the RTU or PLC, with timestamps and quality flags on each record. That is an architecture decision (Path 4), not a router feature.
Q4：Why does the link work for twenty minutes after a reboot and then stop?
Almost always an idle-state expiry rather than a fault. Carrier NAT mappings typically age out after a median of about 65 seconds for UDP and five to fifteen minutes for idle TCP, while default TCP keep-alive timers are measured in hours. Set a keep-alive at 60 seconds or less and the symptom disappears.
Q5：Can my control-centre master poll the site directly?
Only if the site is reachable. On a standard public APN behind carrier-grade NAT — the norm, not the exception — inbound connections are blocked and port forwarding cannot bypass it. Either order a static public IP or private APN plan, or have the router initiate an always-on VPN and poll through it. We recommend the second.
Q6：How many slaves can I put behind one serial port?
The protocol allows 247 addresses, but your real limit is sweep time. With ten-register reads at 9,600 baud, fifteen slaves already costs about 0.9 seconds on the wire, and once each transaction also waits for a cellular round trip the total roughly doubles. Size the loop by the update rate you need, then check the baud rate.
| The short version |
| Modbus crosses 4G easily. What does not cross easily is responsibility — and that is what breaks projects. Decide where the master lives before you choose hardware, because that one decision determines who retries, what a ninety-second outage costs you, and whether the gap appears as a logged exception or as a plausible value nobody questions. Then set the ladder: framing identical at both ends, response timeout from measurement rather than from a template, keep-alive short enough to survive carrier NAT, stale tolerance long enough that operators still trust the alarm. And instrument the master, not just the router, because the router will tell you about bytes while your problem is in transactions. None of this requires a faster modem. It requires knowing which clock you are living on. |
Send us your Modbus numbers
Tell us how many slaves, what baud rate, what poll interval and where your master sits, and we will return a sweep-time model, a timeout ladder for your specific link, and a router configuration built around the serial ports you actually need.
