Skip to content

Ramgarh Farm Sensor Node — Project Overview

Table of Contents

  1. What is This Project?
  2. System at a Glance
  3. Why This Matters
  4. Documentation Map
  5. Current Status
  6. Quick Numbers

What is This Project?

The Ramgarh Farm Sensor Node is a solar-powered, battery-backed monitoring station designed to collect environmental and agricultural data from a remote farm in Rajasthan, India. The sensor node lives in the field, exposed to extreme heat, dust, and occasional rain, autonomously measuring soil moisture, rainfall, air temperature, humidity, light intensity, and motion detection. Every 15 minutes it reads these sensors; every 15 minutes (configurable) it sends a batch of data over WiFi back to a central farm server in London.

This is not a security camera system. It is fundamentally a crop-first monitoring platform. The sensors exist to answer agricultural questions: Is this zone getting adequate moisture? How much rain fell overnight? Are the microclimates across the farm differentiated? The data flows into a digital twin model that helps predict crop development, detect irrigation scheduling problems, and feed analytics to the farm team.

The engineering challenge is elegantly simple but practically difficult: keep a sensitive electronic device alive for 31 days without recharging, powered only by a small solar panel under Rajasthan's harsh dry-season conditions (dust, intense heat, varying cloudcover). The solution combines careful component selection, aggressive power management in firmware, and a clear understanding of the energy budget.

This documentation package describes Rev A.1 of the sensor node hardware. Rev A.1 is the first production design—a refinement of prototypes—targeted at pre-validation testing on breadboard before PCB manufacture. Some values in this document are still estimated; others are locked based on datasheet specifications and engineering analysis. Every number is sourced back to the system_parameters.yaml file in ../data/.

System at a Glance

The sensor node operates as an integrated power and sensing system. Energy flows from the solar panel through a charger into a lithium-ion battery, which feeds a boost converter to produce stable 5V supply for the microcontroller. The microcontroller orchestrates sensor reads, formats data, and transmits packets over WiFi. A watchdog supervisor monitors the system voltage and holds the microcontroller in reset if supply voltage dips dangerously low.

graph LR
    Solar["☀️ Solar Panel<br/>6V 200mA<br/>~350mAh/day"]
    -->|Voc 7.2V| Schottky["⚡ SS14 Schottky<br/>Vf 0.3V"]

    Schottky -->|~6.9V| Charger["🔌 MCP73871<br/>Solar Charger<br/>500mA"]

    Charger -->|4.2V max| Battery["🔋 Li-Ion 18650<br/>3400mAh<br/>3.0-4.2V"]

    Battery -->|3.7V nom| Switch["🎚️ Rocker Switch<br/>Master Power"]

    Switch -->|3.0-4.2V| Boost["⬆️ MT3608<br/>5V Boost<br/>85% efficient"]

    Boost -->|5V 350mA| MCU["🧠 ESP32 DevKit<br/>WiFi + ADC<br/>32-bit ARM"]

    Boost -->|5V| Supervisor["🛡️ MCP100-450<br/>Brownout Reset<br/>4.5V threshold"]

    MCU -->|3.3V| Sensors["📊 Sensors<br/>• Soil moisture<br/>• Rain detector<br/>• Temperature/Humidity<br/>• Light intensity<br/>• Motion"]

    MCU -->|WiFi| Server["☁️ Farm Server<br/>Data ingestion<br/>Cloud processing"]

