LoRa Soil-Moisture Monitoring Mesh with Gateway and Dashboard for Small Farms (Embedded C, Python)

LoRa Soil-Moisture Monitoring Mesh is a full LPWAN system — sensor nodes, a relay, a gateway and a dashboard — designed for a small Indian farm, where irrigation is decided by habit and groundwater is falling. Capacitive soil-moisture sensors and waterproof DS18B20 temperature probes are buried in the root zones of different plots. Each node — an Arduino Pro Mini 3.3 V paired with an RA-02 (Semtech SX1278) LoRa module on 433 MHz — sleeps in power-down mode, wakes on the watchdog timer, samples the sensors, and transmits a 12-byte packet with sequence number, battery voltage, moisture and temperature.

A node on the far plot cannot reach the pump shed directly, so a relay node stores and forwards its packets one hop — a deliberately simple two-hop mesh with duplicate suppression, no network server required. The gateway (ESP32 + RA-02, mains-powered at the pump shed) acknowledges packets, deduplicates them, and pushes batches over Wi-Fi to a Python (Flask + SQLite) dashboard on an old laptop. The dashboard plots per-zone moisture trends, raises irrigation alerts against crop-stage thresholds from FAO-56 guidance, and exports CSV.

Everything is programmed in Embedded C on the Arduino framework — squarely the territory of the JNTUH R22 Microcontrollers and IoT labs — and every design choice, from spreading factor to sleep current, is justified with measured numbers from our own field trials. Flask and SQLite are industry-standard extras labelled as such; the LoRa link, power budget and mesh logic are the project's real engineering.

On small Indian farms, irrigation decisions have no data behind them: the valve runs on a fixed schedule or on the farmer's judgement, so plots are alternately water-logged and stressed, borewell water and pump energy are wasted, and there is no record that could show what better scheduling would save. Commercial telemetry fixes exist but cost ₹8,000–15,000 per point plus a recurring SIM fee, which a two-acre holding cannot justify, and Wi-Fi-based student solutions do not cover an open field.

There is a need for a low-cost, no-recurring-fee monitoring mesh that measures soil moisture in several zones, carries the readings over hundreds of metres to a single mains-powered point using long-range low-power radio, survives field conditions on solar-charged batteries, and presents per-zone trends and simple irrigation alerts on a dashboard a farmer or a student team can actually read — turning published crop-water guidance into a daily, plot-specific decision.

Abstract

Small-holder farmers irrigate on habit and eyesight, over-watering some plots while others stress silently. This project builds a three-node LoRa mesh that reports soil moisture and temperature from different plots to a pump-shed gateway, with a Python dashboard turning readings into simple irrigation advice. A three-week soak test on a two-acre vegetable plot with solar-charged nodes produced measured link margins, packet-loss rates, sleep currents and discharge curves.

Introduction

A two-acre vegetable plot near the Hyderabad outskirts is typical of the target farms: drip laterals exist, but the valve runs a fixed time regardless of soil condition. Water is pumped from a borewell at real energy cost, and checking every zone twice daily costs the farmer time. Agronomy references such as FAO Irrigation and Drainage Paper 56 publish crop water requirements — knowledge that never reaches the valve. Schemes such as Per Drop More Crop push micro-irrigation hardware; what is missing is the data that says when to open the valve.

Existing System

• Fixed-schedule drip: the valve runs a set time whether the soil needs it or not; over-irrigation leaches fertiliser and drains the borewell.
• Touch-and-feel checks: crumbling soil between fingers twice a day; subjective and unrecorded.
• Commercial GSM telemetry loggers: ₹8,000–15,000 per node plus recurring SIM cost — unrealistic for a two-acre holding.
• Wi-Fi-based student projects: single node, single sensor — and Wi-Fi does not cross an open field.
• Limitations: no per-zone data, no history, no alerting, and recurring costs a small farmer cannot justify.

Proposed System

• Sensing: corrosion-free capacitive soil-moisture sensors at 15 cm depth in each zone, plus DS18B20 soil temperature, calibrated per sensor with dry-air and water references.
• Nodes: Pro Mini 3.3 V in power-down sleep, watchdog wakeups, a 12-byte packet (node id, sequence number, battery voltage, moisture, temperature) transmitted at SF9 on 433 MHz.
• Mesh: a store-and-forward relay extends coverage to the shaded far plot; a hop byte and sequence numbers give duplicate suppression without a routing protocol.
• Gateway: ESP32 + RA-02 at the pump shed ACKs, deduplicates, buffers to local flash during laptop downtime, and batch-uploads over Wi-Fi.
• Dashboard: Flask + SQLite shows per-zone moisture trends, battery health and irrigation alerts against crop-stage thresholds; CSV export feeds the report.

Feasibility Study

