Skip to content

Quick Start — What You Need to Know

Table of Contents

  1. Production Profile Decision
  2. Profile Comparison
  3. Why Profile B?
  4. System Power Flow
  5. What's Ready, What's Pending
  6. Real-World Cautions

Production Profile Decision

→ Use Profile B (Recommended Production) for standard farm deployment.

This is the locked recommendation. Profile B balances three competing demands: sufficient data sampling frequency (5-minute read intervals), acceptable power consumption (77.6 mAh/day), and WiFi communication latency (15-minute TX intervals). It delivers 31 days of autonomous operation on a fully charged battery with no solar input, and 4.5× energy surplus on a clear-day solar harvest. Most farms will deploy Profile B. Only in remote sites with severe dust/cloud conditions or extended deployments should you consider Profile C (Conservative).

Profile A (Debug) is strictly for bench commissioning and laboratory testing. Never deploy it to the field.

Profile Comparison

All numbers derived from ../data/system_parameters.yaml.

graph TD
    A["<b>Profile A: Debug</b><br/>5-min reads<br/>5-min TX<br/>Batch 1"]
    B["<b>Profile B: Recommended</b><br/>5-min reads<br/>15-min TX<br/>Batch 3"]
    C["<b>Profile C: Conservative</b><br/>10-min reads<br/>30-min TX<br/>Batch 6"]

    A --> A_Cons["📊 Daily Consumption<br/>33.4 mAh"]
    A_Cons --> A_Auto["🔋 Autonomy no-solar<br/>81 days"]

    B --> B_Cons["📊 Daily Consumption<br/>77.6 mAh"]
    B_Cons --> B_Auto["🔋 Autonomy no-solar<br/>31 days"]
    B_Auto --> B_Use["✅ Production<br/>Standard farms"]

    C --> C_Cons["📊 Daily Consumption<br/>54.8 mAh"]
    C_Cons --> C_Auto["🔋 Autonomy no-solar<br/>50 days"]
    C_Auto --> C_Use["🌍 Remote sites<br/>Minimal solar"]
Feature Profile A (Debug) Profile B (Recommended) Profile C (Conservative)
Read Interval 5 min 5 min 10 min
TX Interval 5 min 15 min 30 min
Batch Size 1 3 readings 6 readings
Daily Consumption 33.4 mAh 77.6 mAh 54.8 mAh
Autonomy (no solar) 81 days 31 days 50 days
Clear-day margin ~10× ~4.5× ~6.4×
Use Case Bench, lab, commissioning Production, standard farms Remote, minimal solar, heat stress
Data Freshness 5 min lag 15 min lag 30 min lag
Server Load High Moderate Low

Key Insight: Profile B is the sweet spot. It gives you near-real-time data (15-minute granularity is fine for crop monitoring), consumes only what a small solar panel can harvest in clear weather, and leaves a healthy 4.5× energy safety margin. If you need faster readings, increase the read interval and batch on the server side (processing multiple batches per transmission is cheaper than transmitting more often).

Why Profile B?

Data freshness: 15-minute transmission intervals mean the latest readings reach the server within 15 minutes. For crop monitoring (soil moisture, temperature trends), 15-minute granularity is sufficient. Irrigation decisions are made hourly or daily, not in real-time.

Energy balance: 77.6 mAh/day is comfortably sustainable on the Rajasthan dry-season solar harvest (350 mAh/day typical). This leaves a 4.5× safety margin. On a partly cloudy day (maybe 60% harvest), you still run a 2.7× surplus. Even on a dusty panel day (30% harvest), you tread lightly but survive with a small margin.

Firmware simplicity: Batching 3 readings per transmission is computationally trivial. The ESP32 can buffer data to EEPROM if WiFi is temporarily unavailable. The server receives consistent 3-tuple batches, making parsing and analytics simpler.

Field operations: You check on the node once a month, visually inspect the solar panel for dust, maybe wipe it clean. You never need to charge batteries or swap hardware unless something actually breaks.

System Power Flow

