How I built a solar-powered RS-485 soil sensor node for orchard management (open hardware)

Shaunak Sayta — Wed, 15 Apr 2026 12:09:54 +0000

I've been building a per-tree precision agriculture platform for a 2,100-tree
Alphonso mango orchard in Gujarat, India. After a year of hand-wired prototypes,
I commissioned a proper carrier board. The hardware is now fully open — Gerbers,
BOM with LCSC part numbers, and PickAndPlace for JLCPCB assembly.

What the board does

Each node wakes hourly, reads one or more RS-485 Modbus soil sensors (EC, pH,
moisture, temperature, NPK), posts the data to a Cloudflare Workers API, then
goes back to deep sleep. The whole thing runs on a 20W solar panel and a 12.8V
LiFePO4 battery — enough for 15-20 days of monsoon reserve with no sun.

The hardware stack

MCU: Waveshare ESP32-S3-Nano (socketed, not soldered to board)
RS-485: MAX485ESA+ with SM712 TVS surge protection
Power: LM2596S 12V→5V buck, dual AO3400A MOSFETs for sensor and USB power switching
Battery monitoring: INA219AIDR over I2C
Connectivity: USB-A port (power only) for a 4G LTE dongle that creates a WiFi hotspot — one SIM serves the whole orchard

The MOSFET power switching is the critical piece for battery life. Sensors draw
40-80mA at 12V continuously. The 4G dongle draws 200-400mA when active. Both are
switched off during deep sleep. Only the LM2596S quiescent draw (~5-10mA) remains
between wake cycles.

The software stack

Firmware: ESP32 Arduino, Modbus RTU, deep sleep, OTA updates via Cloudflare R2 presigned URLs
Backend: Cloudflare Workers + D1 + KV + R2
AI layer: Claude dual-model stack (Haiku for fast auditing, Sonnet for deep agronomic analysis)
Firmware flashing: Browser-based via Web Serial API — no IDE, no drivers

Why RS-485 and not I2C or WiFi sensors

Cable runs in an orchard are 10-50 metres to the root zone. I2C degrades badly
beyond a few metres. WiFi sensors need their own power management and are
significantly more expensive. RS-485 handles 100m runs reliably at 4800 baud with
a simple twisted pair. Three terminal blocks wired in parallel means up to three
sensors per node sharing one bus.

The case study that proved the concept

One tree — we call it Pradyumna — was near-dead when monitoring began 300+ days
ago. Root zone EC was consistently high with no nocturnal drawdown (the signature
of a tree that isn't absorbing anything). The system guided a recovery protocol:
soil leaching, biological drench sequencing, fertigation timing aligned to the
first confirmed uptake windows. The tree is now in active flush with documented
fruit set.

That 300-day longitudinal dataset — every soil reading, every intervention, every
observed response — is what the intelligence layer is built on. The hardware is
commodity. The data is the moat.

Open hardware, proprietary intelligence

The Gerbers, BOM, and PickAndPlace are published at
sankhyafarms.com/open-hardware.html.
Anyone can order these boards from JLCPCB for under $10 for 5 pieces.

The intelligence layer — uptake index model, agronomic AI prescriptions,
longitudinal per-tree analysis — runs entirely server-side and is not open. The
hardware being open removes the adoption barrier without giving anything meaningful
away. Our moat is 300+ days of per-tree soil data that nobody else has.

What's next

Deploying 5 nodes across 5 irrigation zones. Adding solenoid valve control and
pump monitoring (amp draw via Tuya smart switch telemetry as irrigation ground
truth). Eventually: per-vine deployment in wine grape vineyards, which is where
this architecture scales most interestingly.

Hardware page with interactive component map: sankhyafarms.com/open-hardware.html

Happy to answer questions on the PCB design, the Modbus register maps, or the
Cloudflare Workers architecture.

DEV Community: Shaunak Sayta