Terminus: rings over twilight

Proposal section 4: the fleet

Ride along with one of our satellites for an orbit. It crests the north pole and falls down the night side, two hours of frozen blackness scrolling below, no lights, no one to serve. Then a thin red line rises over the horizon — the twilight band, glowing with the scattered lamps of every town on the planet — and for a quarter of an hour the satellite is working, relaying a thousand conversations, before the band slides behind it and the day side's empty glare takes over. Around the bottom of the world and back up into darkness. A satellite here spends most of its life commuting and a sliver of it on shift.

This section decides how many such commuters we need, and on which roads. The survey gave us the shelf menu; the trap taught us the rings must stay fixed among the stars while the band sweeps past them. Now we lay actual rings in the actual sky — and then, because the RFP demands evidence rather than confidence, we simulate every town on the planet for a full rotation and see whether our first design holds.

It will not. That is what simulations are for.

Why the rings run pole to pole

The twilight band is the line where day meets night, and that line has a useful property: it passes through both poles. Day and night each claim half the planet, and the frontier between them runs top to bottom, like the seam on a two-colored ball. So a satellite ring that also runs pole to pole — a polar orbit — can lie right along the band. Tilted rings would cross the band at an angle, wasting their arc on day and night country; polar rings can spend their whole circle near the line.

But the lesson of the trap never sleeps: the rings are pinned to the stars, and the line turns with the planet — 32 degrees per day. One perfectly placed polar ring drifts out of alignment within hours. So we do not build one ring. We build a wheel of them: six polar rings, their planes fanned evenly like spokes, 30 degrees apart. As the planet turns, the line rotates from one spoke to the next, and the next ring inherits the duty:

• every 22.4 hours (30° at 32.14°/day), the "on-duty" ring changes — a planet-scale shift schedule, slow and predictable;
• every 11 minutes or so, one satellite hands a town's conversations to the satellite behind it — the fast rhythm, set by how closely the ring files its satellites rather than by how long any one of them could serve.

Hold onto the word duty. It is a real and useful idea — one ring does lie closest to the band, and it does carry the most traffic — but we will find, when the simulation is done with us, that it never works alone.

The wheel above is that schedule, running. Nothing in it maneuvers: the six planes are pinned to the stars exactly as the trap insisted they must be, and the planet's own rotation does the scheduling. But watch the misalignment readout through a shift. It is zero only for an instant, in the middle of the shift, when the band lies straight along the duty ring; it climbs from there, and at the moment of handover it stands at its worst — 15 degrees off the ring going off duty and 15 degrees off the one coming on. The shift change and the sourest geometry of the shift are the same event. Remember that; it is where this design breaks.

Two rhythms, hours and minutes, and every piece of protocol we design later must dance to both. With 12 satellites spaced around each ring, the fleet is 6 × 12 = 72 spacecraft. That was our seed design, at 1,800 km — the laborer shelf. It looks right. Most wrong designs do.

Two numbers place a satellite

We have been describing the wheel in words — six rings, fanned like spokes, 30 degrees apart — and words are about to run out. The simulation needs to know where every one of the seventy-two spacecraft is, at every instant, and it gets that from two numbers per satellite. The inclination is already settled: 90 degrees, straight over the poles, for the reason the last section gave. What remains is which plane a satellite flies in, and where in that plane it sits.

The first number names the plane. An orbit is a circle in space, and a circle through both poles cuts the equator at exactly two opposite points — one where the satellite is heading north, one where it is heading south. The northbound crossing is the ascending node, and the angle at which it happens is the plane's right ascension of the ascending node: RAAN, the name it carries in every orbital catalog.

Both halves of that phrase are load-bearing, so it is worth taking apart. Ascending node is the northbound crossing we have just found, as opposed to the descending one half a circle away — naming the plane by one of its two equator crossings, and picking the northbound one by convention. Right ascension is the astronomer's longitude: an angle measured around the equator like any other, but reckoned against the fixed stars rather than against the ground, from a zero direction the sky agrees on, and no planet can drag with it. That distinction is the whole difference between a RAAN and a longitude you could paint on a map. A town's longitude turns with the planet. A plane's right ascension does not, because nothing fastens the plane to the planet: it is a circle in space, and space does not turn.

