THE MITTI TECHFarm-to-income intelligence
Join the pilot

Technical approach

Measure → Validate → Contextualise → Interpret → Recommend

Our rule: validate the measurement before relying on advice. AI and advisory must never mask measurement error. Software keeps raw measurement, processed value, validated result, derived estimate and advisory output separate at every layer.

Prototype in validation

(06) Engineering

Under the record, a serious stack.

Every answer above runs on four layers: the instrument in the field, a plot-level data platform, guidance grounded in approved sources, and the people who act on it.

  1. Measure
  2. Validate
  3. Contextualise
  4. Interpret
  5. Recommend

01 · Field instrument

ESP32-S3 platformBLE, low power, prototype
Sensor busesRS485/Modbus, I2C, SPI, UART
Offline loggingMicroSD, CRC checks
GNSS + clockPlace and time on every scan

02 · Data platform

BLE syncWhen connected, no duplicates
Soil Passport™Plot × season system of record
TraceabilityRaw, processed, estimate, advice kept apart
GIS / satellite / droneBoundaries and context (integration in progress)

03 · Intelligence

QC flagsEvery doubtful reading flagged
Approved-source guidanceKVK and expert documents
On-device inferenceTarget · in development
Mridā-AIInternal model · in development

04 · Ecosystem

Human reviewUncertain or high-stakes advice to a person
Experts · vetsHard cases
FPOs and programmesPlot-level reporting
Schemes · mandisWith source and date

Prototype architecture: every item above is a design requirement being checked through the validation gates.

Offline first

Built assuming rural network will fail.

Human review

Uncertain or high-stakes advice goes to a person.

Traceable

Every recommendation points back to its data.

Consent first

Farm data is recorded only with the farmer’s consent.

Read the technical approach

Firmware

Every scan follows one state machine.

  1. BOOT
  2. SELF TEST
  3. LOAD CALIBRATION
  4. START GNSS
  5. SAMPLE READY
  6. SCAN
  7. ACQUIRE
  8. FILTER / COMPENSATE
  9. QC
  10. CAPTURE GEO / TIME
  11. SAVE RAW
  12. SAVE PROCESSED
  13. DISPLAY
  14. OPTIONAL ADVISORY
  15. OPTIONAL BLE SYNC

Traceability

What every scan record must contain

This is a design requirement, not a performance claim.

  • scan_id, device_id, prototype_revision, PCB_revision, firmware_version, calibration_revision
  • timestamp_utc, time_source (GNSS / RTC), latitude, longitude, altitude if valid
  • GNSS fix type, satellite count, HDOP / estimated accuracy, GEO status
  • farmer_id, plot_id, sample_id, operator_id where available
  • raw sensor values for all channels and processed values for all reported parameters
  • sample temperature, ambient temperature / humidity, orientation / movement flag
  • QC flags, retest flag, error codes and operator notes

QC flags

  • SENSOR_TIMEOUT
  • OUT_OF_RANGE
  • REPEAT_FAIL
  • GEO_OK
  • GEO_LOW_ACCURACY
  • GEO_NO_FIX
  • TIME_GNSS_SYNCED
  • TIME_RTC_ONLY
  • WDT_RESET
  • UPDATE_ROLLBACK
  • LOG_CRC_FAIL

Engineering rules

The rules we do not bend.

N, P, K sensing principle
For each nutrient we document whether the value comes from ion-selective sensing, spectroscopy/colorimetry or a model-based estimate. Estimates are labelled as estimates everywhere.
pH front end
A glass pH electrode never connects directly to the MCU ADC; a dedicated very-high-input-impedance front end is required.
Temperature compensation
EC, pH and moisture compensation method, reference temperature and calibration revision recorded.
Location
Meter-class GNSS baseline. With no fix the scan is stored as GEO_NO_FIX; a stale or invented coordinate is never used. One scan is never presented as a field map.
Data integrity
Append-only records with CRC, partial writes rejected after power loss, watchdog recovery and firmware rollback.
Sync
Offline queue; repeated sync attempts never create duplicates; raw evidence is never overwritten.
AI guardrails
Guidance grounded in approved sources; model/rule version, confidence and a human review path. AI never invents measurement values, scheme eligibility or agronomic facts.
On-device AI
On-device inference with TFLite Micro is a feasibility target, not a guarantee. Mridā-AI is an internal project.

(07) Evidence

Evidence, not decoration.

MITTI SCANNER is a prototype. When each stage completes, we publish its method and result. Until then, we don’t print the number.

  1. G0

    Design review

    Sensing method, pH front end, power, sample procedure and test plan reviewed.

    In progress

What we will publish

Per-parameter results
After the 50-sample reference-lab comparison (G5)
Battery and runtime
After measured power testing
Field outcomes
After multi-season pilots

Company

  • The Mitti Tech Private Limited · Est. 2026
  • Lucknow, Uttar Pradesh
  • DPIIT-recognised startup · Certificate DIPP272273
  • StartInUP-recognised
  • Stage: prototype, validation in progress

50-sample comparison

Pass marks fixed before we see results.

The 50-sample set is an initial engineering validation, not a single headline percentage. Before testing we freeze the reference-lab method, sample-selection rule, per-parameter metrics (MAE, RMSE, bias) and acceptance thresholds. Failed runs are logged, never silently discarded.

Result table (filled after testing)

उदाहरण / Example
N
Not yet tested
P
Not yet tested
K
Not yet tested
pH
Not yet tested
EC
Not yet tested
Moisture
Not yet tested
Temperature
Not yet tested

Help build the validation

If you work in hardware, firmware, soil science, GIS or reference testing, get in touch.

Enquire about research collaborationfounder@themittitech.com