# Target Location Error (TLE)

When two independent measurements of the same target disagree, the difference between them is the **Target Location Error (TLE)**. In test-pilot work this is the canonical accuracy metric — survey-truth versus sensor estimate, designated coordinate versus what the inertial system reports, target-truth versus weapon impact. The standard process is always the same four steps:

1. Express both measurements in latitude, longitude, and height (LLH).
2. Convert each to Earth-Centered Earth-Fixed (ECEF) coordinates.
3. Subtract in ECEF, then rotate the difference into a local North-East-Down (NED) frame anchored at the truth point.
4. Reduce to two operational scalars: $e_H = \sqrt{e_N^2 + e_E^2}$ (horizontal) and $e_V = |e_D|$ (vertical).

The math chain is the same regardless of where on Earth the scenario is, but the *meaning* of a given LLH offset is not — a one-arcsecond longitude error produces about 30 m of east error at the equator, 15 m at 60° latitude, and barely a meter near the pole. The cos(latitude) factor is one of the central facts to internalize from this demo.

## Why not just subtract LLH directly?

Tempting, but wrong. Latitude and longitude are *angles*, not distances, and a degree of longitude shrinks toward zero as you approach the poles while a degree of latitude is roughly the same everywhere. The conversion through ECEF and back into NED is what bakes the WGS-84 ellipsoid geometry into the answer. The DCM $\mathbf{C}_e^n$ at the truth point turns the metric ECEF difference into a meaningful local horizontal/vertical decomposition.

## Interactive demo

<a class="demo-fullscreen" href="../_static/demos/TargetLocationError.html" target="_blank" rel="noopener">Open in full screen</a>

<div class="demo-wrap">
<iframe src="../_static/demos/TargetLocationError.html"
        title="Interactive Target Location Error demo"
        width="100%"
        loading="lazy">
</iframe>
</div>

## Walkthrough

The demo opens at the **Edwards default** scenario — Edwards AFB at $34.92°\text{N}, 117.90°\text{W}$, with a small simulated sensor error of about 30 microdegrees of latitude, 20 microdegrees of longitude, and 6 m of altitude. Try the following:

1. **Read the headline metrics.** $e_H \approx 3.80$ m, $e_V = 6.000$ m. Open the **Conversion chain** panel at the bottom to see the four steps explicitly: each LLH converted to ECEF, the dECEF difference, the $\mathbf{C}_e^n$ matrix evaluated at truth, and the resulting NED.
2. **Drag the orange E pin in the NE plot.** This sets the sensor location graphically; the Sensor LLH inputs update live to whatever LLH gives that NED offset. Use the zoom chips above the plot to pick a sensible scale; the zoom doesn't auto-change while you drag, so the cursor and the pin stay locked together.
3. **Try each scenario chip.** "Lat error only" applies a 1-arcsecond latitude offset and produces $e_N \approx 30.8$ m, $e_E \approx 0$ at the latitude of Edwards. "Lon error only" gives $e_E \approx 25.3$ m, $e_N \approx 0$ — fewer meters per arcsecond because $\cos(34.9°) \approx 0.82$. "Alt error only" gives $e_H = 0$, $e_V = 10$ m.
4. **Run the cos(lat) experiment.** With "Lon error only" loaded, slide the **truth latitude slider** from $-85°$ to $+85°$. Both pins translate together — the same arcsecond of longitude offset stays applied — but the metric east-error changes dramatically. Watch the curve at the bottom: $e_H$ traces $\cos(\phi)$, peaking near the equator and falling toward zero at the poles. Meanwhile $e_V$ stays flat — vertical doesn't care about latitude. The dot on the curve marks the current state.
5. **Run the same sweep with "Lat error only."** Now $e_H$ stays nearly constant across all latitudes; the small variation comes from the WGS-84 ellipsoid (the meridian radius of curvature isn't quite constant). **Latitude offsets translate to north-error roughly the same way everywhere on Earth; longitude offsets do not.** That asymmetry is the headline.
6. **Edit the LLH inputs directly.** The two LLH coordinates are the primary inputs to the chain — everything else (NE plot, altitude view, conversion chain readout) is derived from them. The Δ row beneath the inputs shows the offset in arcseconds, plus a per-arcsecond sensitivity readout for the current truth latitude.

## Key observations

- **Arcseconds are the right operational unit for LLH offsets.** A degree is huge ($\approx 111$ km), a microdegree is awkward, an arcsecond is roughly 30 m everywhere — close to the precision of GPS-grade civilian equipment. The Δ readout uses arcseconds for that reason.
- **$e_V$ is essentially $|\Delta h|$.** The vertical chain has very little geometric machinery; altitude offsets pass through almost untouched. All the geometric subtlety of TLE lives in the horizontal channel.
- **Same arcsecond, different meters.** A test point at the equator and the same test point at $80°\text{N}$ produce wildly different $e_E$ values for the same $\Delta\text{lon}$. Test programs at high or low latitudes need to factor the cos(lat) effect into measurement-precision requirements.
- **The $\mathbf{C}_e^n$ matrix at truth depends only on the truth latitude and longitude**, not on the sensor offset. That's why the chain evaluates it once at the truth point and reuses it.

## Source

<a class="matlab-link" href="../_static/downloads/SY6301%20Navigation%20and%20State%20Estimation%20%E2%80%93%20Code.zip#code/TargetLocationError.m" download><svg viewBox="0 0 22 22" width="14" height="14" aria-hidden="true" style="vertical-align:-2px;margin-right:6px;"><rect width="22" height="22" rx="3" fill="#e87722"/><text x="11" y="15.5" text-anchor="middle" font-family="'Inter',sans-serif" font-size="9" font-weight="800" fill="#fff" letter-spacing="-0.04em">MAT</text></svg><span class="ml-text">MATLAB · code/TargetLocationError.m</span><span class="ml-arrow">↓</span></a>

With the LLH↔ECEF and ECEF↔NED utilities in `code/navutils/`.