Give a polar orbit its right ascension, and you have named the plane completely; every satellite in it rides the same circle.

So a wheel of six rings needs six values of RAAN, and here the obvious guess is wrong in a way worth slowing down for. Six things spread evenly around a circle sit 60 degrees apart. Our rings sit 30 degrees apart, and their RAANs are 0°, 30°, 60°, 90°, 120°, and 150° — they stop halfway around and never finish the circle. Look at the wheel above, and you can see why: each ring is drawn as a diameter, not a spoke, because a polar orbit passes over both poles and so reaches clean across the planet. The three-dimensional model at the top of this page will show you the same thing: press Pole view · North, and the rings you have been watching as loops flatten into six straight lines through the middle of the world. The plane you would place at 180° is the plane already sitting at 0°. It is the same circle in the same piece of sky, traversed in the opposite direction. A polar plane is its own opposite, so N polar rings divide 180 degrees rather than 360:

let raan = k as f64 * PI / c.planes as f64;   // PI, not 2 * PI

That single PI is the reason the shift schedule has twelve shifts and not six. The band sweeps a full circle in a local year and meets a plane every 30 degrees of that sweep — but there are only six planes, so each one takes duty twice, once as its ascending half swings into the band and once, half a year later, as its descending half does. The roster on the plate's rim carries every ring number twice for exactly this reason.

The second number places the satellite along the ring. Twelve satellites, evenly filed, 30 degrees of arc apart:

let theta0 = j as f64 * 2.0 * PI / c.sats_per_plane as f64;   // here, the full circle

The full circle this time, because a satellite genuinely can be anywhere on the ring and a position and its opposite are two different places. Those 30-degree slots are what set the fast rhythm: the handover cadence we are about to quote is the time it takes the ring to advance by one slot.

The arrows on the plate are worth one more look, because they carry a fact we will need twice more before this section is done. Walk around the rim, and you pass six rings running inward — climbing north over the pole — and then six running outward, back down the far side. Between those two runs are two places where a ring's nearest neighbor, 30 degrees away, is flying the other way entirely. These are the wheel's seams. They are unavoidable: the nodes span half a circle, the traffic spans a whole one, and something has to give at the join. When we try to interleave the rings like a honeycomb later on, the seams are what defeat it.

One last consequence, and it closes the loop with the trap. The planes hold their right ascensions forever, because that is what being measured against the stars means; the planet turns underneath at 32.14° a day. In the planet's own frame, then, every node walks steadily backward — node = raan - spin * t, one line in the simulator — and that backward walk is the shift schedule. The wheel does not hand over because anything aboard it decides to. It hands over because the ground keeps moving and the nodes do not.

When the backbone puts a navigation shell above this one, it will spread its nodes over a full 360 degrees instead. Nothing has changed about the arithmetic; those planes are tilted 55 degrees rather than 90, and a tilted plane is not its own opposite — flip it halfway around the planet, and it leans the other way. Only the polar case gets to halve its circle.

The interrogation

Confidence is not evidence. So we put the whole planet under simulation: sample the inhabited band — its center line and both edges, all the way around — and every 30 seconds for a full 11.2-day rotation, count how many satellites each sample point can actually use, meaning satellites standing at least 25 degrees above that point's horizon. The counting core is brute-force honest:

/// Number of the constellation's satellites at or above `min_elevation`
/// as seen from `ground_unit` at time `t`.
pub fn visible_count(body, c: &PolarConstellation, ground_unit, min_elevation, t) -> usize {
    let mut count = 0;
    for k in 0..c.planes {
        let raan = k as f64 * PI / c.planes as f64;
        for j in 0..c.sats_per_plane {
            let theta0 = j as f64 * 2.0 * PI / c.sats_per_plane as f64;
            let sat = polar_sat_position(body, c.altitude, raan, theta0, t);
            if elevation(body, ground_unit, sat) >= min_elevation {
                count += 1;
            }
        }
    }
    count
}