• Technical: the SX1278 link budget at SF9 covers the ~600 m line-of-sight span on this class of farm, the relay closing the shaded path — verified by an on-site RSSI survey before hardware commit. All firmware sits on a documented open-source Arduino library for the SX1278.
• Economic: about ₹5,800 one-time for three nodes, relay and gateway; zero recurring cost — solar-charged 18650 cells, no SIM. That is the decisive edge over GSM loggers.
• Operational: the probe sits in the ground, the electronics in IP-65 boxes; the farmer reads one dashboard screen or a weekly printout. Risks — monsoon ingress, antenna damage, calibration drift — are designed out and re-checked in the soak test.

In scope

• Three sensor nodes plus one relay and one gateway, one farm, 433 MHz short-range band with low transmit power and duty-cycled transmission.
• Monitoring and alerting only — the system advises; it does not actuate valves.
• One-hop store-and-forward meshing with duplicate suppression; no dynamic routing protocol.
• Calibration and soak-test methodology with published measurements.

Out of scope (v1)

• A LoRaWAN stack and network server (raw LoRa point-to-multipoint is used deliberately; LoRaWAN is future scope).
• Valve or pump actuation, fertiliser dosing, and weather-station integration.
• Security hardening beyond CRC and sequence checks — payload encryption (AES-128, as LoRaWAN would mandate) is listed as future work.
• Multi-farm or cloud-hosted deployments; the dashboard is intentionally self-hosted on one laptop.

The team followed the Spiral model, chosen because the dominant risks — radio range in the field, battery endurance and sensor calibration drift — can only be retired by real field iterations, and each spiral loop ends with an explicit risk review before the next loop's commitment.

Test plan: unit tests per stage (sensor raw-value histograms, radio register read-back, RSSI survey sheets); integration tests (relay forwarding, duplicate rejection, ACK timeout retransmission, gateway buffer replay after Wi-Fi outage); system-level soak testing with daily field visits logging battery voltage, packet counters and a manual soil-check reference; and dashboard failover tests (laptop off overnight, gateway buffers, no data loss on reunion). Every case is recorded as ID, input, expected, actual, result.

The system has three tiers: field nodes, a backhaul edge (relay + gateway), and a self-hosted dashboard. Nodes spend almost their whole life in power-down sleep; on watchdog wakeup they read the capacitive sensor through the ADC and the DS18B20 over 1-Wire, build a 12-byte frame — node id (1 B), sequence number (2 B), battery mV (2 B), moisture % (2 B), temperature ×10 (2 B), hop byte (1 B), CRC-8 (1 B) — and transmit at SF9. After transmitting, the node listens 2 s for an ACK; three silent retries are logged with the packet counter so the report can quantify link quality. The relay node runs a store-and-forward queue: packets whose hop byte is 0 are retransmitted with hop set to 1, and sequence numbers let the gateway reject duplicates.

The gateway (ESP32 + RA-02) ACKs directly-heard nodes, feeds the relay's queue when it forwards, writes every accepted reading to local flash, and batch-POSTs to the dashboard over Wi-Fi every five minutes, replaying buffered batches after outages. The dashboard keeps readings, nodes and alerts tables in SQLite, renders per-zone moisture and battery trends with an open-source charting library, computes alerts against crop-stage thresholds, and exports the CSV used in the report.

flowchart TD
  ZA["Zone A node: Pro Mini 3.3V + RA-02 + capacitive probe + DS18B20"] -->|433 MHz LoRa SF9| GW["Gateway: ESP32 + RA-02 at pump shed"]
  ZB["Zone B node (far, shaded plot)"] -->|LoRa hop 0| REL["Relay node: store & forward, hop set to 1"]
  REL -->|LoRa hop 1| GW
  GW -->|ACKs + dedupe by node id + seq| GWBUF["Local flash buffer (survives Wi-Fi outage)"]
  GWBUF -->|Wi-Fi, HTTP POST batch every 5 min| SRV["Flask + SQLite on farm laptop"]
  SRV --> UI["Dashboard: moisture trends, battery health, irrigation alerts, CSV export"]
  SOL1["6V solar + TP4056 + 18650"] -.->|charges| ZA
  SOL2["6V solar + TP4056 + 18650"] -.->|charges| ZB
  MAINS["Pump-shed mains + 5V adapter"] -.->|powers| GW

All firmware is Embedded C on the Arduino framework; the only Python lives on the dashboard side. The 12-byte frame and its field order are documented so any node, relay or gateway can be reimplemented independently — the test that keeps the team honest about the protocol.

• LoRaWAN migration to the Indian 865–867 MHz band with a proper network server, device profiles and AES-128 security, ideally via a community gateway deployment.
• Valve automation: a latching solenoid driver on each node so the dashboard's advice closes the loop into scheduled micro-irrigation.
• More agronomy inputs: soil EC/pH probes and a rain-gauge node, extending the frame format without breaking old gateways (version byte is reserved).
• Crop-model scheduling: replace fixed thresholds with FAO-56-based water-balance scheduling using local weather data, in consultation with the local KVK.
• Fleet features: OTA firmware updates over LoRa for the nodes and a multi-gateway setup for larger farms.