A sensor that cannot report is a data logger someone has to drive to. Most field programs discover this after the sensors are bought, when the site turns out to have one bar of signal on a good day. The link should be chosen with the sensors, not after them, and the choice is usually between three options, each with a clear place.
Cellular (LTE-M and NB-IoT)
Where there is coverage, cellular is the simplest. The sensor or its gateway carries a modem and a plan, data goes straight to the cloud, and there is no infrastructure to own. LTE-M and NB-IoT are the low-power variants built for devices that send small messages a few times an hour; they cost a fraction of a phone plan and let a battery-powered node last months or years.
The catch is coverage at the antenna, which is not the coverage map. A site survey with the actual modem, at the actual mounting height, before purchase, is the only reliable test. Plan cost per device also adds up across a large deployment, and the carrier decides when a network generation is retired.
LoRaWAN
LoRa is a long-range, low-power radio that works with no carrier at all. Sensors talk to a gateway you own, kilometres away with line of sight, and the gateway needs a backhaul: cellular, Ethernet, or satellite. It shines where there are many sensors across a large site (a watershed, a campus, a farm, a facility) and where the messages are small.
You own the network, which is both the appeal and the responsibility. Gateway placement, antenna height, and power are engineering work. Throughput is small by design, so it is the wrong choice for images or audio. Public LoRaWAN networks exist in some areas and can remove the gateway work where they reach.
Satellite
For sites that no terrestrial network reaches, satellite IoT services now carry small messages from a modem the size of a matchbox, at a cost per message that makes a few readings a day affordable. It is the right answer for remote monitoring where any other link means a truck. It is the wrong answer for anything that needs frequent updates, because message cost and latency dominate.
The gateway is the system
Whichever radio is chosen, the field gateway is where reliability lives. It should buffer readings when the link is down and send them in order when it returns, so an outage is a gap in latency, not in data. It should watch its own health (battery, temperature, link quality) and report that too. It should be updatable in the field without a visit, and it should be able to be rebooted remotely. A gateway that does these things turns a fragile deployment into one that runs unattended.
The power budget decides more than the radio
Every design starts from how much energy the site can give a node per day, from mains, solar, or a battery that is replaced on a schedule. Radios, sensors, and sample rates are chosen to fit that budget with margin for winter. Programs that skip this step learn about it in February.
Security in the field
Devices carry credentials, so they must be provisioned individually, be revocable, and talk only over encrypted links. Physical access is assumed: a node in a field can be taken. The design should make that a lost node, not a compromised network. Data should land inside the agency's boundary or a government cloud region, with the same logging and access rules as any other system.
A method that works
- Survey the site with the candidate radios and measure, do not assume.
- Set the power budget and the reporting interval from the science or the operation, then choose the link that fits.
- Buy one gateway and a few nodes, deploy them for a month, and look at the gaps.
- Then scale, with the same gateway configuration and a written procedure for adding a node.
Working with us
We design and build sensor networks and the radio links, gateways, and cloud ingestion behind them, and we supply the sensors themselves. If you have a site to connect, tell us what you're working on, or see sensors and research systems.