Off-Grid Soil Moisture Sensor Network with LoRaWAN

What an off-grid soil sensor network actually has to survive

The hard part of an off grid soil sensor network is not the radio. It is that every node sits unattended in a field for a full growing season, swinging from freezing pre-dawn to hot afternoon, getting rained on, growing a crop canopy that did not exist when you commissioned it, and being powered by a panel that the crop will eventually shade. Most failures we are called to fix are mechanical, thermal, or power-sequencing problems wearing a "the data stopped" costume — not LoRaWAN problems.

So this is a build guide written backwards from the failures. Every recommendation below is tied to the specific way a node dies in the field if you skip it: the sensor interface choice, the power budget for solar plus battery, what LoRaWAN range really looks like once the crop is tall, where the gateway has to sit, and how the bytes get from a stake in the dirt to a Grafana panel someone actually looks at.

Sensor interface: analog vs RS485 vs SDI-12

The single decision that determines whether your network is trustworthy is the soil probe interface, because it sets whether a reading taken at node 1 means the same thing as the same reading taken at node 20. Analog capacitive probes are seductively cheap, but the analog voltage drifts with cable length, supply-rail noise, and temperature, so per-node calibration does not survive a long cable run or a hot afternoon. For anything beyond a single short-cable probe, go digital.

A few rows decide most real builds. RS485 uses differential signalling, so it shrugs off the electrical noise that an open analog wire picks up next to a pump or VFD, and it lets you multidrop several probes — for example three depths in one profile — onto a single node's bus, which slashes node count and BOM. SDI-12 is the interface most agronomy probe vendors standardise on, so if you want the widest off-the-shelf sensor catalogue and addressed multi-sensor buses, it is the safe default. The on-device job in either case is the same: wake, power the bus, read the registers, and — if you are computing pore-water EC (poreEC) on the node from raw permittivity and bulk EC — run that conversion locally so you transmit a small, finished number instead of three raw fields.

The field failure this prevents: a network of analog probes that all read plausibly at the bench and then disagree by double digits across the field once cables differ in length and the sun is on them. You cannot calibrate your way out of that after deployment; you avoid it by choosing the interface up front.

Computing poreEC on the node, not in the cloud

It is tempting to ship raw permittivity, bulk EC, and temperature and let a server compute pore-water EC. Do the conversion on the node instead. Two reasons, both about failure modes. First, LoRaWAN payloads and duty cycles are tight, so sending one finished poreEC value plus volumetric water content costs far fewer bytes — and far less airtime and battery — than three raw fields. Second, when the link drops for a day, a node that already computed and queued the finished value can resend exactly what the agronomist needs, whereas a "raw + compute upstream" pipeline loses meaning the moment the upstream model version drifts from what the node was calibrated against. Keep the math next to the sensor.

Power budget: a deep-sleeping node, not a thirsty one

For a daily-report node the energy arithmetic is almost embarrassingly in your favour, if you architect it right. The node should spend essentially all day in deep sleep, wake once or twice to power the sensor bus, take a reading, transmit one uplink, and sleep again. In that mode an ESP32-class node plus an RS485 transceiver draws a sleep current measured in microamps and an active burst measured in tens of milliamps for a second or two. A small solar panel harvests more in a few hours of sun than the node spends in a day.

So the battery is not sized for energy — it is sized for autonomy through bad weather and for surviving cold. The trade-offs that actually matter:

1. Pick the cell chemistry for the climate, not the datasheet capacity. Standard Li-ion must not be charged below roughly 0 C without plating damage; LiFePO4 tolerates cold better and is more abuse-tolerant. In a climate with frosty mornings, the cheaper-per-Wh cell that refuses to charge at dawn is the expensive choice.
2. Size for several cloudy days of autonomy. The panel will have a run of overcast days and the node must coast through them. Capacity here buys uptime, not range.
3. Mount the panel above the canopy from day one. The crop you are monitoring grows up and shades the panel that powers the node. A panel sized for full sun that ends the season in shade is a guaranteed mid-season dropout.
4. Add a low-voltage cutoff and a clean brown-out recovery. Let the cell sag too low and you both damage it and risk the node browning out mid-transmit and corrupting state. Cut off cleanly, and on recovery re-init the radio session rather than assuming it survived.
5. Seal and breathe the enclosure. Condensation inside the box, not the energy budget, is the most common quiet killer. Use a rated gland for the probe cable and a vent membrane so the box does not pump moist air in and out as it heats and cools.

The failure these prevent is the classic one: a node that ran beautifully on the bench and through a sunny commissioning week, then went dark in week six — not because it ran out of energy, but because the cell would not charge at 2 C one morning, or the now-tall crop shaded the panel, or water beaded on the PCB.

LoRaWAN range over a real crop canopy

Here is where datasheets lie by omission. LoRaWAN marketing range figures assume line-of-sight over open ground. Your field grows a wet, dense crop canopy between the node and the gateway, and at 868/915 MHz that water-filled foliage absorbs RF. The same node that hit the gateway from a kilometre away over bare soil at planting can struggle from a few hundred metres at full canopy. The lever you have is the spreading factor (SF): a higher SF demodulates a weaker signal, buying range and canopy penetration, but it stretches airtime, which costs battery and burns into your duty-cycle budget.

The engineering rule we apply: let Adaptive Data Rate (ADR) optimise the easy nodes, but size your gateway placement and antenna for the worst node at full canopy. A network that links perfectly in spring at SF7 and falls off a cliff in mid-summer when every node ADRs up to SF11/SF12 — colliding with itself and draining batteries — is a network commissioned at the wrong time of year. For a daily-report node even SF12 is energetically survivable because it transmits so rarely, but SF12 everywhere means airtime collisions and duty-cycle exhaustion, so treat high SF as a tool for a few hard nodes, not a default.