The number that matters is the minimum — the worst moment of the worst town's whole year. An average means nothing to a village whose connection died at shift change. And for the 72-satellite seed at 1,800 km, the minimum is zero.

Somewhere in the band, sometime in the rotation, a town looks up and finds no usable satellite at all.

Anatomy of a silence

The gap lives at the seams of the wheel. When the twilight band lies midway between two rings, a town at the band's center sits about 15 degrees off either ring's track. From that far aside, a passing satellite stands high enough to use for only a short stretch of its arc — about ±13 degrees of along-track travel. But the satellites in a ring are spaced 30 degrees apart. 13-degree windows, 30-degree spacing: between one satellite's setting and the next one's rising there is a sliver of silence, sweeping the mid-seam country like a slow blade, several times an orbit, every 22.4 hours when the geometry sours.

Both flanking rings are in the same predicament at the same moment, and — in this first design — in the same rhythm: every ring files its satellites at identical phase, so their windows open and shut in unison and their gaps line up perfectly. The silence is not one ring's failure. It is all of them blinking together. Nor is it only the mid-seam towns that suffer: the band is 20 degrees wide, and its two edges lie farther from every ring than its center does, so the outer margins of the inhabited zone go dark slightly more often than the middle.

We will admit an embarrassment here, because the RFP's author values honest methods over tidy stories. Our first, coarser simulation — samples every two minutes — showed that staggering the rings' phasing closed the gap, and we nearly filed that as the fix. At 30-second sampling, the gap reappeared through every stagger we tried: the silences were narrow enough to slip between our samples. A machine intelligence reviewing this proposal would have caught that in an afternoon. We preferred to catch it ourselves. Coverage claims in this proposal are therefore made only at fine sampling, as a standing rule.

Buying coverage with altitude instead of hardware

Two honest fixes exist. The brute-force one: more satellites, tightening the spacing until the windows overlap — at 1,800 km that takes 84. The elegant one: raise the whole fleet, which widens every satellite's footprint, stretching the along-track window until 12 per ring suffice again. The simulation prices both:

cargo run --release -p terminus-orbits --example access_constellation

  alt (km)   rings  sats/ring   total   min visible   mean visible
      1800       6         12      72             0           2.68
      1800       6         14      84             1           3.13
      1800       7         12      84             1           3.13
      2000       6         12      72             1           3.07
      2200       6         12      72             1           3.45
      2400       6         12      72             1           3.81

Climbing 200 km closes the gap with the same 72 spacecraft — but at 2,000 km the along-track window beats the spacing by under three percent, a margin we decline to bet a civilization on. At 2,200 km the margin is real, the average town sees about three and a half satellites, and the edge-of-footprint latency has crept only from about ten to about twelve milliseconds — still comfortably inside the RFP's budget. The evaluation rule in TER-REQ-016 makes the choice for us: altitude is free forever; twelve extra spacecraft are not.

The baseline access fleet, recorded as ADR-0003: six polar rings, twelve satellites each, at 2,200 km. The old 1,800 km label is retired from the reference architecture.

With the altitude settled, the fast rhythm gets its exact value — and it is worth a sentence of its own, because the obvious guess is wrong. A satellite up here could serve a town for 16.6 minutes: that is the pass the survey measured, the whole arc of a satellite that happens to cross straight overhead. But a town is never given a whole pass. The next satellite in the ring rises behind it, climbs higher in the sky, and the link moves. One orbit, 131.6 minutes, divided by twelve satellites, is 11 minutes — and that, not the pass, is the nominal interval every later protocol has to survive. Handover cadence is the ring's spacing, not the satellite's pass duration. Treat 11 minutes as a ceiling rather than a promise: as the next section shows, the satellite that rises next is not always in the same ring, and a link that moves between rings moves sooner. It is also a lever: a satellite added to a ring buys coverage and costs handovers in exact proportion; a ring added to the wheel buys coverage and costs none.

One debt is flagged in the ADR rather than hidden: a minimum of one visible satellite is coverage without redundancy. Lose that satellite — or ask, as we soon will, for a second one to be visible before the first lets go of a conversation — and the count must rise. The simulation has already priced it: eighteen satellites per ring instead of twelve, 108 instead of seventy-two, buys a minimum of two. We will pay that bill when we design the handover machinery, and pay it knowingly.

