Your first analysis

What you will accomplish

You will take the constellation from the quick start and answer the two questions that decide whether a design is viable: how much of the Earth it sees, and whether it can actually talk to the ground.

More usefully, you will see a design that looks fine on a globe fail its link budget, which is the normal outcome of a first attempt.

Prerequisites

Installation complete.
demo.json from the quick start, a 60-satellite Walker Delta at 550 km and 53 degrees.

Steps

Measure coverage

Coverage asks: standing at a given point on Earth, is at least one satellite visible above the horizon mask?


orbitforge coverage \
  --constellation demo.json \
  --duration-hours 6 --step-seconds 60 \
  --grid-deg 10


Coverage over 684 grid points (10 deg), 60 sats, 6.0 h at 60 s:
  mean coverage 70.2% (area-weighted), min 0.0%, fully covered 10.5%, any 68.4%
  max fold 3, max coverage gap 5760 s

Read what it says

Each number answers a different question, and the headline figure is the least interesting one.

Figure	Value	What it means
Grid points	684	Sample points at 10-degree spacing. Finer grids cost time
Mean coverage	70.2 percent	Area-weighted average fraction of time a point is covered
Min	0.0 percent	At least one point was never covered in the whole window
Fully covered	10.5 percent	Fraction of points covered for the entire window
Any	68.4 percent	Fraction of points covered at least once
Max fold	3	The most satellites simultaneously visible from any one point
Max coverage gap	5760 s	The longest a covered point went unseen, 96 minutes

A mean of 70 percent with a minimum of 0 percent is the signature of a design with structural holes, not a design with occasional outages. At 53 degrees inclination the satellites never fly over the poles, so polar grid points are never covered by anything. Averages hide that; the minimum reveals it.

The 5760-second gap is close to one orbital period, which tells you that covered points are typically waiting for the same satellite to come around again rather than being handed to a different one.

Close the link

Coverage says a satellite is above the horizon. It says nothing about whether enough signal arrives to be useful. That is the link budget.


orbitforge link \
  --constellation demo.json \
  --station "Madrid,40.43,-3.7,0.6" \
  --frequency-ghz 20 \
  --availability 99.9 \
  --climate-zone K


Link analysis: 60 satellites, 1 stations, 6.0 h at 60 s (20.0 GHz).
  madrid: coverage 100.0%, 92 contacts, best margin 4.6 dB
  Madrid link availability: does not close at 95%

Interpreting the result

This is the interesting part, and it is why the page exists.

Madrid has 100 percent coverage and 92 contacts in six hours. Geometrically the constellation is excellent over Spain. Yet the last line says the link does not close at 95 percent availability, which is a weaker target than the 99.9 percent that was asked for.

Both statements are true at once, and the reason is that coverage and link closure are different questions:

Coverage is geometry. Is a satellite above the elevation mask?
Link closure is energy. Does enough signal survive the path, at the worst geometry in the pass, through the worst weather permitted by the availability target?

The best margin across the window is 4.6 dB, and that is the best case: the highest-elevation moment of the best pass, in the calmest atmosphere. At the edges of a pass the slant range is far longer, and at 20 GHz rain attenuation in climate zone K is severe. Those two together consume more than 4.6 dB.

A design that reports high coverage and fails its link budget is not broken. It is telling you that the constraint is RF, not geometry. Adding satellites will not fix it. More transmit power, a larger antenna, a lower frequency, a higher elevation mask, or a lower availability target might.

What to try next

Each of these changes one variable, so you can see which constraint actually binds:


# Lower frequency: less rain attenuation, but less bandwidth available.
orbitforge link --constellation demo.json \
  --station "Madrid,40.43,-3.7,0.6" \
  --frequency-ghz 12 --availability 99.9 --climate-zone K
 
# Relax availability: accept more outage per year.
orbitforge link --constellation demo.json \
  --station "Madrid,40.43,-3.7,0.6" \
  --frequency-ghz 20 --availability 99.0 --climate-zone K

Run orbitforge link --help for the transmit power, antenna, and elevation-mask options that let you change the spacecraft rather than the requirement.

Troubleshooting

Symptom	Cause	Fix
`unexpected argument '--grid-step-deg'`	The flag is `--grid-deg`	The CLI suggests the closest match; read its tip
Coverage reports 0 grid points	`--grid-deg` too coarse for the region	Reduce the spacing
Link reports 0 contacts	Station outside any ground track, or elevation mask too high	Check the station latitude against the inclination
Analysis takes minutes	Debug build, fine grid, or long duration	Build with `--release`, coarsen the grid, or shorten the window

Next steps

Link budgets for why the margin came out where it did.
Accuracy and limitations before you put any of this in a review.

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