The Truth About “Everywhere IoT” for Water Monitoring

Whether you’re working in oceanographic science, hydrology, utilities, aquaculture or offshore renewables, you’ve probably heard some of the noise around “NTN” – using cellular IoT standards like NB-IoT and LTE Cat-1 to send data over satellite. It’s very promising: one chipset roaming between cellular and satellite networks, lowering hardware costs, broadening coverage and simplifying integration.

As is so often the case, the reality is a little more nuanced. In this blog post, we aim to separate myth from reality, and help teams capturing data from remote water sensors design robust data paths that will stand the test of time. We’ll start with one of the most pervasive myths.

The sweet spot for satellite IoT is services in the L-band radio frequency, as these need very little power and are largely unaffected by poor weather. They’re suited to much smaller data volumes, and fit an IoT use case perfectly, for example, regular level and water quality readings from a buoy, float, or river gauge.

So, who offers L-band services? The pre-eminent Satellite Network Operators (SNOs) are Iridium, Viasat (Inmarsat) and Globalstar. Of these three, Iridium is the only one that is truly global. Viasat has great coverage but doesn’t cover the poles, and Globalstar has some big gaps over Asia, the polar regions and the oceans.

Now we have to go one level deeper (sorry!). Of these three, currently Viasat is the only network that offers both proprietary and standards-based services.

• “Proprietary” means that you have a Viasat chipset that works with Viasat satellites; you can’t use it to communicate with Iridium satellites, or vice versa.
• “Standards-based” refers to the use of cellular standards over satellite, namely NB-IoT and LTE Cat-1. As these are all built to the same standard, it should – when the services mature – be possible to switch supplier without needing to change your hardware.

Viasat’s proprietary services (IoT Nano, IoT Pro) are well established and available everywhere where Viasat’s satellites can see the Earth. Their standards-based service, NB-NTN, is in its infancy, and they’re turning on coverage where there’s sufficient demand. Currently that’s North America, parts of Europe, Brazil, Australia and New Zealand. Huge swathes of the ocean are not covered, and if your application is in South America (excluding Brazil), Africa or much of Asia, you’re also out of luck.

In short, check coverage carefully, particularly for maritime devices like offshore buoys, USVs or drifting floats, as claims often don’t live up to reality. For inland water sensing, don’t assume that “country-wide” includes your upland reservoir or remote abstraction point either.

Myth #2: More Bandwidth Solves Everything

Even within specialist services for IoT, the more throughput or volume you need, the larger the antenna, and the greater the power draw. Message-based services can be more challenging to work with (we’ll come back to this), but they are the most efficient means of utilizing a satellite link, especially for water sensors that only need to report periodically.

The following simplified table lays out the trade-offs.

*There’s no hard protocol limit that stops you above a certain size; NB-IoT can technically carry up to around 1.6 kB of user data in a single packet. But current NTN NB-IoT services are engineered around tiny messages (tens of bytes) and tens of kilobytes per month per device. Anything bigger quickly becomes slow, power hungry, and uneconomic.

This is in contrast to cellular NB-IoT, which can move 1-2 kB per transmission, and is generally economically viable up to ~5 MB of data per month per device. That’s more than enough for frequent level and quality readings from a river, reservoir or pipeline monitoring point, but if you try to replicate that pattern over satellite, both cost and power consumption quickly become challenging.

If you’ve been working with cellular NB-IoT and enjoying the larger volumes of highly economical transmissions that terrestrial networks facilitate, you’re in for a bit of a shock when it comes to moving that data over satellite. You will need to be able to work within the data constraints of the NTN version, which is likely to need some data optimization (we’ll come back to this shortly).

Another consideration that may stand in the way of seamless transition between cellular and NTN NB-IoT is your antenna.

• Cellular NB-IoT is designed to work with small, low gain antennas – often just a simple PCB or stub antenna in a plastic box. While antenna placement requires some forethought (not inside a metal box, not under a pump skid etc.), it doesn’t need to be outdoors.
• NTN NB-IoT over GEO satellites is a different beast. Connecting to a satellite which is – in the case of Viasat NB-NTN – 35,786 km from Earth requires a higher gain antenna and clear line of sight to the satellite. The antenna needs to be on the roof, on a mast, on top of a buoy, not buried in a pit or down in a plant room.

