“Our PLC needs real-time. Can you do it over 4G?” is the wrong question. The right one is a number. This guide turns industrial cellular router selection into an arithmetic problem: measured LTE round-trip times, tunnel overhead, Modbus RTU polling maths, timeout sizing and dual SIM failover windows — with the sums shown.
Written by E-Lins Engineering Team
A controls engineer once asked us, during a commissioning call, whether our router could “do real-time over 4G”. The honest answer is that the question cannot be answered as asked — because real-time is not a feature. It is a budget. Once you write the budget down, most of the fear disappears, and the remaining 5% of cases become obvious: they were never router problems in the first place.
This guide is that budget, written out. It is for the engineer who has to specify an industrial cellular router for a working production line, a SCADA or MES system that wants data from it, and no fibre run to the machine. We work through the measured latency of public cellular, what an encrypted tunnel adds, why the slowest part of a Modbus RTU over cellular link is almost never the cellular part, how to size a timeout so one failed slave does not stall the scan, and how long dual SIM failover in industrial automation actually leaves you blind.
Where we quote a number, we say where it comes from. Where our own hardware is the wrong answer, we say that too — because the fastest way to lose a year on an automation project is to put a router where a PLC belongs.
“Real-Time” Is a Budget, Not a Feeling
Every automation cell runs on more than one clock, and conflating them is the root of most cellular anxiety. There are three, and they differ by three orders of magnitude.
| Clock | Typical period | What breaks if it slips | Cellular acceptable? |
|---|---|---|---|
| Clock 1 — Machine / safety PLC scan, motion loop, interlock | 1–50 ms | Product damage, injury, unplanned stop | No — never |
| Clock 2 — Supervisory HMI, SCADA polling, historian | 100 ms – 5 s | Stale screen, missed trend point | Sometimes — if engineered |
| Clock 3 — Enterprise / cloud OEE, analytics, remote service, firmware | 10 s – 24 h | Late report, delayed truck roll | Yes — designed for it |
The discipline is simple: Clock 1 must close locally. No cellular router, and no amount of 5G marketing, belongs inside a safety function or a motion loop. A router is a WAN device. Its job is Clock 3, plus a resilient backup path for Clock 2. Almost every “we need real-time over 4G” conversation turns out to be a Clock 2 or Clock 3 requirement wearing a scary label — and once the rows are sorted, the question becomes “is 4G fast enough for this row“, which has a number in it.
| The one rule that is not negotiable |
| A cellular router must never be the only path for a function whose failure can hurt someone. Emergency stops, safety interlocks, overspeed and over-temperature trips belong on hardwired or safety-rated fieldbus circuits, governed by IEC 62061 / ISO 13849 — not on a WAN link whose latency is a function of how many people are streaming video on the same tower. |
What the Cellular Link Actually Adds
Cellular latency is not a constant; it is a distribution whose shape depends on radio conditions and sector load. The figures below are round-trip times compiled from carrier documentation and third-party drive-test data for public LTE and 5G non-standalone networks — typical values, not guarantees. Treat them as planning inputs, then measure your own site.
| Link | Idle RTT | Loaded RTT | Jitter | Reads as |
|---|---|---|---|---|
| Fibre (GPON) | 5–15 ms | 10–25 ms | < 2 ms | Baseline |
| Cable (DOCSIS 3.x) | 15–30 ms | 30–60 ms | < 5 ms | Baseline |
| 4G LTE, good RF | 40–80 ms | 80–200 ms | 10–50 ms | Usable for Clock 2 |
| 4G LTE, congested sector | 150–300 ms | 300–500 ms | 50 ms + | Clock 3 only |
| 5G sub-6 GHz public NSA | 20–40 ms | 40–100 ms | 5–20 ms | Better, not different |
| 5G URLLC (target / private) | < 10 ms | < 10 ms | < 1 ms | Private network only |
| Satellite (GEO) | 550–700 ms | 700–1200 ms | High | Store and forward |
It also explains why a 5G router for industrial automation is a throughput decision more than a latency one: public sub-6 GHz 5G trims RTT to roughly 20–40 ms, while sub-10 ms belongs to URLLC on private spectrum.
What the Tunnel Adds (and the Myth About Modbus)
Encryption costs bytes and CPU cycles. How many depends on the cipher and the mode — and this is where otherwise careful designs get their MTU wrong.
| Tunnel type | Overhead per packet | Effective MTU on 1500 B link | Practical setting |
|---|---|---|---|
| GRE only (no encryption) | 24 B | 1476 B | Trusted links only |
| IPsec ESP, AES-128-GCM | 50–58 B | 1442–1450 B | ip mtu 1438 · adjust-mss 1398 |
| IPsec ESP, AES-256-CBC + SHA2 | 62–74 B | 1426–1438 B | ip mtu 1420 · adjust-mss 1380 |
| GRE over IPsec + NAT-T | 84–96 B | 1404–1416 B | ip mtu 1400 · adjust-mss 1360 |
| WireGuard (IPv4) | 60 B | 1440 B | Fastest recovery after IP change |
| OpenVPN over UDP | 36–60 B + 28 B | ~1412–1436 B | Avoid TCP mode |
Here is the myth, and it is worth killing explicitly: an IPsec tunnel does not slow down your Modbus polls by fragmenting them. A Modbus/TCP request for ten holding registers is roughly 12 bytes of payload plus a 7-byte MBAP header. Even with 96 bytes of tunnel overhead you are at about 115 bytes on the wire — nowhere near any MTU. Fragmentation bites the other traffic on the link: firmware images, HMI page loads, historian backfills, log uploads. Those are the packets that hit 1500 bytes, get pushed over the tunnel MTU, fragment, and then reassemble badly on a lossy radio link.
What encryption does cost Modbus is per-packet processing — negligible at a few hundred tags, material at a thousand a second in software AES-256-CBC. For IPsec VPN for SCADA at scale, prefer AES-GCM where hardware supports it: no separate HMAC pass, no block padding, eight bytes instead of sixteen of IV — 20–47 bytes and a real slice of CPU saved per packet.
| One configuration line prevents most tunnel tickets |
| Set the tunnel MTU explicitly and clamp TCP MSS to MTU minus 40. Do not rely on Path MTU Discovery alone — plenty of carrier and firewall paths silently drop the ICMP “fragmentation needed” message, and the symptom is a link where pings work and HTTPS hangs. That is an MTU problem wearing a latency costume. |
The Serial Floor: RS-232 or RS-485, and the Order-Time Trap
Before any WAN maths matters, there is a harder constraint underneath it: the serial link to the machine. In brownfield automation this is where projects go wrong, and the most common cause is one line in our own datasheets.
| Read this line carefully before you order |
| Our specifications say “Serial Port RS232 or RS485”. That is one physical port, configured at order time as either RS-232 or RS-485 — not two ports, and not a port you can switch in the field. If your scope of supply assumes both, the order is wrong, and you will find out on the day the cabinet is being terminated. |
The whole range carries Modbus and DTU (serial to cellular gateway) functionality — the capability that makes these routers useful in automation at all. The router terminates the serial bus locally and carries Modbus across IP, so a 1990s drive on an RS485 industrial router becomes a reachable Modbus/TCP slave without touching the machine programme. But the physical interface varies by model:
| Model | Serial interface | Serial ports | DI/DO | Note for automation |
|---|---|---|---|---|
| H700 | RS-232 or RS-485 | 2 | 4 | Only model with two serial ports; 5× GbE switchable WAN/LAN |
| H900t | RS-232 or RS-485 (terminal socket) | 1 | 4 | Dual modem dual SIM online option — no re-dial on failover |
| H900f / H900pf / H900uf | RS-232 or RS-485 (terminal socket) | 1 | 4 | 5G; PoE PD or PSE depending on variant |
| H820 | RS-232 or RS-485 (DB9) | 1 | 4 | DB9 plus on-board console; PoE PD or PSE |
| H750 | Serial port | 1 | 4 | Adds MicroSD card slot for local buffering |
| H685f | RS-232 or RS-485 | 1 | 4 | Compact; PoE PD 802.3af/at(/bt on H685f) |
| H685t | RS-232 or RS-485, built-in terminal block | 1 | 2 | Half the I/O of its siblings — check before specifying |
| M400 | DB9 or DB15 or terminal block + USB | 1 | — | Smallest option where you need serial at all |
| H820QO | None | 0 | 0 | IP68 outdoor unit — Ethernet and cellular only |
| H685m | None | 0 | 0 | 5G modem, not a router: no Modbus, no DTU, no I/O |
Two traps hide in that table. H685t has two DI/DO rather than the family’s usual four — easy to miss when copying a bill of materials. H685m is a 5G modem, not a router: no serial, no Modbus, no digital I/O. If your design needs a serial to cellular gateway, H685m is the wrong line item.
Modbus Polling Arithmetic: Where the Milliseconds Actually Go
This is the section to keep. Modbus RTU is request-and-response over a half-duplex bus, and the cycle time is arithmetic you can do on the back of an envelope — which means it is also arithmetic you can get wrong there.
A character on the wire is 11 bits (1 start + 8 data + 1 parity + 1 stop): 1.146 ms per byte at 9600 baud. Frames are delimited by silence — t3.5 is 3.5 character times, so 4.01 ms at 9600 baud, and above 19200 baud the specification fixes t1.5 at 750 µs and t3.5 at 1.750 ms because UARTs and operating systems cannot resolve shorter gaps. A complete transaction is therefore:
| The transaction you are actually timing |
| T = request frame + slave processing + response frame + t3.5 silence. For a read-holding-registers (FC3) of N registers: request = 8 bytes, response = 5 + 2N bytes. Count the silence once per transaction, not once per frame, and never omit the slave’s own processing time. |
Work it at 9600 baud, ten registers, a reasonably quick slave: request 8 B × 1.146 = 9.2 ms; slave processing ≈ 15 ms; response 25 B × 1.146 = 28.7 ms; silence 4.0 ms. Total ≈ 57 ms per transaction. Poll fifteen slaves once each and the scan is 15 × 57 ms ≈ 0.9 seconds. If your SCADA wants a one-second update you are already at the limit — at 9600 baud, with ten registers and a fast slave.
| Baud | Per transaction (10 reg, 15 ms slave) | 10 slaves | 15 slaves | 25 slaves |
|---|---|---|---|---|
| 9 600 | ~57 ms | ~570 ms | ~855 ms | ~1 425 ms |
| 19 200 | ~37 ms | ~370 ms | ~555 ms | ~925 ms |
| 38 400 | ~27 ms | ~270 ms | ~405 ms | ~675 ms |
| 115 200 | ~23 ms | ~230 ms | ~345 ms | ~575 ms |
Look at the shape of that table, because it holds the most useful lesson here. Going from 9600 to 38400 baud cuts the frame time by four — but the 15 ms of slave processing does not move, so the transaction only falls from 57 ms to about 27 ms. Raising the baud rate compresses the framing; it cannot compress the slave. If slow devices rather than long frames dominate your scan, a faster baud rate will disappoint you.
That leads to the highest-leverage optimisation available: batch your reads. Fixed per-transaction overhead dominates, so one read of forty registers beats four reads of ten by a wide margin. Where a bus mixes fast I/O with slow legacy instruments, put the slow devices on their own port — precisely where the H700’s second serial port earns its keep.
Timeouts: The Number That Decides Whether the Line Stops
If one configuration value separates a stable cellular automation link from a permanently broken one, it is the timeout — and it is also the value most often set by copying a default from a wired installation.
The sizing rule that works, with a safety factor on top, is:
| Timeout rule of thumb |
| Scan rate ≥ 1.5 × Σ(transaction times) + N × slave processing time. Use 2.0× as the safety factor in production. Then, for the Modbus/TCP timeout on the far side of a cellular link, add the round trip and the jitter on top: TCP timeout ≥ local serial timeout + 2 × RTT + jitter margin. |
At 9600 baud with a typical slave, published practice puts the minimum practical serial timeout at 500 ms, with 1000 ms recommended. Add a 4G link — two round trips at 80 ms is 160 ms, plus 100 ms of jitter allowance — and you land near 800–1000 ms for the TCP-side timeout. Set it to 100 ms, a very common wired default, and perfectly healthy slaves start returning exception 0x0B (gateway target device failed to respond); the master retries, the queue grows, and the bus appears to collapse under a load it was never carrying.
The opposite error is just as damaging, and it is the one that stops production. Set the timeout to 3 seconds “to be safe”, lose one slave, and the scan goes from roughly 620 ms to 3.6 seconds — because every scan now pays the full timeout for the missing device. Add a retry and it is worse. On a line where an operator is watching a value that drives a manual decision, a four-second blind spot is a process problem.
| Timeout setting | Healthy scan (4 slaves) | One slave offline | What the operator sees |
|---|---|---|---|
| 100 ms (too short) | Timeouts on healthy slaves | Cascade of 0x0B exceptions | Random comms alarms all day |
| 500 ms (minimum) | ~620 ms | ~965 ms | Brief blip on the failed tag |
| 1 000 ms (recommended) | ~1 s | ~1 465 ms | Acceptable for Clock 2 |
| 3 000 ms (too long) | ~3 s | ~3 465 ms + retries | Screen freezes, decisions stall |
Two further practices pay for themselves: give a failed slave its own grace period — drop it from the fast poll list after N consecutive failures and retry it on a slow background cycle, so one dead instrument cannot hold the scan hostage — and measure the real turnaround before sizing anything, working from the captured 95th percentile rather than a datasheet figure. Notice, too, what this implies about industrial router latency: with a 1 s timeout and an 80 ms RTT, the cellular hop is roughly 8% of your worst-case scan. It is not the bottleneck, and tuning it will not fix a bus saturated at 9600 baud.
DI/DO: The Loop That Cannot Wait for the Network
Every second spent optimising latency is wasted if the design has no answer to a simpler question: what happens when the network is gone? Digital inputs and outputs are the answer, and the cheapest resilience in the whole design.
A digital input lets the router see a local contact — a cabinet door switch, a UPS on-battery contact, a level float — and act on it with no round trip to the control centre. A digital output drives a relay, a beacon or an interlock input locally. Most of the range provides 4 DI/DO, the H685t provides 2. That is not meant to replace a PLC; it is meant to carry the handful of signals that must survive a WAN outage.
The pattern we recommend is two independent paths, kept separate: an alarm path that is short, local and degraded-tolerant (DI → SMS, DO → beacon), and a data path that is rich and IP-based (Modbus → tunnel → SCADA). When the carrier drops, the alarm path keeps working; when someone remote-accesses the site, they use the data path and cannot disturb the alarm path.
| Field deployment · 58 sites |
| “The SCADA polling gap during a SIM switch averaged 165 seconds on single-modem units. That was fine, because the alarms never stopped — DI/DO to SMS ran through the whole carrier changeover. If we had put the alarm reporting on the same path as the data, we would have been blind exactly when we needed to see.” |
| Gas pipeline cathodic protection network, Central Asia · two-path design: DI/DO → SMS for alarms, IPsec tunnel → SCADA for data |
The Failover Window: How Long You Are Actually Blind
Dual SIM is often sold as continuity. It is not — it is a bounded interruption. The useful question is how big the bound is, and the answer depends on architecture and on how aggressively you have tuned the health check.
In a single-modem design — the architecture in the H700, H720, H750 and H820Q series — the router monitors the active SIM and, when a trigger fires, tears down the session and re-dials on the standby SIM. Field measurement puts that switch in the range of 15–45 seconds depending on how quickly the new SIM registers and gets an IP lease. Two modems change the picture entirely: with the dual-modem dual-SIM-online option on the H900 series, both SIMs are registered simultaneously, so a WAN failure does not require a re-dial at all.
But the detection policy dominates the total, and that is where deployments are won or lost. In acceptance testing on H750 units at three sites, measured time from path failure to confirmed connectivity on the backup SIM was:
| Health-check policy | Site 1 (strong backup) | Site 2 (moderate) | Site 3 (marginal) | Side effects observed |
|---|---|---|---|---|
| Conservative — 10 s timeout, 30 s interval, 3 retries | 147 s | 163 s | 211 s | No false switches in 72 h |
| Aggressive — 5 s timeout, 10 s interval, 2 retries | 68 s | 92 s | 112 s | 2 false switches in 72 h |
Read the trade-off honestly: the aggressive policy nearly halves the outage and buys you two spurious failovers — and a spurious failover on a marginal site is a self-inflicted outage. For SCADA work the conservative setting was preferred because it was slower. There is also a trap that catches people regardless of setting: configure “switch back to master” too aggressively on a site with intermittent coverage and the router will oscillate between SIMs every minute for as long as the anomaly lasts. Disable switch-back, or set it long.
One detail from that deployment is worth copying: the ICMP check target was the operations centre’s own public IP, not a public DNS resolver. A resolver proves the carrier is connected; your own concentrator proves the path you care about — tunnel included — is reachable. Dual SIM failover in industrial automation should test the path, not the radio.
One more lever: when the public IP changes, the tunnel protocol matters more than the modem. WireGuard recovers in under a second; IKEv2 with MOBIKE updates the address without full renegotiation; plain IKEv1 renegotiates from scratch. With a tight failover budget, that is cheaper than new hardware.
Power, Place and the IP30 Reality
First: the enclosure rating. Every router in this range except the H820QO is IP30 — protected against solid objects larger than 2.5 mm, with no water protection at all. An IP30 router goes inside an enclosure. If the only available location is on the outside of a machine, on a mast, or in a wash-down area, the answer is the IP68 H820QO or a properly rated cabinet — not an IP30 router and a hope.
Second: where in the cabinet. All of these models mount desktop, wall or DIN rail — the form factor most plant cabinets already expect from a DIN rail cellular router. Keep the router away from variable frequency drives, contactors and switching supplies, and cross power cables at right angles. Cabinet ambient matters more than most expect: a sealed steel cabinet in a hot plant adds tens of degrees to the room temperature, and every 10 K roughly halves the life of an electrolytic capacitor. Give the router the coolest rail position available, not the leftover one next to the drive.
Third: power. These are DC devices on industrial supplies, typically 24 V. The H820QO accepts 5–40 V DC as standard, and you need the 5–60 V version if you intend to feed it from 48 V PoE — a detail that catches people who order PoE and a standard-voltage unit on the same purchase order. Fit an inline fuse: 3 A for 9–24 V DC, 2.5 A above 24 V DC. Where the supply has inductive loads, look for ISO 7637-2 transient protection — reverse-polarity and load-dump pulses on a 24 V machine supply are real, and they are not the same thing as lightning protection. Industrial router 24V DC power design is not glamorous, but it is the difference between a five-year install and a two-year one.
- Confirm the enclosure — IP30 means inside a cabinet; only H820QO is rated for exposed mounting.
- Choose the rail position — away from VFDs, contactors and the heat that collects at the cabinet top.
- Fuse the DC feed — 3 A at 9–24 V, 2.5 A above 24 V, on the supply side.
- Match the input range to the PoE plan — order the 5–60 V version if 48 V PoE is in scope.
- Route the antenna outside the metal — a sealed steel cabinet is a Faraday cage.
- Label the serial interface physically — RS-232 or RS-485 is fixed at order time.
VLAN 802.1Q: Keeping IT Traffic Off the OT Clock
Segmentation is usually justified as a security control, and it is one — IEC 62443 is built on zones and conduits for good reason. But on a plant floor there is a more immediate argument: an unsegmented network steals time from the poll cycle you just calculated.
On a flat network a Windows patch download, a camera stream and a laptop’s cloud backup all contend with Modbus on the same broadcast domain and uplink. Your carefully sized 400 ms scan becomes a variable, and variable is worse than slow. With VLAN 802.1Q OT network segmentation — supported across the range — you separate the classes:
- VLAN 10 — OT / SCADA. PLCs, drives, RTUs. Whitelisted peers only, no internet egress.
- VLAN 20 — Monitoring. Cameras, condition-monitoring sensors, environmental probes. Internet allowed, VLAN 10 not.
- VLAN 30 — IT / maintenance. Laptops, guest Wi-Fi, engineering stations. Reaching OT only through a controlled jump host.
Then the router’s role is to be the only device that knows all three exist, carrying the one stream that has to leave the site — typically SCADA data over an IPsec tunnel to head office — with a default-deny inbound policy on everything else. Small configuration, outsized effect on both jitter and risk.
Honest Limits: What a Cellular Router Is Not
A vendor article that does not tell you where the product stops is marketing. Here is where ours stops.
| Requirement | Answer | What to use instead |
|---|---|---|
| PROFINET, EtherNet/IP, OPC UA | Not supported | PLC / DCS communication modules; the router carries the traffic, it does not speak the protocol |
| Motion control, synchronised axes | Not supported | Deterministic fieldbus on the machine network |
| Safety functions (E-stop, interlock) | Not supported | Safety-rated hardware per IEC 62061 / ISO 13849 |
| Modbus RTU / Modbus TCP | Yes — across the range | — |
| DTU / serial-to-cellular gateway | Yes — across the range | — |
| Digital / analogue field I/O | DI/DO only, 4 (2 on H685t) | A PLC or remote I/O module for anything more |
| Exposed or wash-down mounting | H820QO only (IP68) | H820QO, or a rated cabinet for an IP30 model |
The last row deserves emphasis, because it is the one that causes RMAs: every model except the H820QO is IP30. With a hose, a roof edge or a coastal salt atmosphere, that rating decides the question before latency, baud rate and failover policy even come up.
| Also worth knowing before you specify |
| The H685m is a 5G modem, not a router: USB and Ethernet, PoE PD, no serial, no Modbus, no DTU, no digital I/O. It is the right product for giving a device a 5G uplink and the wrong product for connecting a machine to SCADA. |
Verdict: Write the Budget Before You Buy the Box
The pattern across every deployment we have been involved in is consistent: the projects that went smoothly did not have better radios. They had a written number for how late each function was allowed to be, and a design that kept the tight-number functions away from the WAN.
So the recommendation is procedural rather than product-shaped. Sort your requirements into the three clocks before you shortlist an industrial cellular router. Clock 1 stays local, full stop. Clock 2 gets a local LAN path with cellular as a bounded backup and a timeout computed from the bus arithmetic plus the measured round trip — not from a default. Clock 3 goes over the tunnel, on its own VLAN, with a deliberate MTU and a measured failover window.
Do that and you will usually find brownfield automation connectivity over public LTE is not the risky part. The risky part was always the thing nobody wrote down.
| Key takeaways |
| Clock 1 (1–50 ms) never crosses a WAN. Clock 2 can, with engineered timeouts; Clock 3 is what cellular is for. |
| Public LTE adds 40–80 ms idle, 80–200 ms loaded. Invisible to Modbus/TCP polling, very visible to a chatty HMI. |
| Tunnels do not fragment Modbus (~115 bytes on the wire) — but they do fragment firmware, HMI pages and log uploads, so set MTU and MSS deliberately. |
| At 9600 baud a ten-register transaction is ~57 ms and fifteen slaves take ~0.9 s. Raising baud compresses framing, not slave turnaround; batch reads instead. |
| Size timeouts at 1.5–2× the computed scan, plus 2 × RTT and jitter. 100 ms causes phantom exceptions; 3 s freezes the screen. |
| Dual SIM is a bounded interruption — 15–45 s on single-modem hardware, 68–211 s by policy. Size the historian buffer to match, and keep alarms on a separate DI/DO path. |
Frequently Asked Questions
Q1：Can I run a PLC control loop over 4G?
No. A control loop belongs on Clock 1 (1–50 ms) and must close locally, on the machine network. Public LTE adds 40–80 ms idle and 80–200 ms loaded, and none of those are guarantees. Use cellular for supervisory traffic, monitoring, remote service and backups — and nothing whose failure could hurt someone.
Q2：How much latency does LTE really add to a Modbus poll?
Typically 40–80 ms of round trip on a good radio path, 80–200 ms under load. Against a correctly sized 1 s Modbus timeout that is under 10% of the worst-case scan — rarely the bottleneck, since the serial bus at 9600 baud usually is.
Q3：Does an IPsec VPN slow down Modbus traffic?
Not by fragmenting it — a Modbus/TCP read of ten registers is roughly 115 bytes including tunnel overhead, far below any MTU. What encryption costs is per-packet CPU work. It will fragment large transfers (firmware, HMI pages, historian backfills), so set the tunnel MTU and clamp TCP MSS explicitly rather than relying on PMTUD.
Q4：What is the right Modbus timeout over a cellular link?
Start from the bus: scan rate ≥ 1.5–2× the sum of transaction times plus slave processing. At 9600 baud that puts the serial timeout at 500 ms minimum, 1000 ms recommended. Then add two round trips plus a jitter margin for the cellular hop — 800–1000 ms is typical. Never copy a 100 ms wired default onto a cellular link.
Q5：Is 5G worth it for industrial automation?
Only with a throughput requirement or a private network. Public sub-6 GHz 5G improves latency from roughly 40–80 ms to 20–40 ms — real but modest, and invisible to most polling. Sub-10 ms URLLC requires dedicated spectrum and private infrastructure. Moving video, or running a campus private network, changes the answer.
Q6：”Serial Port RS232 or RS485″ — do I get both?
No — the most common ordering mistake we see. It is one physical port, configured at order time as either RS-232 or RS-485. The H700 is the only model with two serial ports; the H820QO and H685m have none at all.
Q7：How quickly does dual SIM failover recover?
On single-modem hardware (H700, H720, H750, H820Q) the switch itself completes in 15–45 s, but the health-check policy dominates: measured end-to-end recovery was 68–112 s with an aggressive policy and 147–211 s with a conservative one — and the aggressive setting bought two spurious failovers in 72 hours on a marginal site. Dual-modem dual-SIM-online (H900 option) removes the re-dial entirely.
Send us your latency budget
Give us the poll list, the baud rate, the slave count and your update-rate requirement. We will return a computed scan time, a timeout recommendation, a failover window and the right model for the enclosure you actually have.
