Pointed and pushbroom sensors

What you will accomplish

A coverage result that reflects the payload you are flying, rather than the geometric horizon.

The default coverage analysis asks whether a satellite is above the elevation mask from a ground point. That is the right question for a communications terminal, which can point anywhere in its hemisphere. It is the wrong question for an imager, which sees only where its aperture is aimed.

Prerequisites

A constellation.
Coverage and revisit for the convergence discipline this guide assumes.

Steps

Measure the horizon-limited baseline


orbitforge coverage --constellation ph1.json \
  --duration-hours 6 --step-seconds 120 --grid-deg 10 \
  --min-elevation-deg 10


  mean coverage 70.1% (area-weighted), min 0.0%, fully covered 10.8%, any 68.4%
  max fold 3, max coverage gap 5760 s

Constrain it to a real aperture


orbitforge coverage --constellation ph1.json \
  --duration-hours 6 --step-seconds 120 --grid-deg 10 \
  --min-elevation-deg 10 \
  --sensor-shape conical --sensor-cone-deg 45


  mean coverage 12.3% (area-weighted), min 0.0%, fully covered 0.0%, any 57.9%
  max fold 2, max coverage gap 11760 s

What just happened

Mean coverage fell from 70.1 percent to 12.3 percent. Nothing about the orbits changed.

The first number was never a claim about the payload. It says the satellite was above 10 degrees elevation, which for a 45-degree half-angle nadir sensor is true for most of the time the ground point is nowhere near the footprint.

Quoting horizon-limited coverage for an imaging mission overstates it here by a factor of roughly six.

The elevation mask and the sensor cone are both applied, and they answer different questions. The mask is a constraint at the ground point, usually terrain or atmosphere. The cone is a constraint at the spacecraft.

The shapes

Shape	Flags	Represents
Line of sight	none	A steerable communications terminal
`conical`	`--sensor-cone-deg`	A circular field of view
`rectangular`	`--sensor-along-deg`, `--sensor-cross-deg`	A framing or pushbroom imager

A pushbroom is a rectangle that is very narrow along track and wide across it:


orbitforge coverage --constellation ph1.json \
  --duration-hours 6 --step-seconds 120 --grid-deg 10 \
  --min-elevation-deg 10 \
  --sensor-shape rectangular --sensor-along-deg 2 --sensor-cross-deg 30


  mean coverage 0.3% (area-weighted), min 0.0%, fully covered 0.0%, any 18.7%
  max fold 1, max coverage gap 4080 s

A narrower sensor reported a better gap. It is not better.

Read those three runs in order and one column moves the wrong way:

Sensor	Mean coverage	Any coverage	Max gap
Line of sight	70.1%	68.4%	5760 s
Conical 45 deg	12.3%	57.9%	11760 s
Pushbroom 2 x 30	0.3%	18.7%	4080 s

The pushbroom sees almost nothing, yet its maximum gap is the shortest of the three.

This is a property of the statistic, not of the sensor.

The maximum gap counts only internal gaps, meaning intervals bounded by coverage on both sides. A grid point that is never covered contributes no gap at all, because an unbounded outage is not a revisit interval and reporting one would be arbitrary.

That definition is the correct one. But it means the gap statistic is computed over a shrinking population as the sensor narrows. With the pushbroom, 81 percent of grid points are never seen and are silently excluded from the number.

The gap figure is conditional on being covered at all. Read it only alongside any coverage, which is the fraction of grid points the sensor ever saw:

Line of sight: a 5760 s gap across 68.4 percent of points.
Pushbroom: a 4080 s gap across 18.7 percent of points, and no revisit information whatsoever about the other 81.3 percent.

Quoting “maximum revisit gap 4080 s” for the pushbroom is technically accurate and operationally meaningless.

Off-nadir pointing

A body-pointed or gimballed sensor is modeled with a roll offset:


orbitforge coverage --constellation ph1.json \
  --duration-hours 6 --step-seconds 120 --grid-deg 10 \
  --min-elevation-deg 10 \
  --sensor-shape conical --sensor-cone-deg 45 --sensor-roll-deg 20


  mean coverage 23.7% (area-weighted), min 0.0%, fully covered 0.0%, any 63.2%
  max fold 2, max coverage gap 9960 s

Rolling 20 degrees nearly doubles mean coverage, from 12.3 to 23.7 percent, and cuts the gap from 11760 s to 9960 s.

This models a fixed roll held for the whole window, not an agile sensor that slews per target. A real tasked spacecraft points where the schedule sends it, so treat this as the coverage available at one standing attitude rather than as the capability of a steerable payload.

Off-nadir viewing also costs resolution and increases atmospheric path length. Neither is modeled here.

Choosing the numbers

The sensor angles are half-angles from boresight. Deriving them:

Circular aperture. Half-angle is half the full field of view.
Pushbroom. Along-track is the detector’s instantaneous footprint, often under a degree. Cross-track is the swath.
Swath to angle. For a swath width w at altitude h, the nadir half-angle is approximately atan(w / 2h), ignoring Earth curvature. Curvature makes the true angle smaller than that estimate, so it is mildly conservative.

The constellation file also carries a payload.fov_deg. That is metadata; the coverage analysis uses the flags you pass on the command line. If they disagree, the flags win and nothing warns you.

Checklist

Did you state the sensor, or accept the horizon by default?
Is any coverage high enough for the gap statistic to mean anything?
Are you quoting a mean over the whole grid when the mission cares about one region?
Did you converge the grid, as in Coverage and revisit? A sensor-limited run has a smaller footprint and needs a finer grid to resolve it.

Point 4 matters more than it looks. A footprint that spans less than one grid cell is a footprint the grid cannot see.

Next steps

coverage reference for the full flag set.
Access windows and pointing for per-pass geometry rather than aggregate coverage.

Question? Give us feedbackDocuments Varaha Constellation Designer main (pre-release)