1. The guide that needed a map and a battery

Douglas Adams’s The Hitchhiker’s Guide to the Galaxy returns one last time for this arc because the Guide is only useful if it knows where it is, knows where the network is, and has enough power to call for an update. The desktop’s autonomous communications manager needs the same three things: orbital and attitude state, link predictions and measurements, and the power and thermal budget to transmit.

This entry wonders what autonomous communications management needs from the desktop.

2. State and prediction

The platform cannot manage links it cannot predict. It needs:

  • Orbit state: precise position and velocity to predict ground station visibility and Doppler shift.
  • Attitude state: knowledge of where the antennas are pointing, especially for high-gain links.
  • Ground segment model: up-to-date schedules, locations, capabilities, and costs for available ground stations and networks.
  • Link model: predicted path loss, atmospheric attenuation, and interference as a function of elevation and weather.
  • Storage state: how much data is queued, by priority and age.
  • Power and thermal state: whether the platform can afford the transmit power and can reject the resulting heat.

These models do not need to be perfect, but they must be good enough to avoid unsafe or wasteful decisions.

3. Measurement and feedback

Prediction is not enough; the platform must also measure and adapt:

  • Received signal strength and quality: from ground transmissions, used to calibrate the link model.
  • Telemetry acknowledgments: confirming that transmitted data was received.
  • Bit error rate or frame error rate: indicating whether the current modulation and coding are appropriate.
  • Ground station status: whether a scheduled station is actually available and receiving.

Without feedback, the platform is flying blind. With feedback, it can correct its models and recover from unexpected conditions.

4. Policy and authority

The platform must know what it is allowed to decide:

  • Which ground stations or networks can be used without explicit approval?
  • Which data priorities can be overridden in an emergency?
  • What transmit power, data rate, and frequency bands are permitted?
  • When must the platform notify ground before or after a decision?
  • What happens if a pass fails: retry, defer, or escalate?
  • Which communications activities can preempt payload operations, and vice versa?

Policy is the boundary between useful autonomy and rogue behavior. It must be defined by the operator, loaded from ground, and enforced onboard.

5. Execution and recovery

Finally, the platform needs the ability to act and to recover:

  • Point antennas, configure modems, and start and stop transmissions.
  • Switch between bands, stations, or relay paths.
  • Buffer, retransmit, and delete data according to policy.
  • Detect missed passes and bad links and take corrective action.
  • Log every decision and anomaly for ground review.

6. What this changes

  • Autonomous communications management builds on orbit determination, attitude control, power management, thermal management, and data storage.
  • The desktop already has most of these pieces from earlier arcs. The new work is integration and policy.
  • The next entry will close the autonomous communications management wondering arc.