Who is actually on duty

We have been saying "the duty ring" as though the wheel takes turns, one ring working while five coast. The simulation has been quietly telling us otherwise the whole time, because it never counted rings — it counted satellites, wherever they were. So ask it directly: when a town looks up, how many rings can it actually see?

The answer depends on where the town stands, and the reason is a piece of geometry we have been using all along without following it through. Polar rings are 30 degrees apart at the equator, but every one of them passes over both poles. They are not parallel; they are a fan, splayed at the waist and pinched at the ends.

cargo run --release -p terminus-orbits --example duty_ring_trade

Near the equator — where most of the band's area lies, and most of its towns — the wheel is a two-ring affair. The duty ring is genuinely the workhorse there, supplying about half of everything the town can see, with a single neighbor covering the rest and, crucially, covering the moments when the duty ring's own satellites are between slots. Walk toward a pole, and the rings crowd together until all six are overhead at once, and "duty" stops meaning anything: the on-duty ring's share falls to 17 percent, which is exactly the one-sixth a town would get if the label were assigned at random.

So the duty ring survives as an idea, and the shift schedule is real. What does not survive is the notion that it works alone. A town at the band's edge, at the sourest moment of the shift, can be 35 degrees of arc from the duty ring's track — and a satellite at 2,200 km can reach only about 23 degrees. That town is not underserved by the duty ring; it is outside it altogether. No number of satellites added to that ring would reach it, because the failure is one of reach, not of spacing. We priced the alternative honestly: a fleet where the duty ring really did serve alone would have to fly at 7,300 km, nearly tripling edge latency from 12 to 32 milliseconds, or drop its elevation mask to 5 degrees and surrender the rain margin this cloudy, wind-driven band cannot spare.

There is a gift hidden in this, and it is worth more than the tidiness we gave up. We re-ran the whole rotation 64 times per design, each time dealing every ring a different, arbitrary starting phase — the sort of scramble a real launch campaign produces when windows slip. The minimum never moved. Not once in 256 attempts did a scrambled wheel cover the band worse than a perfectly synchronized one.

We should say precisely what that does and does not prove, because we tested one more idea and it failed. A cellular network covers a city by offsetting each ring of towers half a step from the last, so their cells interlock like a honeycomb — the densest way known to tile a flat plane with circles. Try the same trick here, giving each ring half a satellite's head start on its neighbor, and the wheel gets worse: at our twelve satellites per ring, it opens a gap that the plainly aligned wheel does not have — --example phasing_options walks the whole profile, and the result is not even monotone in satellite count, because "half a slot" means 360°/satellites and so changes meaning every time you add one. The honeycomb does not survive the trip from a plane to a sphere. Every ring runs over both poles, so the cells that were tidy hexagons at the equator pinch shut at the caps; and because a ring is a closed circle, it serves the band at two opposite longitudes at once, climbing north on one side while falling south on the other, so there is no single offset to tune. Where the wheel closes on itself, neighboring rings run in opposite directions outright.

So the freedom we have is narrower than it first looked, and worth stating honestly: the fleet is free to ignore inter-ring phase, not free to choose it badly. Uncoordinated is safe. Clever is not.

That matters enormously for how this fleet gets built. A launch reaches a given ring only when the launch site swings beneath its plane, and on a world that turns once every 11.2 days, those windows are precious — one per ring per rotation, each ring's window 22.4 hours after its neighbor's. Had coverage depended on the rings staying in step, every launch would have had to hit not just its window but a particular minute inside it, and then the fleet would have had to hold that arrangement forever: a satellite injected just 100 meters off its intended altitude drifts a full slot within about fourteen months. It costs almost nothing to correct — a nudge of about forty millimeters per second — but it is a nudge that never stops being due, on all seventy-two spacecraft, for as long as the constellation flies.

We owe none of it. The rings may be launched in any order, in any year, at any phase, and a slipped window costs exactly one late satellite and not one second of anyone's coverage.