Not dissimilarly to your cellphone trying to find a network, a poorly positioned antenna drains power and is more likely to drop data.

The bottom line is that NTN is viable and workable for a myriad of water-sensing applications; just not all of them. And while working with data constraints might take some getting used to, doing so has cost, power and battery life benefits. So here are our top tips for optimizing your data for streamlined transmissions.

Most of the above is fairly self-explanatory, but it’s worth a quick dive into message-based protocols, because this is where many water monitoring applications can win back cost and battery life.

Why Message-Based Protocols Matter

Because cellular connectivity is abundant and cheap, most IoT applications use an IP connection to move data. We often liken this to a telephone call: an interactive, two way communication path which, while very widely used, has some drawbacks from an IoT perspective, particularly when operating with data constraints.

Firstly, the real time “conversation” between the sensor and your control centre is relatively hard on battery life. Secondly, the amount of overhead passed over that connection in addition to the actual data you need is considerable.

When you’re sending data into space, every byte matters.

Sending data over IP is not the most cost-effective, nor battery-conservative, means of using satellite IoT.

The alternative is a message-based solution, which we touched on earlier. NTN NB-IoT is message-based, as are Iridium SBD and IMT, and Viasat IoT Nano. Message-based connections are more like a text message: you send the message, receive an acknowledgement (note: not all services include this), and close the connection.

The message contains much less overhead, and the connection stays open only as long as is needed to transmit. This is the most economical way to use satellite IoT, both from a cost and power perspective. While it often requires a little more engineering work to format your data appropriately, it is usually worth the effort.

On the server / cloud side, platforms like Ground Control’s Cloudloop will decode the data on receipt and send it to your destination of choice, properly formatted, so there’s no need for engineering work on the cloud / server side.

Many applications can move to message-based transmission: data buoys, weather stations, reservoir level sensors, groundwater monitoring wells, water quality sondes and static flow/abstraction meters where data isn’t needed in real time.

If you do need real-time command and control, for example, remotely piloting a USV, or actively managing gates and valves in a complex hydraulic system, there are reliable services available, including Iridium Certus 100 and Viasat IoT Pro. But it’s definitely worth investigating message-based services if you can work with a few seconds’ latency and slightly less interactivity.

Choosing a Network: Matching Technology to Use Case

To bring this to life, we’ve put together this table to illustrate a few use cases.

If the device needs a real time connection, it needs an IP-based service, but if it’s solar powered, it needs to couple that requirement with high power efficiency. Iridium Certus 100 or Viasat IoT Pro meet both requirements, and are your best options here.

If the device is running exclusively on a battery, and has very low data requirements, this is a great application for NTN NB-IoT (Viasat’s brand for this service is NB-NTN). However, you need to check coverage. If coverage is not available, Iridium’s Short Burst Data (SBD) service is a cost effective and global alternative.

If data volumes are larger, Iridium Messaging Transport (IMT) can carry up to 100 kB per message, and the modules can also be powered by a battery. In each case, there are several options for the device that houses the module, ranging from enclosed and vibration-tested devices with simplified commands (RockBLOCK Pro) to developer PCBs with a choice of internal or external antennas (RockBLOCK 9704 / 9603).

Designing the Right Data Path for Your Water Sensors

The headline story around NTN is seductive: one chipset, everywhere connectivity, cellular-like costs. For water monitoring teams under pressure to instrument more assets – more rivers, more reservoirs, more outfalls, more offshore platforms – it sounds like the silver bullet we’ve all been waiting for.

It isn’t. But it can be a powerful new tool in the box if you treat it as such.

If there’s one takeaway from this post, it’s this: everywhere IoT is not something you buy; it’s something you design.

For water sensing, that design work boils down to a handful of questions:

• Where are my sensors, really? Open ocean, estuary, upland catchment, plant room? Coverage claims matter less than the actual map.
• How is each device powered? Battery, micro-solar, or a nice fat cable from the control room?
• How quickly do I genuinely need the data? Seconds, minutes, hours?
• How much data do I actually need to move? Raw streams, or carefully chosen summaries and alarms?

Answer those honestly, and the right combination of L-band IoT, NTN, cellular and (where appropriate) broadband satcom usually reveals itself.