The energy system operates as a cascade: solar → charger → battery → boost → processor → sensors → WiFi. Each stage has efficiency losses and quiescent draws that accumulate. Understanding the flow is key to trusting the autonomy numbers.

graph LR
    Solar["Solar Panel<br/>6V, 200mA peak<br/>~350 mAh/day"] -->|"Voc 7.2V<br/>Ich 200mA"| Charger["MCP73871<br/>Charger<br/>500mA limit<br/>0.1mA quiescent"]

    Charger -->|"4.2V max<br/>~99% efficient"| Battery["18650 Battery<br/>3.7V nominal<br/>3400 mAh nominal<br/>2720 mAh usable"]

    Battery -->|"3.7V avg<br/>at load"| Boost["MT3608 Boost<br/>5V out<br/>85% efficient<br/>0.6 mA quiescent"]

    Boost -->|"5V nominal<br/>350mA max<br/>24/7 powered"| ESP32["ESP32 DevKit<br/>3.3V logic (LDO)<br/>0.01 mA sleep<br/>160 mA TX peak"]

    ESP32 -->|"GPIO 3.3V<br/>up to 400mA"| Sensors["Sensors<br/>• ADC reads<br/>• I2C devices<br/>• DHT22 (opt)<br/>• PIR<br/>• Soil (gated)"]

    ESP32 -->|"WiFi module<br/>~160 mA TX<br/>~95 mA RX"| WiFi["WiFi Transmit<br/>~20-30 mAh<br/>per full cycle"]

    Charger -.->|"Quiescent<br/>0.1mA"| Battery
    Boost -.->|"Quiescent<br/>0.6mA (dominant)"| Battery
    ESP32 -.->|"Sleep<br/>0.01mA"| Boost

    style Solar fill:#FDB913
    style Charger fill:#4CAF50
    style Battery fill:#2196F3
    style Boost fill:#FF9800
    style ESP32 fill:#9C27B0
    style WiFi fill:#E91E63

Sleep state (most of the time): battery supplies 0.762 mA total across all components (ESP32 0.01mA + MT3608 0.6mA + charger 0.1mA + misc 0.05mA). Over 24 hours: 0.762 mA × 1440 min = 18.2 mAh/day at rest.

Transmit state (few seconds, many times per day): ESP32 WiFi draws 160 mA peak, boost sees (160 mA × 5V) / (3.7V × 0.85 eff) = 254 mA on battery side. A full TX cycle (WiFi association + TCP handshake + data send) takes ~10–15 seconds. With 3 transmissions per hour (Profile B), that's 30–45 seconds of TX per hour, or ~12–18 minutes per day = 254 mA × 18 min / 1440 min = 3.2 mAh/day from TX alone. But WiFi association penalty and retries push actual consumption closer to ~30 mAh/day per transmission event.

Sensor read state (few milliseconds, frequent): ADC reads, I2C device polling, and optional DHT22 parasitic pullup draw negligible current compared to WiFi.

Profile B total: 18.2 (sleep) + 59.4 (WiFi three times per hour) = 77.6 mAh/day (including margin for retry overhead and inefficiencies).

What's Ready, What's Pending

Ready for Breadboard Validation

  • ✅ Component selection locked. All ICs are selected, ordered, and on-hand.
  • ✅ Schematic complete. Two design reviews passed. Ready for PCB layout.
  • ✅ Pin mapping finalized. GPIO allocation, I2C addresses, ADC channels all assigned in system_parameters.yaml.
  • ✅ Power budget modelled. Simulation covers all three profiles with consumption breakdown.
  • ✅ Firmware skeleton. State machine and sensor acquisition loop designed (implementation pending).

