Sensor coverage predictions are computed from numbers describing where the sensor is and which way it is pointing. Some of those numbers are measured. Others are typed into a form by whoever did the install, on a day when getting the system online mattered more than getting the survey right. The prediction cannot tell the difference, and neither can the operator reading it three months later. This is an argument that emplacement metadata deserves the same scepticism you apply to the detections themselves.
Four numbers, and how each one goes wrong
A radar, an RF direction-finder, an acoustic array, or an electro-optical sensor all need roughly the same four facts before their output means anything in the world rather than relative to themselves: where they are, how high above the ground, which way true north is, and what time it is. Every one of those has a characteristic failure mode.
1. Altitude, and the datum nobody agreed on
This is the one that quietly ruins more tracks than any other, because two systems can both be correct and still disagree by tens of metres.
"Altitude" means at least three different things in practice. Height above the WGS-84 ellipsoid (HAE) is a geometric surface — what a GNSS receiver natively computes. Height above mean sea level (MSL) is referenced to the geoid, an equipotential surface that follows the Earth's actual gravity field. And a barometric flight level is neither of those; it is a pressure measurement.
The two are related by the geoid separation, N:
In the continental United States N runs roughly −16 to −37 metres, which means HAE is consistently less than MSL. Treat an MSL height as if it were ellipsoidal, or the reverse, and you have introduced an error of that size — silently, with no indication anything is wrong.
This is not hypothetical, and it is not confined to obscure formats. The ASTERIX standards used across surveillance radar do not agree with each other internally: CAT048 supplies an MSL 3D height when the radar is 3D, and a barometric flight level otherwise, while CAT062 carries WGS-84 ellipsoidal height. A system ingesting both, treating altitude as one undifferentiated field, is mixing three reference surfaces in the same track table.
Thirty metres of vertical error is the difference between an aircraft at low altitude and one on the ground. It is enough to put a track on the wrong side of a floor in an airspace restriction, and enough to make a coverage prediction confidently wrong about whether terrain masks a sensor.
2. Height above ground, which is usually a guess
Sensor height above ground level drives every line-of-sight and propagation calculation. It is also the number most likely to have been estimated by eye. A mast is "about ten metres." A rooftop install is "roughly building height." Nobody measures it, because measuring it properly requires an instrument nobody brought.
Line-of-sight range over terrain scales with the square root of antenna height, so the error is forgiving at first and then is not: the difference between an assumed ten metres and an actual six is a materially smaller coverage footprint than the one in the plan.
3. True heading, assumed rather than measured
For any directional sensor, bearing accuracy is capped by how well you know which way the sensor is facing. Two independent problems live here.
The first is magnetic declination — the angle between magnetic and true north, which varies by location, changes over time, and reaches double digits in degrees across much of the United States. A heading taken with a compass and not corrected is wrong by that amount, and every bearing the sensor reports inherits the error.
The second is subtler and survives even on sensors that determine true heading themselves using dual-antenna GNSS interferometry. Those systems compute heading correctly and can still be misaligned in practice: the antenna baseline may not be parallel to the axis the software assumes, a mounting offset may have been misconfigured at install, a display may be in heading-up rather than north-up mode, GNSS multipath in an urban setting can corrupt the solution, and mast vibration can shift a mounting offset over months.
None of those produce an error message. Every track is simply rotated, consistently, by an amount nothing downstream can detect — because a uniform rotation still looks entirely plausible.
4. Time, which everyone assumes is fine
Multi-sensor fusion is arithmetic on timestamps. If two sensors disagree about when an observation happened, correlating them produces a track that never existed, or fails to correlate two views of something that did. This is the failure mode that most resembles a software bug, and it is why a disciplined hardware timing reference on a wire remains a real requirement rather than a legacy one.
What you can do about it today
The reason to enumerate these carefully is that three of the four are addressable in software you can already deploy, and the fixes share a design principle: measure where you can, declare what you cannot, and never silently resolve a disagreement.
Reconcile altitude at the boundary, per input
AtlasBridge normalises altitude as detections enter the system rather than hoping every sensor agrees. Each input declares its own altitude datum. An MSL-referenced input is converted using the geoid separation for the site; an ellipsoidal input passes through; a barometric flight level is recognised as neither and not pretended into one.
The geoid separation itself can come from a surveyed value or from a connected GNSS receiver's own position solution — and where both exist, the design decision worth stealing is this: the surveyed value wins, because it is an operator statement about a specific site, while the receiver's figure comes from its own coarse internal model. When the two disagree by more than two metres, the console reports the divergence rather than picking a winner quietly.
That two-metre threshold is set deliberately above measured model disagreement. On a bench receiver in the mid-Atlantic, the receiver's internal model reported a separation of −34.50 m where the EGM96 five-arcminute grid gives −33.22 m — a 1.28 m difference against a correction of about 34.5 m. Two lessons sit in that one measurement. The correction is large and skipping it costs you tens of metres. And the residual disagreement between reasonable geoid models is on the order of a metre, which is what the tolerance has to accommodate.
The conservative behaviour matters as much as the arithmetic: an input declared MSL with no separation available is passed through unchanged rather than shifted by a guessed offset. A wrong correction is worse than an acknowledged gap.
Verify heading against known truth
GridDown Maps includes a survey-style alignment check for any directional sensor that reports bearing and range. You pick landmarks you can identify, it computes the true bearing and range from the sensor's surveyed position, you enter what the sensor reported for the same landmarks, and it returns per-landmark discrepancies plus a multi-landmark consistency analysis.
The consistency analysis is the useful part, because it separates a constant mounting offset — every landmark off by the same amount, which is correctable — from scatter, which indicates something else. For sensors that do not self-align, this is the primary alignment mechanism rather than a check on one. For sensors that do, it is how you find out that a correctly computed heading is being applied to a baseline that is not where the software thinks it is.
Prefer a measured position to a typed one
The same principle shows up in the GridDown Sensor Hub. A fixed install can have its coordinates entered by hand, and for a permanent emplacement with no receiver that is the right answer. But a connected GNSS receiver, or a tablet pushing its own position, automatically overrides the typed value — because a measurement, even an imperfect one, beats a number somebody remembered to update.
The uncomfortable question
Take a coverage prediction you rely on and ask, of each of the four numbers underneath it, whether it was measured or asserted. Ask when it was last checked. Ask whether anything in the chain would tell you if it had drifted.
For most emplacements the honest answers are: asserted, at install, and no. That is not incompetence; it is a consequence of these being the least interesting numbers in the system, entered under time pressure, by people whose actual job was getting the sensor working. They are also the numbers everything downstream is silently multiplied by.
The fix is not more precision for its own sake. It is knowing which of your four facts are measured, which are assumed, and how much your prediction depends on the difference — and having systems that report a disagreement instead of resolving it behind your back.
BlackAtlas is also developing a dedicated instrument for this problem, called AnchorDatum, intended to measure all four facts at an emplacement and stream them over interfaces that already exist. It is a validated concept in active development rather than a shipping product, and its published figures are component specifications rather than measured system results. The software layer described above is being built regardless of the hardware outcome, because it improves products already in the field.
Normalise It at the Boundary
AtlasBridge reconciles altitude datums, reports geoid disagreement instead of hiding it, and translates sensor detections into the command-and-control systems you already run.
Explore AtlasBridge