Most of the fleet is asleep

Look again at that latitude table, and something should nag. A town near the pole has all six rings overhead — but it is one town, with one sky's worth of demand. Why would we run seventy-two transmitters to serve a band that never needs more than a handful over any one place?

We would not. Visible and needed are different questions, and we have been answering the wrong one. So ask the right one: at each instant, what is the smallest set of satellites that still serves every point of the band? That is a classic problem — minimum set cover — and our instances are small enough that we do not have to guess at the answer. We can prove it.

cargo run --release -p terminus-orbits --example activation_plan

Read the second row as an epitaph. Lighting only the duty ring — the design we spent this section dismantling — leaves the band uncovered at every single instant we sampled. It never works, not once in eleven days.

Read the last row as the prize. Twenty-one satellites, on average, can hold the entire twilight band. Roughly seventy percent of the fleet can be dark at any given moment. That is not an estimate; a branch-and-bound search — the kind that discards whole families of plans at once until only the provably best remains — closed on the true optimum at all 16,128 instants we tested (the same 11.2-day rotation, planned at a one-minute step rather than the interrogation's 30 seconds), so the number is a floor and not a hopeful heuristic.

But we are not going to fly the optimum, and the reason is instructive. The optimal plan is free to reshuffle its entire active set every minute, and it uses that freedom: it switches satellites on and off 423 times an hour to our 253, and every switch is a thermal cycle and a power-electronics cycle on a spacecraft we would like to last decades. What it buys for all that churn is under two satellites.

So we take the policy in the third row, which an operator can still state in one sentence: light the duty ring, add satellites from the neighboring rings wherever a hole remains, then switch off anything that turns out to be serving no one. The duty ring keeps its meaning — it is genuinely the block that goes on first — and the wheel fills in behind it.

Here is the whole algorithm — first as a shape, then as something you could implement from. There is nothing clever in either, and that is the point: every step is one a ground controller could check by hand.

The flowchart shows the shape; the loop at its heart deserves stating exactly, because everything turns on how the next satellite is chosen:

plan(t):
    duty  ← ring whose plane lies closest to the terminator at t
    lit   ← every satellite in duty                  # block, before measuring
    for each of the 216 band points p:
        reach[p] ← satellites ≥ 25° above p at t

    while some p has no satellite in lit:
        best ← argmax over dark satellites s of
                   |{ p : reach[p] ∩ lit = ∅ and s ∈ reach[p] }|
               ties broken toward s already lit at t−1
        lit ← lit ∪ {best}

    for s in lit, dark-last-instant first, then least useful first:
        if every p reached by s has another satellite in lit:
            lit ← lit \ {s}                          # prune
    return lit

smooth(plans):                                       # across time, not within
    for each satellite s:
        close every off-gap shorter than 180 s       # lazy off
        extend every on-run backward by the warm-up  # warm start

The Rust this is drawn from is crates/orbits/src/activation.rs — duty_first_activation is the planner, smooth_schedule the pass over time, and exact_activation the branch-and-bound that produced the proved minimum we decided not to fly.

Five things in there are doing real work.

The duty ring goes on as a block, before anything is measured. That is not an optimization — it is what keeps the plan explainable. The ring nearest the band will carry most of the traffic anyway, so starting from it costs little and means the answer always has a shape a human recognizes. The prune pass may hand one or two of them back at the end, but the block is where every plan starts.

The score counts holes, not coverage. Read the argmax again: a dark satellite is judged purely on how many currently unserved points it would rescue — not on how much sky it can see, and not on how much it would reinforce places already covered. A satellite hanging over a stretch of band that three others already serve scores zero and stays dark, however good its view.

The last pass undoes the greedy loop's own mistakes. Each pick is the best one available at the moment it is made, and that is exactly the weakness: a satellite lit to close hole A often also covers hole C, which a later pick made for hole B then covers again. The early pick is now carrying nothing the plan needs, and nothing in a forward-only loop will ever notice. So the planner finishes by walking everything it has lit and switching off any satellite whose every point would remain covered without it. It is worth 1.1 satellites — and the surplus it removes is not spread evenly. It piles up over the poles, where all six planes converge, and one patch of ground ends up served several times over by satellites each chosen for a different hole. That is precisely where this section began, and precisely the over-serving it set out to disprove.

Ties go to whoever was already awake. When two satellites would close the same number of holes, the one lit a moment ago wins. It costs nothing, and it stops the plan from reshuffling itself for no reason — the churn that made the theoretically optimal policy so expensive two paragraphs ago.

The smoothing happens across time, not within an instant. plan(t) sees one moment and nothing else, which is exactly what makes a satellite flicker: needed, not needed, needed again, in the space of a couple of minutes. Planned that way, a satellite blinks on and off 787 times a day for no gain at all. The lazy-off rule kills every one of those for about one and a half extra satellites lit, and it can be exact rather than a guess, because the geometry is known years ahead — "will this be needed again shortly?" has a real answer.

That last point is what makes the whole scheme practical. This is a timetable, not a negotiation. Nothing in the diagram runs on a spacecraft; it runs on the ground, weeks early, and the fleet is told when to wake up.

One honesty check before we bank the savings. A dark satellite cannot take a conversation the instant it is asked; it has to be awake before it is needed. Charge the plan for that lead time, and the numbers move:

Even granting a full ten minutes of warm-up — far more than any radio needs — the fleet still runs under half lit. And notice what the lead time does to the prune pass. It saves 1.1 satellites with nothing charged for warm-up, and 0.1 at five minutes, where the plan with the pass (30.4) and the plan without it (30.5) are indistinguishable. On the averages alone it stops paying for itself almost immediately.

We keep it anyway, and the reason is not arithmetic. A pruned satellite is not one the plan suspects is idle; it is one the plan has proved serves no point that needs it. There is no defending a transmitter radiating at nobody when the check that finds it is free and runs on the ground weeks in advance. The averages stop rewarding the step long before the argument for it runs out — which is worth remembering the next time an optimization is judged by its mean.

Two things this does not buy, and the RFP will ask about both. It does not shrink the fleet: all seventy-two spacecraft are still required, because the satellites dark now are working in twenty minutes. And it does not relax the handover design — quite the opposite: since a link may only ever be handed to a satellite that is already awake, the activation timetable and the handover plan have to be generated together. We will honor that when we build the handover machinery.

Running it yourself

Nothing in this section is a claim you have to take on trust. The simulator is terminus, it is open source, and every table above is one command away. You need a Rust toolchain (1.79 or newer); nothing else.

git clone https://github.com/eventhelix/terminus
cd terminus
cargo run --release -p terminus-orbits --example access_constellation

Four examples carry this section:

One practical note, and it is not optional: keep --release. These sweeps evaluate a full 11.2-day rotation against 216 sample points — at 30-second resolution for the coverage sweeps, one-minute steps for the activation planner — hundreds of millions of geometry evaluations — and a debug build turns those minutes into an afternoon. The runtimes above are from an ordinary laptop; treat them as the shape of the cost rather than a promise. That cost is the honest price of the fine sampling this section insisted on, and it is exactly why our first pass sampled every two minutes and got the wrong answer.

If you would rather read the code than run it, the counting core is crates/orbits/src/constellation.rs, the duty-ring and activation logic are duty.rs and activation.rs, and cargo test -p terminus-orbits checks every claim in this section — including the two that caught us out: that a coarse sample grid hides real gaps, and that the half-slot stagger breaks the very baseline it looks like it should improve.

The wheel, turning

So picture the finished thing from far above the pole: six silver rings fanned around a dark world, seventy-two points of light sliding along them; a red ribbon of civilization turning slowly beneath, and duty passing from ring to ring like a watch changing in the night. Every town under at least one satellite, every second, for as long as the fleet is maintained.

And every one of those conversations is now arriving at a satellite 2,200 km up and asking to reach a large language model. Where is the model? On the satellite overhead, which vanishes in a quarter of an hour? Spread across the fleet? Parked out at those strange balance points the star cannot steal? The next section takes on the question the whole proposal has been circling: where does the mind live?