Skip to content

This site is new and updates oftenLast updated Sep 25, 2026, 11:47 AM

Coding

Farm of the Future

IoT data infrastructure for CAST, Cornell CALS' data-driven agriculture testbed.

cals.cornell.edu/cast-farm-future

Diagram of CAST's three farms - Cornell University Ruminant Center, Cornell Teaching Dairy Barn, and Musgrave Research Farm - and its stakeholder network
CAST's three farms and stakeholder network, from the CAST team's own materials.

Problem

Every barn and field at CAST already produces data - just not in one place or one shape. Collar sensors like SmaxTec and SilentHerdsman report activity and rumination continuously; parlor systems like AfiFarm log milk yield, fat, and protein per milking; herd-management software like DairyComp 305 holds lactation history and health events. Each source has its own units, its own collection frequency - continuous, per-session, per-lactation - and its own server, cloud or local. None of it arrives pre-joined.

The field side adds another layer: soil maps sampled once a season, yield maps from the combine, and satellite imagery (Landsat, Sentinel-2, Planet) at resolutions from 30 meters down to 3, refreshed anywhere from daily to every couple of weeks. Reconciling a per-second cow sensor reading with a once-a-season soil sample is a genuinely different problem than reconciling two dairy vendors' APIs with each other.

System design & approach

CAST - the Cornell Agricultural Systems Testbed and Demonstration Site - runs across three Cornell-operated farms in New York: the Cornell University Ruminant Center in Harford, the Cornell Teaching Dairy Barn in Ithaca, and Musgrave Research Farm in Aurora, with CAST-NET, its extension network, bringing in farmers, equipment manufacturers, consultants, and academic experts at every stage. I built the pipeline that turns those streams into something usable: piping live IoT sensor readings into Postgres, a React dashboard that surfaces gaps and spikes as they happen instead of after a report runs, and lightweight models that catch flaky sensors before a bad reading gets treated as real data.

My role

The pipeline above is mine end to end. It feeds decision-support and predictive tools other researchers on the team build - like MyCow$ (real-time cash flow per cow) and RuFaS - which I didn't build myself, but which depend on it being correct.

Retrospective

That infrastructure supports two research thrusts: precision management on the crop side - input rates, cover cropping, soil amendments like biochar for carbon sequestration - and precision animal management on the dairy side - feeding, health, and reproductive monitoring. Both are aimed at testing technology under real commercial-farm conditions instead of a controlled lab, then extending what works through CAST-NET.

Reconciling streams that arrive at wildly different paces into one pipeline other people's tools can depend on, and building lightweight anomaly detection so a flaky sensor doesn't quietly corrupt a model several steps downstream from where I was working.

Mohammad Labadi with the CAST research group
With the CAST research group.
Dairy cows at CAST's freestall barn
Dairy cows at CAST's barn, on-site.
A tagged dairy cow at CAST, photo via Cornell CALS
Via Cornell CALS / CAST.
  • AWS
  • React
  • PostgreSQL
  • scikit-learn

Back to Coding