We’ve been delivering remote IoT connectivity for over 20 years, and in our experience, remote IoT projects run into trouble when the system becomes too expensive, too power hungry, or too complex to support once it moves beyond the pilot stage.
These problems tend to show up when deployments move from proof of concept to real rollout, when assumptions about cost, data behavior, battery life and field support are tested properly.
That’s why the most important decisions in remote IoT often happen early. The architecture you choose, the amount of data you send, and the way the device behaves in the field all shape whether a deployment is commercially viable at scale. Our latest eBook explores these considerations, and how to set your project up for success.
The first big decision: aggregate locally, or connect each asset directly?
One of the earliest design choices is whether assets should connect individually to the wider network, or whether multiple sensors should be aggregated through a gateway, hub or local site network before backhaul. Neither model is inherently better. The right answer depends on the job the system is there to do.
Aggregation often makes sense when sensors are physically close together, fixed in place, and operating in a consistent environment. In those situations, a shared gateway can reduce per-device hardware cost, simplify backhaul and support very low power sensor operation. If dozens of sensors are concentrated on one site, it often makes little sense to give every endpoint its own wide area connection.
Direct connectivity becomes more attractive when assets are dispersed, mobile, deployed across difficult terrain, or likely to have different reporting patterns and service requirements. In those cases, the value is independence.
Each device can operate without relying on a gateway, local radio coverage or site-specific network design. That can be especially important for use cases like environmental monitoring, mobile equipment or remote assets spread over a large area.
A good way to think about it is this: aggregation can be very efficient, but it also creates dependency on local infrastructure. Direct connectivity can be more flexible, but only if the economics work.
Why direct connectivity deserves a fresh look
For years, the trade-off in remote IoT was fairly predictable: aggregate wherever possible, and reserve direct connectivity for the assets that really needed it. That’s starting to change. Direct-to-satellite sensor connectivity is not new; services such as Iridium SBD and other proprietary approaches have supported it for years. What’s changing is that the market is making those models easier, smaller, lower power and more cost effective for a wider range of deployments.
That shift is being driven from two directions. On one side, proprietary providers are continuing to launch more compact, lower cost devices aimed at simple remote sensing, such as the Iridium 9604 and Kinéis KIM2. On the other, NTN (non-terrestrial networks; shorthand for the use of cellular standards delivered over satellite, such NB-IoT) is beginning to shape expectations around what future standards-based direct connectivity could look like for low data, low power applications. NTN matters, but it’s not the whole story, and it’s not the right answer for every use case.
The more useful takeaway is that direct connectivity now deserves to be reconsidered more seriously than it might have been a few years ago. Proven options already exist, newer proprietary ones are improving the economics, and standards-based alternatives are coming. The right choice still depends on the asset, the data requirement and the operating model, but the design space is clearly widening.
Your data model is your cost model
Remote IoT gets expensive quickly when devices send more data than the application actually needs. That affects airtime, but it also affects battery life, because every transmission uses energy. In many deployments, reporting behaviour has more impact on lifetime cost than the hardware itself.
That’s why the data model needs to be part of the system design from the start. Begin with the minimum useful data: what needs to be sent, how often, and whether batching, thresholds or exception-based reporting would do the job more efficiently.
In remote IoT, sending less data, less often, is often one of the fastest ways to improve both cost and performance.
Battery life is not a spec sheet number
Battery life isn’t really a device specification; it’s the result of a series of design choices. In remote deployments, long life depends on duty cycle, transmission behaviour and how the device behaves in real field conditions, not ideal lab ones.
The practical rule is simple: sleep should be the default state. Devices should wake for a clear reason, complete a clear task, and return to low power as quickly as possible.
Solar can help extend operating life, but it works best when the underlying system is already efficient, not when it is being used to patch an inefficient design.
Remote IoT scales better when the basics are right
Remote IoT becomes easier to scale when systems are designed around the real requirement, not the maximum technical possibility. That means choosing the simplest connectivity model that fits the job, defining the minimum useful data, and designing the power budget around real field behavior rather than ideal conditions.
For engineers, OEMs and systems integrators, that discipline makes a huge difference. It can be the difference between a deployment that looks fine in a pilot but becomes painful in production, and one that is easier to support, easier to justify commercially and much more sustainable over time.
Download the full eBook to go deeper into the trade-offs around aggregation vs. individual connectivity, why direct connectivity is changing, how to design a data model that keeps costs under control, and what battery life planning really needs to look like in remote deployments.
How can we help?
If your application has some remote deployments, and you’d like advice on the most reliable and cost-effective way to network your sensors, we’re here to help.
You don’t need to complete this form to get the eBook – please just click on one of the links in the blog post – but if you’d like to talk to one of our engineers, please email hello@groundcontrol.com, or use the form to tell us a bit about your application.
We’ll respond within one working day.