Pending — Blocking for PCB Fabrication

  • ⚠️ Breadboard power chain validation. Must build and test on breadboard:
  • MT3608 stability under 160 mA WiFi TX load (voltage droop, efficiency measurement)
  • ESP32 boot behavior when rocker switch is turned on
  • MCP100 reset threshold testing at cold (0°C) and hot (60°C) enclosure conditions

  • Actual power draw of assembled breadboard under WiFi TX

  • ⚠️ ESP32 physical measurements. DevKit V1 dimensions pending caliper check. Current spec is 30×52 mm, but actual variant may differ. Critical for enclosure layout.

  • ⚠️ Enclosure HT-5WAY internals. Size and mounting points not yet confirmed. Affects component placement on PCB and thermal routing.

  • ⚠️ Solar harvest field measurement. Current estimate is 350 mAh/day (based on panel spec sheet and Rajasthan irradiance averages). Must measure on-site to validate.

Pending — Post-PCB (Field Trial)

  • ⏳ Thermal testing (Rajasthan >50°C ambient expected)
  • ⏳ WiFi range and signal quality under field obstruction
  • ⏳ Battery aging and voltage trending over 2+ months
  • ⏳ OTA firmware update infrastructure

Recommendation: Breadboard validation is the critical-path item. Once it passes, PCB fabrication can proceed immediately. Budget 1–2 weeks for breadboard testing before committing to PCB.

Real-World Cautions

Solar Is an Estimate

The 350 mAh/day figure is modelled from panel specifications and Rajasthan climate data, not field-measured. Real-world harvest depends on:

  • Dust and pollen buildup — Rajasthan dry season can coat panels in 7–10 days. Even light dust reduces output by 20–30%.
  • Panel orientation — Must face south and be tilted to sun angle. Slight misalignment costs 5–10% harvest.
  • Seasonal variation — Winter (Jan–Mar) has higher solar irradiance than monsoon (Jun–Sep). Summer (Apr–May) is peak but can have haze.
  • Age and temperature — Panels degrade ~0.5%/year. Hot panels (60°C) are less efficient than cool panels.

Action: In the first field deployment, log solar panel voltage and current hourly. Compare actual harvest to the 350 mAh/day estimate. Adjust firmware Profile if needed. See Risk Scenarios for low-solar contingency.

WiFi Reliability Is Unknown

The range and penetration of the WiFi link from the field node to the on-site receiver have not been tested. In Rajasthan, vegetation is sparse (helps range), but metal farm buildings and terrain can scatter signal. Poor signal means:

  • WiFi association timeouts (firmware retries, consuming extra 10–20 mAh per day)
  • TCP packet loss (firmware retries, consuming extra 10–20 mAh per day)
  • Complete dropout periods (data buffered locally, transmitted when link recovers)

Action: In commissioning, do a site survey. Place the node at its planned location, check RSSI (signal strength) from the receiver. If RSSI < -75 dBm, consider repositioning the antenna or receiver.

Enclosure Thermal Rise

The HT-5WAY polycarbonate enclosure is transparent (good for light sensor, but conducts solar heat). On a 50°C Rajasthan day, internal temperature could reach 60–65°C. Li-ion batteries degrade faster at high temperature; MT3608 efficiency drops slightly.

Action: In early deployments, place a temperature sensor inside the enclosure (optional DHT22 on GPIO16). Log enclosure temperature alongside ambient. If internal temp regularly exceeds 55°C, consider: - Matte white or reflective enclosure coating - Small vent holes with desiccant to manage humidity - Active thermal monitoring in firmware (reduce TX if too hot)

See Risk Scenarios for detailed heat analysis.

Deployment Checklist (Pre-Field)

Before commissioning a node for field deployment:

  • [ ] Breadboard power chain tested and validated
  • [ ] MT3608 trimpot calibrated to 5V ±2%
  • [ ] ESP32 programmed with production Profile B firmware
  • [ ] All sensors tested and readings logged
  • [ ] Battery fully charged
  • [ ] Solar panel at 350 mAh/day baseline (or field-measured alternative)
  • [ ] WiFi RSSI verified at planned field location (>-75 dBm)
  • [ ] Enclosure sealed with desiccant
  • [ ] Daily consumption verified against model (logging test for 24h)

Next Steps

← Overview | Next → System Architecture