Telemetry Data Usage Estimator
Engineers planning cellular or satellite telemetry use this to estimate how much data a site will move each month before choosing a data plan. Enter the number of tags, bytes per sample, how often they poll, and a protocol overhead allowance, and it returns an estimated megabytes per month.
Cellular and satellite plans are billed by data volume, so it helps to estimate a site's monthly traffic before committing. This estimator multiplies the tag count, the bytes per sample, and the number of samples in a month, then adds a protocol-overhead allowance. It is deliberately a rough planning figure, not a metered guarantee.
The Estimator
Result (estimate)
This is a rough planning estimate, not a metered figure.
The Formula
Each tag is sampled 86400 / interval times a day, over an average 30.44-day month, at the given bytes per sample, scaled up by the overhead allowance:
The 86400 is seconds per day, 30.44 is the average days per month, and dividing by 1e6 converts bytes to megabytes.
Worked example. 50 tags at 16 bytes, polled every 60 s, with 30% overhead: samples per day per tag = 86400 / 60 = 1440. Raw = 50 × 16 × 1440 × 30.44 / 1e6 = 35.07 MB. With overhead: 35.07 × 1.30 = 45.6 MB/month, and 1440 × 30.44 = 43,834 samples per tag per month.
Assumptions and Limits
- This is labeled an estimate on purpose. Real cellular usage depends on the protocol, whether the link reports by exception or polls on a fixed cycle, keep-alive traffic, retries, and TLS or VPN overhead, none of which are modeled exactly.
- The default 16 bytes per sample and 30% overhead are generic placeholders. Report-by-exception protocols send far less when values are stable; chatty protocols send more. Replace the defaults with measured figures once you have them.
- The average 30.44-day month smooths over month-length differences; a specific month may differ by a few percent.
- Results are engineering estimates for plan sizing. Validate against a metered trial or your carrier's usage reports before committing to a data plan.
FAQ
Why is this only an estimate?
Actual data depends on protocol framing, how often values actually change, keep-alive and reconnect traffic, retries over a weak signal, and any encryption overhead. Those vary too much to model precisely, so the figure is meant for planning, not billing.
How do I lower the number?
Poll less often, report by exception so only changed values are sent, group tags into fewer larger messages to cut per-message overhead, and compress where the device supports it. Each of those reduces one of the multipliers in the formula.
What overhead percent should I use?
The 30% default is a generic allowance for headers, handshakes, and occasional retries. A clean, well-batched TCP link may run lower; a chatty or lossy link higher. Measure a representative site and use that figure if you can.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.