Every component is chosen to minimize energy draw in the sleep state. When the ESP32 is not transmitting, it enters deep sleep consuming just 0.01 mA. The entire system (including the boost converter's quiescent draw) sleeps at ~0.76 mA. Over 24 hours, that idle consumption adds up to 18.2 mAh. When the WiFi transmitter turns on, current jumps to 160+ mA for a few seconds. A full transmit cycle (including WiFi association and TCP handshake) might consume 20–30 mAh. Under the recommended Profile B configuration, the node transmits once every 15 minutes with 3 sensor readings batched per transmission. The daily energy budget works out as follows: 18.2 mAh (sleep) + ~59.4 mAh (WiFi transmissions) = ~77.6 mAh per day consumed. The solar panel on a clear day harvests ~350 mAh, a 4.5× surplus. On cloudy days or dust-covered panels, the margin shrinks. On no-solar days, the 2720 mAh usable battery capacity sustains operation for 31 days without any harvested energy.

Why This Matters

Agricultural monitoring in remote regions faces three hard constraints: power, connectivity, and reliability. Traditional grid-powered weather stations require trenched power lines. Cellular-only nodes depend on variable signal strength. The Ramgarh approach is different: assume unreliable or absent WiFi, assume no grid power, assume harsh environmental conditions. Build a system that survives by itself, harvests its own energy, and queues data locally when connectivity drops. The sensor node is designed to outlive the farmer's attention span—it works in the background for months, asking nothing of the human except that it sit in the field unmolested.

For crop monitoring, this means: - Continuous baseline data — Temperature, humidity, and soil moisture profiles across the farm reveal irrigation stress, evaporation patterns, and localized microclimates. - Early problem detection — Sensors trigger alerts when moisture dips below critical thresholds or temperature swings suggest frost risk. - Repeatable analytics — The digital twin model takes the same measurements every 15 minutes. Year-over-year comparison becomes possible. - Autonomous operation — No technician visits the field to charge batteries or swap SD cards. The system owns its energy destiny.

This is particularly important in Rajasthan, where summer temperatures exceed 50°C, dust storms can obscure panels for days, and grid power is intermittent. A system designed for autonomy is a system that scales across the farm without multiplying the operations burden.

Documentation Map

Document Purpose Read Time
00. Overview (this file) High-level context, why the project exists, system diagram 15 min
01. Quick Start TL;DR for production deployment, profile recommendations, key graphs 10 min
02. System Architecture Detailed block diagram, voltage domains, sensor pinout, communication flow 30 min
03. Power Model State machine, consumption calculations, battery math, assumption table 40 min
04. Results Summary Simulation graphs, autonomy numbers, confidence levels 25 min
05. Design Decisions Why each component was chosen, tradeoffs, rationale 35 min
06. Risk Scenarios What can fail, failure modes, mitigation strategies 30 min
07. Deployment Guide Commissioning procedure, field validation checklist, monitoring 25 min
08. Future Enhancements Roadmap, adaptive firmware, mesh networking, camera integration 15 min

Recommended reading order for new team members: 1. Start here: Overview (this file) 2. Then: Quick Start to understand production configuration 3. Then: System Architecture to see how components connect 4. Optionally: Power Model for deep understanding of energy budget 5. Reference: Design Decisions when you need to understand the "why" 6. Reference: Risk Scenarios before deployment

Current Status

Revision: A.1 (pre-validation)

What is complete: - Component selection (all ICs ordered and on-hand) - Schematic design (two reviews complete, ready for PCB) - Power model simulation (confidence: medium-high) - Pin mapping and firmware skeleton (GPIO allocation locked) - System architecture (block diagram, voltage domains, power budget)

What is pending (blocking PCB): - Breadboard power chain validation (MT3608 stability under WiFi TX load) - MCP100 reset behavior verification (threshold testing at cold/hot) - ESP32 physical dimensions (caliper measurements of DevKit variant) - Enclosure measurements (HT-5WAY internals for component placement) - Solar harvest field validation (current estimate is 350 mAh/day, not measured)

What is pending (post-PCB): - Thermal testing (Rajasthan >50°C ambient; internal enclosure rise estimation) - WiFi range testing (distance and obstruction effects on signal) - Long-term reliability (2+ month field trial with battery voltage trending) - OTA firmware update infrastructure

Key Insight: Rev A.1 is production-intent but pre-validated. Breadboard testing is the critical-path blocking item. Once breadboard validation passes, PCB can proceed to fabrication with confidence.

Quick Numbers

All values sourced from ../data/system_parameters.yaml (the single source of truth).

Parameter Value Confidence Notes
Battery Capacity 2,720 mAh MEDIUM NCR18650B, usable 80% after derating
Daily Consumption (Profile B) 77.6 mAh MEDIUM Modelled, validated on breadboard pending
Autonomy (no solar) 31 days MEDIUM Derived from above
Solar Harvest (clear day) 350 mAh/day LOW Estimated; NOT field-measured yet
Energy Margin (Profile B) 4.5× MEDIUM Harvest ÷ consumption on clear days
Sleep Current (all systems) 0.762 mA MEDIUM Dominated by MT3608 quiescent (79%)
WiFi TX Peak Current 160 mA HIGH ESP32 datasheet peak
BOOST Output Voltage 5.0 V MEDIUM Set by MT3608 trimpot, ±2% tolerance
Battery Nominal Voltage 3.7 V HIGH NCR18650B datasheet
Battery Operating Range 3.0–4.2 V HIGH Cutoff at 3.0 V (MCP100 threshold 4.5 V on BOOST = ~2.8 V on BAT)

Recommendation: Before field deployment, measure solar harvest on a clear day and validate WiFi TX stability on breadboard. Both will refine autonomy estimates and build confidence in the model.

Next Steps

← Start | Next → Quick Start