Your range is set by your lens.

Most vendors publish a detection range. A range is only true behind the optics it was measured with, and that configuration is almost never stated. So we publish the threshold instead: 8 px minimum resolved size, measured 13 Aug 2026 on the hardware named on the specification page. Below it the detector enters a statistical regime and most targets are missed.

This calculator turns that threshold into a distance for your configuration. It is textbook optics — you can check every number with a pencil, and you should. Nothing is collected before you see the answer.

Horizontal pixels 3840 for 4K, 1920 for 1080p, 640 for a common LWIR core.

Horizontal field of view (°) The narrower the lens, the further the floor moves out. This is the term that dominates the answer.

Target class Nominal spans, for orientation. Use the real figure if you have it.

Target span (m) The dimension that faces the sensor — usually the widest.

Target speed (m/s) Used only for frames-on-target. 30 m/s is roughly 108 km/h.

— enter your sensor and target

—instantaneous field of view per pixel —range at 16 px — one doubling of margin above the cliff —observations on a target crossing the full field at 5.76 FPS — independent of your lens, see below —resulting horizontal field of view

Target extent in pixels, by range
Range	Target extent	Against the 8 px floor

Read this as a ceiling, not as a detection range. The target reaches the 8 px floor at the distance above; effective detection will be shorter, and depends on contrast, atmosphere, target motion and how cluttered the background is. Below the floor the detector enters a statistical regime and most targets are missed. The floor itself was measured on the hardware named on the specification page, on 13 Aug 2026. Correlation against surveyed truth in the field has not been done yet, and it will be published measured, whatever it shows. Nothing on this page is a claim about our software — the ceiling is the same for any detector behind those optics.

ifov_rad = (hfov_deg × π / 180) / horizontal_pixels ifov_rad = pixel_pitch_µm / (focal_length_mm × 1000) ← from a sensor datasheet R_max_m = target_span_m / (8 × ifov_rad) frames = 5.76 × hfov_rad × R / target_speed_m_per_s

One result worth pausing on: frames-on-target does not change when you change the lens. Narrowing the field pushes the floor further out, and the target crosses the narrower field proportionally faster — the two cancel exactly. A longer lens buys you distance and detail per pixel; it does not buy you more looks at a crossing target. More looks come from frame rate, from a second node, or from the target flying towards you rather than across.

Callable

The same function, over HTTP.

Public, unauthenticated, CORS open. It is arithmetic; there is nothing here to protect. If you are wiring an assistant or a sizing tool, call it directly rather than scraping the page.

GET /api/detection-geometry?px=3840&hfov_deg=30&span_m=0.35&speed_ms=30
GET /api/detection-geometry?focal_mm=25&pitch_um=12&px=640&span_m=2.5

{
  "pixel_floor_px": 8,
  "ifov_urad": 136.4,
  "r_max_m": 321,
  "r_16px_m": 160,
  "frames_on_target": 32,
  "caveat": "Geometric ceiling, not a detection range. ..."
}

Machine description at /openapi.json.

Want the full geometry report for this configuration? We'll send you the threshold sweep, frames-on-target across the engagement, and the exact method note behind the 8 px figure. No automated spam. Just engineer to engineer.

Request the full report