Field App

The whole job, on a mid-range Android, with no signal

Six lifecycle visits to one plot, captured by a technician covering 150 to 200 farmers across villages with no connectivity and no external GPS. This is that app, running: the walk is the engine's seeded GNSS simulation, the area and the error band are computed from the fixes on screen, and a saved capture is a real row in IndexedDB that survives a reload.

The reframe the product rests on: multi-stage capture is not a burden imposed on the technician, it is the error-reduction mechanism. Six independent observations of one boundary, plus the edges it shares with neighbours in the same Club, reconcile to something far tighter than any single walk can be.

12.5% to 1.8%

Mean absolute area error, one walk against six plus topology

Generator Monte Carlo, 4,000 trials on a 0.5 acre square with 4 independent vertices, 7.1x reduction. The Problem tab quotes one sigma from the engine's correlated-track model instead, which is why it reads a little differently.

Rs 3,756 to Rs 528

Disputed value per settlement on that plot

At Rs 60,000 an acre, with no external hardware

10.1% vs 5.7%

Measured mean absolute error, single against dual frequency

Across 954 simulated captures in this world

43 captures

Still sitting on handsets at the world clock

Median lag 88 h, worst 43 days

14 Mar 09:30no serviceL1

Srikanth B.2026-03-14

Today

2

Clubs

Cross Road, North

24

Plots to visit

33 stage slots open

Before you leave

Club data on handsetReady

Pre-loaded sizeFarmers, plots and boundaries for today82.4 KB

Capture historyFetched per plot, not carried in the day bundleLoaded on demand

Queue waitingSession memory only0 ops

100%

Storage is not durable

This browser refused IndexedDB, so the queue is held in memory for this session only. In the field that would mean a closed app loses the walk.

Clubs

Day order is derived from open stage slots, not from a calendar. The season is closed and the settlement window is open, so a plot missing a stage is a plot that cannot be settled.

In the field - no connectivity · Synthetic fixture world

Screen 1 of the stack

Screen 1 · Daily plan

Everything needed today is on the handset before leaving, measured in bytes. Day order comes from open stage slots, not a calendar.

Who is holding the phone

Switching technician switches handset. Every tolerance, expected error and acceptance band on the capture screens is recomputed from that handset, so the dual-frequency case is made by using it rather than by claiming it. Srikanth B. is on Mid Android (2021 class), L1.

Conditions

Where the technician is

Models field connectivity. The browser itself stays online, and no screen claims otherwise.

GNSS condition

Blocks or qualifies a capture on the start and walk screens.

Every screen

Plan the day

Find the plot

Capture

Offline and sync

When it goes wrong

What is real in here

The walksimulateGpsWalk from the engine: samples along the true boundary every 2.5 m, an AR(1) error chain decorrelating over 7 m, at the sigma this handset gets under this stage's canopy in this village. Seeded, so the same plot walks the same way every time.
Every numberArea is the shoelace area of the recorded fixes. The band is the engine closed-form area variance on those same points. Tolerances, value at risk and marginal gain are engine calls, not constants in the copy.
The queueA real IndexedDB write-ahead log with gap-free sequence numbers allocated inside the write transaction. Captures survive a reload; the session counter on the queue screen is the proof.
The syncA real POST to /api/traverse/sync. Whatever it answers is shown as it came back, including whether a database wrote anything or the route fell back to fixtures.
The conflictFound by the queue's own local detector with no connectivity: two unsynced captures on one plot and stage from two technicians. The second walk is a second real simulation, so the areas differ by physics.
Real GNSSOptional and clearly labelled. If this browser gives a position, the capture uses it and every screen says so, including the payload written to the queue.

Honesty

SYNTHETIC DATA. Every company, village, club, farmer, plot boundary, capture, contract, rate and settlement in this file is fabricated for a product study. No real person, holding or agreement is represented. District and state names are real Indian administrative names used only to anchor the belt; village centroids are approximate synthetic points inside it and do not correspond to any actual settlement.

Every GNSS fix in this app is simulated unless the screen says otherwise, and a simulated capture carries its seed everywhere it goes, including into the payload written to the queue. If a browser will give a real position, the capture can use it, and it is labelled as a device fix from the walk screen through to the stored op. The satellite figures the wider study uses are study inputs, not outputs of this app.