A lift station with two pumps, a level transmitter and a flow meter carries roughly 116 tags — and most utilities pay every month to carry those tags whether or not a single value changed. This guide does the byte-level arithmetic on polling, publishing, batching and dead-bands, then shows what a well-chosen SCADA industrial cellular router can and cannot do about the bill.
Written by E-Lins Engineering Team
Every water utility has the same conversation eventually. The bill goes up, somebody opens the carrier portal, and one site — or ten — is chewing through twenty times the data anybody expected. The reflex is to blame the modem, the APN or the tariff. It is almost never those. It is nearly always the polling rate someone inherited from a radio system in 1998, multiplied by a protocol that re-transmits every value whether or not it moved.
So this is a guide about arithmetic, not about buying bigger plans. The same numbers that set your monthly bill decide whether your SCADA screen fills with “stale data” banners on a wet Monday when half the towers are congested. Small packets survive congestion. Big poll responses do not.
We build industrial routers, so we have a commercial interest here. We also have a duty to be straight: moving from Modbus polling to MQTT publishing does not automatically save money — sometimes polling at a sane interval is cheaper than publishing badly. Knowing which case you are in is the point of what follows.
Where the 116 Tags Come From
Before any byte arithmetic means anything you need a tag inventory — and you need it broken down by how fast each value actually moves, which is not how your SCADA licence counts it. The industry shorthand for a small wastewater lift station runs like this:
| Element | Class | Tags | Example points |
|---|---|---|---|
| Duty pump × 2 (VFD) | Complex | 80 | Current, volts, speed ref, winding temp, starts, fault codes |
| Wet well level transmitter | Analog | 8 | Raw mA, scaled level, high/low alarm, signal fault |
| Discharge flow meter | Analog | 8 | Instantaneous flow, forward totaliser, signal fault |
| Station common | Mixed | 20 | Mains, generator, intrusion, hatch, comms health, UPS hold-up |
| Total (add 25% licence contingency → ≈ 145) | ≈ 116 | Only about five of these move fast enough to justify sub-second sampling | |
Memorise the number, then forget it — what drives your bill is the split. Discrete status (pump running, mains healthy) changes perhaps twenty times an hour, yet a polled register read carries thousands of identical bytes to say so. Slow analogs such as wet well level move centimetres per minute, and a 1% dead-band turns them into events. Only fast analogs — discharge flow during a pump start — benefit from sub-second sampling, and they are a small minority. Compliance totalisers are rare and legally non-negotiable.
A typical lift station lands near 70/20/5/5 across those four. Hold onto that ratio: in section 04 we convert exactly those percentages into megabytes per month. Utilities that skip this step end up paying fast-analog rates to move slow-analog data, which is the most expensive habit in water wastewater telemetry.
The Byte Accountant: What One Poll Cycle Costs
Take the classic case — a Modbus TCP master reading 100 holding registers from one RTU with function code 0x03 — and count everything that leaves the site and everything that comes back.
| Layer | Request | Response | Note |
|---|---|---|---|
| IPv4 + TCP headers | 40 | 40 | No options |
| MBAP header | 7 | 7 | Transaction ID, protocol ID, length, unit ID |
| Function code / byte count | 1 | 2 | 0x03 both ways |
| Address + quantity | 4 | — | Request only |
| Register payload | — | 200 | 2 bytes × 100 registers |
| Per direction | 52 B | 249 B | Payload 200 B, overhead 101 B |
| Per poll cycle | 301 B | Add ~54 B Ethernet framing and ACKs → ~360 B metered at layer 2 | |
Note the ratio: you pay roughly 50% overhead to carry that payload, and almost all of it is fixed per cycle rather than per byte. That is the lever the rest of this guide pulls on.
| Poll interval | Bytes/s | MB/day | MB/month | Where it usually comes from |
|---|---|---|---|---|
| 1 s | 301 | 26.0 | 780 MB | Inherited from old radio practice; almost never justified |
| 5 s | 60.2 | 5.2 | 156 MB | Default in many SCADA templates |
| 15 s | 20.1 | 1.73 | 52 MB | The sensible floor for status telemetry |
| 30 s | 10.0 | 0.87 | 26 MB | Good default for slow analogs |
| 60 s | 5.0 | 0.43 | 13 MB | Often still faster than the process needs |
Look at the spread. Sixty times less frequent means sixty times less volume — 780 MB down to 13 MB per site per month. No protocol change, no new hardware, just a number in the poll table.
| The interval is the first lever, and it is free |
| Everybody reaches for protocol migration first because it is interesting. But going from 1 s to 15 s saves 728 MB per site per month with no migration at all. We will calculate what moving to MQTT saves in section 04, and the honest answer is frequently less than that. Fix the interval before you redesign anything. |
Publishing: What the “30 Bytes” Claim Really Means
The comparison everyone quotes goes like this: a polled Modbus transaction moves about 248 bytes whether or not anything changed, whereas an MQTT publish carrying a Sparkplug B payload is “30 bytes” — so publishing is eight times cheaper. It is a tidy story with one serious flaw. Thirty bytes is the payload, not the packet.
| Component | Bytes | Comment |
|---|---|---|
| IPv4 + TCP headers | 40 | Same cost as any TCP session |
| MQTT fixed header + remaining length | 3 | Small, but not zero |
| Topic string | ~42 | Usually the largest single element — e.g. spBv1.0/LiftStn07/DDATA/PMP1/Current |
| Sparkplug message level (timestamp, sequence) | ~15 | Paid even for a single metric |
| One metric (name, datatype, value) | ~20 | The part everybody quotes |
| Total per unbatched publish | ≈ 120 B | Four times the headline figure |
Now the good news, and it is genuinely good: Sparkplug allows many metrics in one publish, and the topic plus message-level overhead is paid once per message rather than once per metric. Batching is where the real saving lives.
| Metrics per publish | Bytes on the wire | Bytes per metric | vs unbatched |
|---|---|---|---|
| 1 | 120 | 120 | — |
| 5 | 200 | 40 | 3.0× better |
| 10 | 300 | 30 | 4.0× better |
| 25 | 600 | 24 | 5.0× better |
| Batching beats protocol choice |
| A Modbus poll of 100 registers amortises its 101 bytes of overhead across 100 values — about 3.0 bytes per value transported. An unbatched Sparkplug publish pays 120 bytes for a single value, forty times worse. Batch ten metrics into one message and you are back to 30. Your Sparkplug topic naming convention is a bandwidth decision, not documentation. |
One more layer that most comparisons omit entirely, and in industrial deployments it is not optional: encryption. An IPsec ESP tunnel with AES-128-GCM adds roughly 50–58 bytes per packet; AES-256-CBC with SHA-2 authentication adds 62–74 bytes; WireGuard adds about 60 bytes on IPv4. That overhead is per packet, so it punishes small messages disproportionately.
| Design | Payload | With IPsec ESP | Uplift |
|---|---|---|---|
| Unbatched single-metric publish | 120 B | 178 B | +48% |
| Batched 10-metric publish | 300 B | 358 B | +19% |
| Batched 25-metric publish | 600 B | 658 B | +10% |
| Modbus poll cycle, 100 registers | 301 B | ~360–420 B | +20–40% |
Read the first row again: encrypting a small unbatched publish gives back half its size. MQTT straight over a public APN with per-message TLS, no batching and no tunnel is the most expensive combination available — a configuration error, not a protocol flaw.
Our recommendation for Sparkplug B cellular telemetry in water is consistent across nearly every estate we see: keep the broker behind one always-on tunnel, batch aggressively, and let the router own the crypto. Every industrial model in our range terminates IPsec with NAT-T, GRE, L2TP and OpenVPN options, so one tunnel carries everything with a predictable overhead instead of per-message handshakes.
The Break-Even Nobody Calculates
Here is the question that should decide your architecture, phrased so it can actually be answered: at what change rate does publishing cost exactly the same as polling? Polling 100 registers at interval T costs 301 ÷ T bytes per second; publishing costs about 120 bytes per changed value, ignoring batching so the comparison stays conservative.
| Break-even change rate |
| Change rate (values/s) = 301 ÷ (120 × T), where T is the poll interval in seconds. Change slower than this and publishing wins; faster, and polling was already cheaper. |
| Poll interval | Polling cost | Break-even change rate | As % of 100 tracked values |
|---|---|---|---|
| 1 s | 301 B/s | 2.5 changes/s | 2.5% per second |
| 5 s | 60.2 B/s | 0.50 changes/s | One value every 2 s |
| 15 s | 20.1 B/s | 0.17 changes/s | One value every 6 s |
| 60 s | 5.0 B/s | 0.042 changes/s | One value every 24 s |
This table holds the most counter-intuitive result in the guide: the slower you already poll, the less publishing saves you. At 1 second, publishing wins unless more than 2.5% of your values change every second — nearly every water process qualifies. At 60 seconds, one value changing every 24 seconds is enough to make polling the cheaper option.
| The protocol does not create the saving — your process does |
| Publishing lets you collect a saving your process was already offering; it does not manufacture one. Bolt MQTT onto a 60-second schedule with a tight dead-band and you move the same bytes as before, plus overhead. Not a reason to avoid publishing — report by exception telemetry for alarms, a decoupled broker and clean handling of link loss are real benefits. Just a reason to be honest about why. |
What does a real lift station change like?
Our 116-tag station in steady dry-weather operation, with a 1% dead-band on the level transmitter and 2% on flow:
| Value group | Changes/hour | Changes/s | Bytes/s |
|---|---|---|---|
| Pump run/fault status (~8 starts/h) | ~32 | 0.0089 | 1.07 |
| Level and flow crossing dead-band | ~40 | 0.0111 | 1.33 |
| VFD current / frequency during starts | ~24 | 0.0067 | 0.80 |
| Totalisers and housekeeping | ~6 | 0.0017 | 0.20 |
| Steady-state total | ~102 | 0.028 | 3.4 → ≈ 8.7 MB/month |
| Wet-weather storm scenario (10× activity) | ~1,020 | 0.28 | 34 → ≈ 87 MB/month |
So a tuned publish design lands between 9 MB and 90 MB per site per month, against 52 MB for 15-second polling. Publishing at 100 tags does win — typically 2–6× rather than the 10× the payload-only comparison implies. And during a storm, exactly when you most want the data, it briefly loses.
| 301 B |
| One Modbus poll cycle, 100 registers, layer 3/4 |
| 120 B |
| One unbatched MQTT publish on the wire |
| 3.0 B |
| Effective cost per value in a polled batch |
| 780 → 13 MB |
| Same site at 1 s vs 60 s polling, per month |
Choosing the Interval from the Pump Cycle, Not from Habit
How slow can you go? Water differs from most industries we serve in a helpful way: the processes are slow, the consequences of missing a slow trend are also slow, and there is usually a deadline written into your permit. Those three facts set a ceiling and a floor.
| Phenomenon | Timescale | What it implies for polling |
|---|---|---|
| Wet well fill between stop and start floats | 2–10 min | 60 s polling still gives 2–10 samples per cycle |
| Duty pump cycle (motor starts limited to 6–10/h) | 6–10 min | Status polling faster than 15 s measures nothing new |
| Chlorine residual, turbidity, pH | 30 s – 5 min | A 1–2% dead-band beats fast polling every time |
| Pump start transient / VFD ramp | 2–20 s | The one place fast sampling earns its keep — capture it locally |
| Pressure transient / surge | 0.1–2 s | Not carryable over cellular — a local 100 Hz logger’s job |
| Permit compliance integration | 15 min (typical — check yours) | Hard floor — the one interval you cannot stretch |
| Worked example: how fast does a wet well actually fill? |
| A 2.5 m diameter well has about 4.9 m² of plan area. With a 0.6 m working band between stop and start floats that is roughly 2,950 litres — so at a peak inflow of 20 L/s the well fills in about 148 seconds, and at dry-weather flow of 5 L/s nearly ten minutes. Polling once a second gives 150 samples of a variable that moved 6 mm between most of them; every 30 seconds still gives five usable points per cycle. |
And the honest limit: surge and water hammer are not cellular problems. A 0.1–2 second transient crossing a link with 40–200 ms latency and heavy jitter cannot be reconstructed at the master however fast you poll. Log locally at 100 Hz and move only the summary.
A default configuration we recommend
- Compliance totalisers — publish on a 15-minute boundary, always.
- Slow analogs — 1–2% dead-band, plus a 60 s maximum between publishes so you can prove the link is alive.
- Discrete status — publish on change immediately, with a heartbeat summary every five minutes.
- Fast analogs — sample at 1 s locally in the RTU, publish only min/max/average for the interval.
- Alarms — immediate, never batched, mirrored to SMS so they survive failure of the data channel.
Row two matters most. A maximum time between publishes is not politeness, it is your dead-man timer. Without it, a healthy link carrying no changes looks identical to a dead site.
What Cellular Can and Cannot Do About Latency
Bandwidth and latency pull in opposite directions in water SCADA. You can solve a bandwidth problem by waiting; you cannot solve a latency problem by waiting. The budget:
| Segment | Typical | Loaded / poor RF |
|---|---|---|
| LTE radio round trip | 40–80 ms | 150–300 ms |
| End-to-end RTT including core | 80–200 ms | 300–500 ms |
| Jitter | 10–50 ms | 50–150 ms |
| Tunnel encrypt / decrypt at each end | 1–3 ms | ~5 ms |
| Modbus TCP server response (PLC scan) | 5–30 ms | 100 ms+ |
| Command → acknowledgement | ≈ 100–300 ms — fine for supervisory control | |
| Legacy serial radio equivalent | 30–180 s — why old timeout habits are so expensive | |
Three conclusions, and they belong in your design documents rather than in somebody’s head. Supervisory control is fine — start/stop commands and setpoint changes at 100–300 ms round trip are far faster than any human notices. Closed-loop control is not — anything needing sub-100 ms determinism, such as PID on a dosing pump or pressure control valves, belongs in the local PLC. And your timeouts are a design parameter: a master using a 500 ms timeout with one retry will generate thousands of spurious comms failures on a congested evening, each of which somebody has to clear.
| Do not confuse “fast cellular” with “deterministic” |
| 5G URLLC figures below 10 ms exist, but they come from private networks with dedicated spectrum and edge cores — not from a public commercial APN. If your tender document promises 10 ms over public cellular, that sentence needs fixing before it is signed. |
The Historian Bill Nobody Models
The carrier bill is visible and gets argued about. The historian is invisible until the SAN is full, by which point the argument is different and more expensive. Both follow from the same decision — how often you log — so settle them in the same meeting. Assuming a conservative 12 bytes per uncompressed sample:
Storage = tags × (86,400 ÷ log interval) × 365 × 12 bytes ÷ compression ratio
| Log rate | Raw per site-year (116 tags) | At 4× compression | × 200 sites, compressed |
|---|---|---|---|
| 1 s | 43.9 GB | 11.0 GB | 2.2 TB |
| 15 s | 2.93 GB | 0.73 GB | 146 GB |
| 60 s | 0.73 GB | 0.18 GB | 37 GB |
Compression does enormous work here — 10–50× for still processes like reservoir level, but only 2–4× for turbulent ones like discharge flow during a pump cycle. Plan on 4×. Then note the shape of the result: going from 1-second to 15-second logging saves roughly 15× on both the carrier bill and the historian. Nobody argues about the historian until year three; everybody argues about the SIM cost in month one. Fix both with one decision.
Where the Old Analysers Live: RS-485, DTU and the One-Port Fact
Water has a longer asset memory than almost any industry we serve. A treatment works may still be running turbidity analysers, chlorine residual monitors and magnetic flow meters bought when the plant was commissioned — all speaking Modbus RTU over a two-wire loop, none keen to be replaced. The question is where the conversion happens.
Modbus RTU carries 11 bits per character, so at 9,600 baud each byte takes about 1.146 ms. Add the mandatory inter-frame silence — t3.5, which is 4.01 ms at 9,600 baud and fixed at 1.75 ms above 19,200 — and a ten-register read works out as follows:
| Baud rate | Transaction (10 registers) | Practical impact |
|---|---|---|
| 9,600 | ≈ 57 ms | A 15-slave loop takes ≈ 0.9 s per sweep |
| 19,200 | ≈ 37 ms | Good default where cable length allows |
| 38,400 | ≈ 27 ms | Needs decent cable and termination |
| 115,200 | ≈ 23 ms | Overhead-dominated — little further gain |
Above about 38,400 baud the fixed silence and the slave’s own processing dominate, so pushing faster buys very little on an RTU loop. Add a second segment rather than raising the baud rate.
That is what the serial to cellular gateway (DTU) feature does: the router terminates the RS-485 loop locally, converts Modbus RTU to Modbus TCP or MQTT, and puts the result into the tunnel. Local latency stays in milliseconds instead of crossing a jittery link, the master sees one IP endpoint rather than a dozen unroutable slaves, and the site can fail over between bearers without the master losing its address.
| Read this datasheet line twice: “RS232 or RS485″ |
Every model lists Serial Port RS232 or RS485, meaning one physical port, configured when you order it, as either RS-232 or RS-485. Not both, and not switchable in the field. If a site needs two segments — an RS-485 instrument loop plus an RS-232 analyser port — exactly one model does it: the H700, with two serial ports (one DB9, one terminal socket). |
The same discipline applies to digital I/O. Most models give four DI/DO channels, but the H685t ships with two, and on the H700 and H750 the inputs are 0–3.3 V logic level — fine for a contact closure beside the router, useless for reading a 24 V pump-run signal off a motor control centre. For that you need the optional E-Lins switch control board (5–40 VDC). Order it with the router; retrofitting is a truck roll.
What Our Range Actually Gives You at a Water Site
Everything below comes from the current datasheets. Where a specification carries a qualification we have kept it rather than smoothing it away, because that is exactly the kind of detail that becomes a change order.
| Model | Serial | DI/DO | Ethernet | SIM | Fit for water |
|---|---|---|---|---|---|
| H700 | 2 × RS232/RS485 (DB9 + terminal) | 4 (0–3.3 V) | 5 × 10/100/1000 | Dual | The only dual-serial unit — use where you need an instrument loop and an analyser port |
| H900 | 1 × RS232 or RS485 | 4 | 5 × 10/100/1000 | Dual | General-purpose workhorse; dual-modem dual-SIM-online option removes re-dial entirely |
| H750 | 1 × RS232 or RS485 | 4 (0–3.3 V) | 3 × 10/100 | Dual | Compact kiosk and mobile-maintenance installs |
| H720 | 1 × RS232 or RS485 | 4 | 5 × LAN/WAN | Dual | Mid-range site router with Modbus and DTU |
| H820 | 1 × RS232 or RS485 (DB9) | — | 5 × LAN/WAN | Dual | Where you also need PoE PSE for a camera or small switch |
| H820QO | None listed | — | 2 × LAN/WAN | Single (dual opt.) | The only IP68 unit — see the warning below |
| H685f /H685frc | 1 × RS232 or RS485 | 4 | GbE | Single | Compact; H685f is 5G, H685frc is 5G RedCap |
Everything above shares one environmental envelope: −35 °C to +75 °C ambient operating, −40 °C to +85 °C storage, 5–95% relative humidity non-condensing, in an IP30 metal case with anti-lightning protection. The H820QO is the exception on ingress, at IP68. Take the humidity line seriously — section 11 shows why it bites in wet wells.
Keeping the Tunnel Alive: Failover, Switchover and Stale Data
This is the part most polling-versus-publishing comparisons skip, and where we think the real insight sits. A link outage is not the same thing as a data gap — unless your architecture makes it one.
With classic polled telemetry it does: while the link is down nothing is collected, nothing is buffered at the master, and when it returns the record has a hole in it. If the report you file integrates flow across that period, you have a compliance problem caused by a network event.
The industry answer is store-and-forward, and here we want to be clear about responsibilities. The router does not store-and-forward your process data — that is the RTU’s job. A correctly specified RTU or PLC timestamps values at source and holds them until the master collects them. The router’s job is narrower and just as important: make the outage shorter than the RTU’s buffer can cover.
| Reframe the failover specification |
| Stop asking “how fast can you fail over?” and ask instead: “how deep is my RTU’s buffer, and can you get me back inside it?” If the RTU holds 24 hours of timestamped data and your worst recovery is 40 minutes, dual SIM is a nice-to-have. If it holds ninety minutes and your worst measured recovery is two hours during a storm, no link redundancy saves your report — you need a bigger buffer. |
Measured switchover behaviour matters, because it is slower than most people expect. On our single-modem dual-SIM units (H700, H720, H750 and H820Q families) a SIM switch needs network re-registration and typically lands at 15–45 seconds. Across three sites instrumented with the H750:
| Configuration | Site A | Site B | Site C | False switches in 72 h |
|---|---|---|---|---|
| Conservative (10 s timeout, 30 s interval, 3 retries) | 147 s | 163 s | 211 s | 0 |
| Aggressive (5 s timeout, 10 s interval, 2 retries) | 68 s | 92 s | 112 s | 2 |
The pattern matches everything else here: speed costs reliability. Halving failover time roughly doubled detections that turned out not to be real outages. We recommend the conservative profile — 211 seconds sits comfortably inside any reasonable RTU buffer, whereas a spurious switch during a storm teaches people to ignore alarms.
Dual SIM failover for water SCADA can also be done differently. On the H900 there is an option worth knowing: dual modem with two SIM cards online simultaneously. Because both links are already registered, failover needs no re-dial at all. Where your buffer is shallow and your storms long, that is the honest answer rather than tuning timeouts.
Set your stale-data timeout to match
Your SCADA marks a tag stale after some number of missed polls, and if that threshold is shorter than your worst-case failover time, every carrier hiccup produces a burst of comms alarms — followed by the same tags recovering, which nobody logs. That habit is how genuine outages eventually get missed. The rule: stale timeout ≥ worst measured failover time × 3, which for a conservative dual-SIM profile means something north of ten minutes.
The Data Budget: Pooling, Alerts and the One Bug That Eats the Plan
The expensive outcome is rarely a high bill. It is a high bill nobody saw coming because nothing alerted until the invoice arrived — which is why Modbus RTU to cellular gateway projects should specify their data budget before their modem.
The old model was one SIM, one plan, per site. Utilities with a few hundred sites still default to it and pay for idle capacity — buy 300 allowances and most are barely used. A pooled plan lets the estate share one allowance, cheaper precisely because peaks are uncorrelated: a storm hits some catchments, not all. The catch is that pooling turns a per-site problem into an estate-wide one, because one firmware regression reverting a site to 1-second polling drains the shared allowance in days.
| Turn on per-client alerts before you turn on hundreds of sites |
| Every industrial router in our range supports industrial router data usage alerts for the router and each connected client. Set a per-site warning at roughly 3× expected monthly volume and a fleet-level alarm on total consumption: enough headroom to avoid nuisance alerts, tight enough to catch a runaway process within days. |
| Design | MB/site/month | 200 sites, GB/month | Comment |
|---|---|---|---|
| Inherited 1 s polling | 780 | 152 | The scenario behind the angry phone call |
| 5 s polling, no tuning | 156 | 31 | SCADA template default |
| 15 s polling | 52 | 10 | Good outcome from fixing the interval alone |
| 60 s polling, reservoir and tank monitoring | 13 | 2.6 | Often sufficient for slow assets |
| Publishing, tuned dead-bands, batched | 9–90 | 2–18 | Weather-dependent; storms set the upper bound |
| Field pattern · recurring across estates we support |
| “The template said five seconds because fifteen years ago somebody was paying for radio airtime by the poll. Nobody had looked at it since. We changed one number and the estate dropped by two thirds — before we touched a single protocol.” |
| A composite of deployment reviews rather than one named utility, and flagged as such — but the shape is remarkably consistent. The largest single saving in water telemetry is almost always a default nobody revisited. |
Something the data budget does not capture but which lands in your maintenance budget: every router in the range is rated 5–95% relative humidity, non-condensing, and a wet well is the one place on a water network where that is routinely violated. Condensation is a temperature-cycling problem, not an ingress problem — a sealed enclosure breathing cold night air condenses on the coldest surface inside it, and no IP rating saves you; use a desiccant breather or a small panel heater in below-grade vaults. Hydrogen sulphide is a copper problem — H₂S penetrates ordinary gaskets and attacks PCB tracks, with the classic “ghost fault” signature. And everything except the H820QO is IP30, meaning it belongs inside a NEMA 4X enclosure rather than beside the wet well. All units accept 5–40 V DC with dual power inputs and failover; use the second feed.
One more: attempts to reduce SCADA cellular data usage sometimes try to solve a bandwidth bill by throttling the link. Wrong lever. Throttling a link carrying alarm traffic makes alarms late, and late is worse than absent. Reduce bytes at the source; never ration them on the wire — whether you run a hundred lift stations, a fleet of LTE router for AMR metering endpoints, or any remote pump station monitoring scheme.
The Verdict, and What We Will Not Claim
Let us collapse the arithmetic into something you can take into a design review:
- Fix the interval first. Moving from 1-second to 15-second polling saves 728 MB per site per month and costs nothing. Much of the saving people attribute to MQTT is really this.
- Classify every tag before migrating anything. Only fast analogs benefit from sub-second sampling — and they should be sampled locally anyway.
- Publishing is worth doing, for reasons beyond bandwidth. Just do not promise the board a 10× cut in the carrier bill.
- Batch your publishes. Ten metrics per message moves per-metric cost from 120 bytes to 30, and dilutes your VPN overhead too.
- Put conversion at the site and buffering in the RTU. The SCADA industrial cellular router transports bytes; it does not remember them.
- Size the RTU buffer against measured failover time. 147–211 seconds on a conservative dual-SIM profile is a real number.
- Turn on per-client usage alerts before you commission three hundred sites. The cheapest failure to fix is the one caught in week one.
Four things our routers genuinely cannot do for you
| Limitation | What it means for a water design |
|---|---|
| No store-and-forward in the router | Do not treat it as a historian or a data diode. Timestamp at the RTU and buffer there. The router shortens the outage; it does not survive it. |
| One serial port, RS-232 or RS-485 | Chosen at order time, not field-switchable. The H700 alone carries two. Say what you need on the order — and the same applies if you want Modbus RTU over LTE to a legacy analyser. |
| DI inputs are 0–3.3 V logic level | 24 V pump signals need the optional E-Lins switch control board (5–40 VDC). Order it with the router, not after the truck roll. |
| 5–95% RH non-condensing; IP30 except the H820QO | Wet wells and washdown areas need a properly specified enclosure, or the IP68 outdoor unit where external mounting is genuinely required. |
Get those four right, fix the interval, and the rest becomes tuning rather than architecture. Get them wrong and no protocol cleverness will save you — you will simply move the wrong bytes faster. Either way, choose your water utility cellular router on the ports and power you actually have on site, not on the modem headline.
Frequently Asked Questions
Q1:Is MQTT with Sparkplug B always cheaper than Modbus polling at a lift station?
No. Publishing beats polling only below the break-even change rate: one changed value every 24 seconds against 60-second polling, or every two seconds against 5-second polling. Most lift stations clear that comfortably and save 2–6× — not the 10× implied by comparing payload sizes. Measure your change rate first.
Q2:What polling interval should we start with when migrating from radio telemetry?
Start at 15 seconds for status and slow analogs, and 15 minutes for compliance totalisers, then relax both once a season of trend data shows nothing was missed. The trap is inheriting the radio figure — often 1 second, costing 780 MB per site per month against 52 MB at 15 seconds. Set a 60-second maximum between publishes.
Q3:Can we run Modbus RTU over RS-485 straight through to the master?
Technically yes via the DTU feature, but convert at the site instead. An RTU transaction takes about 57 ms at 9,600 baud; doing that across a link with 40–200 ms latency and heavy jitter multiplies every retry. Terminate RS-485 locally in the router, convert inside the panel and publish MQTT up one encrypted tunnel.
Q4:Does the router buffer our data while the link is down?
It does not, and should not be asked to. Store-and-forward belongs in the RTU or PLC, which timestamps values at source and holds them until the master collects the gap. The router keeps the link up, fails over cleanly and returns before the buffer overflows — nothing more. Size that buffer against measured recovery, not marketing figures.
Q5:RS-232 or RS-485 — can we have both on one router?
On almost every model, no. The line reads “Serial Port RS232 or RS485”: one physical port, configured when you order it, as either RS-232 or RS-485. The exception is the H700, which ships with two — one DB9 and one terminal socket. Decide before ordering; it is not field-changeable.
Q6:How do we stop one misconfigured site from consuming a pooled data plan?
Turn on per-client data usage alerts before commissioning, with the per-site warning at roughly three times expected monthly consumption. Every router in our range reports modem usage per connected client and our NMS centralises it. Without per-site visibility, one reverted poll table can drain a shared allowance in days.
Q7:Can cellular carry pressure transient and surge data for our DMA?
No, and no bandwidth fixes it. A surge lasts 0.1–2 seconds, while cellular round trip runs 40–200 ms typical and several hundred milliseconds loaded, with matching jitter. Put a local 100 Hz logger on the transient and move only the summary — peak pressure, duration, timestamp.
| One sentence to take away |
| Water telemetry is not expensive because water data is big. It is expensive because most estates still pay to carry values that have not moved, at an interval chosen when the alternative was a radio licence. Count your tags, classify them by how fast they really change, set the interval from the pump cycle rather than from habit — and only then worry about which protocol moves the remainder. Fix the interval first: it is free, it takes an afternoon, and in our experience it is worth more than everything else here combined. |
Send us your telemetry numbers
Tell us your site count, tag inventory, current polling interval and monthly consumption, and we will return a byte-level model, a failover profile matched to your RTU buffer, and a router configuration built around the serial ports you actually need.