The failure this prevents: a perfect spring commissioning followed by silent nodes in July. Always do a range test at full canopy before you trust the network for a season.

Gateway placement: height beats power

You do not fix a canopy with a louder node; you fix it with a higher gateway antenna. Lifting the gateway antenna above the canopy restores something close to line-of-sight to the tops of the stalks and does more for your link budget than any per-node tweak. Practical placement:

• Put the gateway antenna as high as you safely can — a mast, a barn roof, an existing pole — so it looks over the crop, not through it.
• Centre it so the farthest node still closes the link at full canopy, not so the average node is happy.
• Give the gateway the reliable power and backhaul: it is the one device that should not be off-grid if you can avoid it, because it is the single point through which every node's data flows.
• Keep the antenna feedline short and use a proper lightning/surge arrestor — an elevated mast in an open field is a strike target.

Data path: from a stake in the dirt to a Grafana panel

Bytes leave the node as a compact LoRaWAN uplink, the gateway forwards them to the network server, and from there an application-layer integration decodes the payload and writes points into InfluxDB, which Grafana reads for dashboards and alerts. The discipline that keeps this trustworthy:

1. Decode to typed fields once. A payload decoder turns the packed bytes into named, typed values (volumetric water content, poreEC, temperature, battery voltage, RSSI/SNR) before they hit the database, so a node firmware change is one decoder edit, not a schema migration.
2. Store the link metadata, not just the moisture. Persist RSSI, SNR, SF, and battery voltage alongside the readings. When a node goes quiet, those are the fields that tell you whether it is a dying battery, a canopy range problem, or a gateway outage.
3. Alert on absence, not just thresholds. The most useful agritech alert is "node 7 has not reported in 36 hours," because a missing node is the early signal of every field failure above. A moisture-threshold alert only fires when data is still flowing.

Battery voltage and RSSI/SNR trended in Grafana are the single best early-warning instrument you have: a slowly sagging battery line or a node creeping up the SF ladder week over week tells you which node will fail before it goes dark, while there is still time to walk out and fix the panel shade or reseat a connector.

Where LoRaWAN beats cellular — and where it does not

Be honest about the radio. LoRaWAN wins on a contiguous farm with many nodes: once you own and power a gateway, each additional node is cheap, low-power, and has no recurring SIM cost, and a daily-report node sips energy. Cellular (LTE-M / NB-IoT) wins when your plots are scattered far enough apart that one gateway cannot cover them, when you do not want to own and power gateway infrastructure, or when a node must send larger or more frequent payloads than LoRaWAN's duty cycle comfortably allows. The decision is mechanical: count your nodes and measure the distance between the two farthest ones. Dense and close favours LoRaWAN; sparse and far favours LTE-M. Many real deployments are hybrid — LoRaWAN for the clustered home farm, an LTE-M node for the one remote plot across the road that the gateway cannot reach.

GizanTech designs the node hardware, writes the ESP32 firmware that computes poreEC on-device and survives brown-outs, and stands up the LoRaWAN-to-InfluxDB-to-Grafana pipeline as one system, so the interface, power, range, and data-path trade-offs above are made once with the whole field in view instead of discovered node-by-node in July. If you are scoping a soil-monitoring network and want the radio, power, and sensor-interface decisions validated against your actual field before you build twenty of them, talk to our agri-tech team.

Frequently asked questions

How far can a LoRaWAN soil sensor node realistically transmit across a field?

On open ground with a clear gateway sightline you can get several kilometres, but over a mature crop canopy the realistic, dependable figure is much lower because wet leaves at 868/915 MHz absorb signal. Plan for a few hundred metres to roughly a kilometre per node depending on canopy height and gateway antenna height, and prove it with an end-of-season range test at full canopy, not on bare soil at planting.

How long will a solar-powered soil sensor node run between failures off-grid?

A node that deep-sleeps and reports once or twice a day should run indefinitely on a small solar panel plus a Li-ion or LiFePO4 cell, because the daily energy it harvests far exceeds what it spends. The failures that actually take nodes down off-grid are rarely the energy budget: they are condensation in the enclosure, a panel shaded by the very crop you are monitoring, connector corrosion, and lithium cells refusing to charge below 0 C. Size the battery for several cloudy days of autonomy and solve the mechanical and thermal problems and the node outlasts the season.

Should I use RS485, SDI-12, or analog soil moisture probes for a multi-node network?

For a multi-node network use RS485 (Modbus) or SDI-12 digital probes, not analog. Analog capacitive probes are cheap but drift with cable length, temperature, and supply noise, so calibration does not hold across a field. RS485 gives long cable runs and lets you multidrop several probes on one node; SDI-12 is the agronomy-standard digital bus with excellent vendor support. Reserve analog for a single short-cable probe where BOM cost dominates and field accuracy does not.

When is cellular (GSM/LTE-M) a better choice than LoRaWAN for farm telemetry?

Cellular wins when your nodes are scattered across far-apart plots that a single gateway cannot cover, when you do not want to own and power a gateway, or when a node must send larger or more frequent payloads than LoRaWAN duty cycles allow. LoRaWAN wins on a contiguous farm with many nodes because the per-node power and recurring cost are far lower once your own gateway is up. The honest rule: count your nodes and measure the distance between the farthest two; dense and close favours LoRaWAN, sparse and far favours LTE-M.