What Is Satellite Telemetry?

Back to Blog

How Satellite Telemetry Works

At the site, a satellite terminal - a small dish or a flat-panel antenna - modulates the RTU or flow computer's data onto an uplink to a satellite. The satellite relays the signal down to a ground station (a teleport), which routes it onto the internet and to the SCADA host. Return traffic follows the reverse path. The whole link behaves like an IP connection, so the same Modbus, DNP3, or MQTT data that would ride cellular can ride satellite instead.

The defining constraint is orbit. Geostationary (GEO) satellites sit about 35,786 km up, so a round trip imposes roughly half a second of latency no matter how fast the link. Low-Earth-orbit (LEO) constellations fly a few hundred kilometers up, cutting latency to tens of milliseconds and improving throughput, at the cost of needing many satellites and a terminal that tracks them.

Where Satellite Telemetry Fits

Satellite is the backhaul of last resort - and for genuinely remote wells, offshore platforms, and pipeline segments with no cellular, it is often the only option. Because GEO latency is high and data is metered, engineers design these sites to be frugal: report by exception, poll infrequently, and keep payloads small. Store-and-forward at the RTU means nothing is lost when the link is briefly unavailable.

The rise of LEO services has changed the economics, making higher-bandwidth, lower-latency satellite practical at more sites and even usable as a failover behind cellular. Whichever satellite path a site uses, a cloud SCADA like Merobix simply reads the device at the far end once the IP link is up, treating the satellite hop as transport.

Engineering the Data Diet for a Metered Link

On cellular you can be a little sloppy with polling; on satellite the bill and the latency punish it. The design goal is to send only what changed and only when it matters. Configure report by exception with deadbands wide enough to suppress noise but tight enough to catch real moves, batch multiple points into one message rather than one message per tag, and stretch background poll intervals to the slowest rate operations can accept. Protocol behavior matters too: chatty request-response polling pays the round-trip latency on every exchange, while publish-style reporting rides the link only when there is something to say.

Timestamp at the source. When the RTU buffers data through an outage and forwards it later, records must carry the time they were measured, not the time they arrived at the host. Historian trends and alarm sequences only make sense if the field device stamps its own data, so verify source timestamping end to end during commissioning rather than discovering after the first outage that a day of buffered data landed on one apparent minute. The same check protects alarm shelving and sequence-of-events review, both of which quietly assume the timestamps are honest.

Installation Realities at the Site

A GEO dish must see the geostationary arc, which sits toward the equator from the site, so tree lines, tanks, and terrain in that direction matter; a LEO flat panel instead wants the widest possible view of open sky. Either way the mount must be rigid, because pointing error that would be trivial for a television dish can take a narrow-beam data terminal off the air, and the link margins the service provider engineered assume a clean, correctly pointed installation. Rain and snow degrade any satellite link, which is another reason not to give away margin to a flexing mast.

A pre-commissioning walkdown catches most problems while they are still cheap to fix:

1. Verify the look angle or sky view is clear of obstructions, including ones that grow or will be built.
2. Check mount rigidity, cable strain relief, and weatherproofing on every outdoor connector.
3. Confirm the terminal's power budget against the site's supply, especially on solar sites, using the manufacturer's figures.
4. Bond and ground the mast and terminal per the site's lightning-protection practice.
5. Run the provider's link-quality check and record the baseline for later comparison.

Failover Designs: Satellite Behind Cellular

Where a site has marginal cellular, the strongest design is often both: cellular as primary, satellite as backup, with a router that fails over automatically. The details that separate a working failover from a theoretical one are covered in dual-path telemetry redundancy, but the short version is: exercise the failover on a schedule, alarm on which path is active so a silent failover does not run up the satellite meter for weeks, and make sure the SCADA host accepts the site's traffic from either path.

Choosing between orbits for the backup follows the same logic as choosing a primary. The trade-offs are laid out in LEO vs GEO satellite telemetry: GEO brings long service maturity and wide, predictable coverage with high latency, while LEO brings low latency and higher throughput with a newer service model and a different terminal. For slow monitoring duty a GEO backup is perfectly serviceable; if the backup must carry the same interactive load as the primary, a LEO link behaves far more like the cellular path it replaces.

Frequently Asked Questions