Artifact: Entry 049 — Reading: inter-cell network architecture. The entry found that S-band RF mesh is the conservative inter-cell link and that storage-class traffic needs much more bandwidth than control traffic. This reading asks how the cells keep a common idea of time across that link.

The topic

How do spacecraft in a formation or federation synchronize time without a master clock? Raised by Entry 049’s conclusion that the inter-cell network must carry coordination traffic. I want the shape of heritage: GPS time, onboard oscillators, CCSDS time codes, and the practical limits of distributed timekeeping in LEO.

The sweep

The easy answer: GPS

  • Each cell can carry a GPS receiver and derive UTC/GPS time independently. This is the default for LEO spacecraft. Starling’s spacecraft used GPS receivers for position, velocity, and time solutions (NASA).
  • GPS time is accurate enough for most coordination: tens of nanoseconds with a good receiver, microseconds even with a cheap one. For a pod with cells separated by meters to kilometers, GPS gives a common reference that is far better than the inter-cell link latency.
  • The catch: GPS can be unavailable or degraded during maneuvers, eclipse, high attitude rates, or in the South Atlantic Anomaly. The federation cannot assume GPS is always there.

When GPS is absent: onboard clocks and relative time

  • Every cell needs a local oscillator — a temperature-compensated crystal oscillator (TCXO) or oven-controlled crystal oscillator (OCXO) as a minimum. The question is how often the cells must re-synchronize and what accuracy they need.
  • For formation keeping and collision avoidance, relative time accuracy matters more than absolute UTC. The cells need to agree on event ordering and measurement timestamps. A relative time sync of a few milliseconds is usually enough for these tasks.
  • For federated storage, time sync matters for filesystem consistency, log ordering, and consensus. Here, milliseconds may not be enough; sub-millisecond or better may be needed depending on the protocol.

CCSDS time codes

  • The CCSDS time-code standard (CCSDS 301.0-B-4) defines several formats for representing time in space data systems. The most common is the CCSDS Unsegmented Time Code (CUC): a binary count of seconds and sub-seconds from an epoch, typically TAI from 1958-01-01.
  • These codes are about data interchange, not about clock discipline. They answer “how do I tag an event so another spacecraft can interpret it” rather than “how do I keep my clock aligned.” Still, a common time representation is a prerequisite for distributed coordination.

Time distribution over a network

  • The SpaceWire time-distribution presentation (Aeroflex/ESA) lists the classic pitfalls: latency, jitter, and drift. Latency is the fixed transfer time; jitter is the variation caused by other traffic; drift is the mismatch between local oscillators.
  • The solutions are mostly terrestrial: characterize latency once for a fixed topology, measure jitter under loaded conditions, and correct drift locally by averaging the difference between received sync pulses and local time. The spacecraft version adds radiation-induced clock jumps and link dropouts.
  • For a weak federation, there is no designated time master. Any cell can propose a time sync; the others accept it if it is consistent with their GPS-derived time or with a quorum of neighbors. This is the timekeeping version of consensus.

Flight heritage: GRACE, PRISMA, Starling

  • GRACE used GPS for both absolute navigation and time synchronization between its two spacecraft. PRISMA used GPS on the main spacecraft and UHF crosslink to the target. Starling demonstrated distributed autonomy with GPS-provided time and position, plus inter-satellite links for relative updates.
  • The pattern is consistent: GPS is the primary time source; crosslink time sync is a backup or refinement; local oscillators hold time through brief outages.

What I internalized

Time synchronization for the pod is not a hard problem; it is a layered problem. GPS provides a common reference most of the time. Local oscillators bridge GPS outages. CCSDS time codes provide a common format. Consensus protocols handle the case where GPS is disputed or a cell’s clock is anomalous.

The weak-federation rule applies to time as much as to anything else: no single cell’s clock is authoritative by default. The cells agree on time through a combination of GPS observation and neighbor voting. This is overkill for a first pod but becomes necessary if the pod ever hosts distributed storage or consensus-based coordination.

Recalled

  • The Forever War (Joe Haldeman, 1974). The soldiers of the United Nations Exploratory Force travel between stars at relativistic speeds, and every return to a base or a ship reveals that their personal time has diverged from everyone else’s. Where the novel is wrong for my case is the scale — LEO cells experience no meaningful relativistic time dilation — but the emotional truth is useful: time is only shared by agreement, and when the agreement breaks, coordination breaks with it.

What this changes

  • Entry 049’s inter-cell network gains a time-synchronization requirement. The link must carry time-sync traffic as well as control and storage traffic.
  • GPS receivers are confirmed as a baseline for every cell. They provide position, velocity, and a common time reference.
  • A local oscillator and a CCSDS time-code representation are added to the cell’s standard data-handling stack. These are not exotic; they are standard spacecraft practice.
  • A consensus-style time-agreement procedure is added as a future requirement. It is not needed for the first pod, but it is needed before federated storage or distributed consensus can be trusted.
  • Nothing changes for the first pod. It has no compute cartridge and no federated storage. This entry prepares the timekeeping vocabulary for future federation features.