Survey guidance for accurate locates

Cell Locator matches live cellular measurements against a geo-tagged RF
survey. Locate quality is dominated by how that survey was collected — not by
the estimator alone. Unsurveyed or poorly surveyed areas produce large errors
and low confidence by design.

This note is for teams building or extending a reference survey (drive tests,
learn mode, or paid coverage packs).

---

What the survey must capture

Each survey sample should be a full scan at one place and time:

Serving timing advance is especially valuable: later methods gate and weight
matches using TA. Neighbour TA is unreliable and is not used the same way — do
not invent it.

Use the standard cellscan CSV column set (same as the Android app / RPi client).

---

How to drive (or walk) the survey

1. Cover the routes you will locate on. Fingerprints are local. A locate on
   an unsurveyed road or parallel corridor will not magically snap to the
   nearest surveyed street.
2. Prefer the operational network and bands your devices will use in
   production (same operators / SIMs where practical). A survey on operator A
   does little for queries that only hear operator B.
3. Keep GNSS healthy while surveying. Open sky or light urban canyon is
   fine; underground, deep indoor, or multi-level car parks corrupt the map.
   Pause learn / logging when GPS accuracy is poor.
4. Sample densely along the path, not once per kilometre. Overlap and
   repeated passes help; the engine already thins extreme duplication. Aim for
   continuous logging (e.g. every few seconds while moving), not sparse
   waypoints.
5. Drive both directions and major junctions where traffic will later
   locate. One-way passes leave asymmetric gaps at turns and slip roads.
6. Capture neighbours, not only the serving cell. Rich neighbour sets make
   fingerprints more distinctive and reduce km-scale ambiguity.
7. Stay on the geometry you care about. Road-centreline surveys work for
   road locates; if you need car parks, campuses, or footpaths, survey those
   surfaces explicitly.
8. Re-survey after network change. New sites, retunes, and sector rehome
   change PCI/ARFCN/TA behaviour. Plan refresh for corridors that matter.

---

Quality checks before you trust the map

• GPS filter: drop or avoid ingesting rows with accuracy worse than ~25–30 m.
• Identity sanity: reject placeholder / sentinel values (MCC 0, CID 0,
  ARFCN 65535, Java Integer.MAX_VALUE signal/TA).
• Serving TA present on LTE rows wherever the modem/phone provides it.
• Coverage vs roads: plot survey traces on the target road network; fill
  gaps on tertiary-and-higher links you expect to locate on.
• Hold-out test: keep a later drive (or alternate pass) out of the
  reference; run locate against it and check median error, p90, and honesty
  (error ≤ claimed accuracy_m). Do not score only on roads you just
  surveyed in the same file.
• TA sanity (optional): where known eNodeB sites exist, check that
  reported TA is plausible for distance-to-site.

---

Learn mode vs dedicated survey

Learn is a supplement, not a substitute for an initial corridor survey. Do not
enable learn indoors or with a bad fix — bad truth poisons the reference.

---

What “good enough” looks like

On well-surveyed roads, expect typical errors in the low hundreds of
metres, with an honest accuracy radius and confidence on each fix. That is
coarse complementary PNT, not lane-level GNSS.

If locates are poor:

1. Is the query geography actually in the survey?
2. Are serving + neighbours present (not serving-only)?
3. Was the survey GNSS accurate?
4. Has the live network drifted since the survey date?

Coverage is part of the product. Expanding or refreshing the survey is usually
the highest-leverage fix.