1. The signal that had to decide what mattered most

Douglas Adams’s The Hitchhiker’s Guide to the Galaxy returns as the recalled work because the Guide’s entries are not all equally urgent: some are vital safety information, some are mildly useful, and some are just the author’s opinions about towels. A LEO desktop faces the same triage problem with its data. Telemetry saying the battery is failing is not the same as a queued customer image. The platform must decide what to send when bandwidth is scarce and link conditions are changing.

This entry wonders about link adaptation and data prioritization.

Link adaptation is the real-time adjustment of modulation, coding, and data rate to match the current link margin. At the beginning of a pass, when the spacecraft is low on the horizon, the path loss is high and the link margin is low. Near zenith, the margin is highest. A fixed data rate either wastes capacity at zenith or loses contact near the horizon.

The options include:

  • Constant modulation and coding: simple, predictable, but suboptimal.
  • Discrete mode switching: the platform switches between a few predefined modes based on estimated or measured margin.
  • Continuous adaptation: the modem continuously adjusts rate and coding, as in DVB-S2 variable coding and modulation.
  • Closed-loop feedback: the ground station reports received signal quality and the platform adapts accordingly.

For the desktop, discrete mode switching or DVB-S2-style adaptation is realistic. The platform needs a model of link margin versus elevation and weather, plus a measurement of actual performance.

3. Data prioritization

Not all data is equally valuable or equally time-sensitive. A useful prioritization scheme might include:

  • Critical housekeeping: telemetry needed for safety, such as power, thermal, and fault status.
  • Command acknowledgments: confirmation that ground commands were received and executed.
  • Time-sensitive payload data: customer products with a deadline, such as disaster imagery.
  • Routine payload data: standard products that can wait for the next pass.
  • Bulk archive: data that is nice to have but can be overwritten if storage is full.
  • Debug and logs: engineering data used for diagnosis, lowest priority unless troubleshooting.

The platform should queue data by priority and age, with rules for promotion and deletion. A high-priority item should not be delayed by a low-priority stream. A stale low-priority item should be discarded rather than consuming bandwidth forever.

4. The interaction between adaptation and prioritization

Link adaptation determines how much data can be moved during a pass. Data prioritization determines which data gets those slots. Together they define the communications policy:

  • During a poor pass, send only critical housekeeping and acknowledgments.
  • During a good pass, send time-sensitive payload data first, then routine data, then archive if capacity remains.
  • If storage is filling faster than downlink can empty it, increase transmit time, reduce data generation, or drop lower priorities.
  • If a pass fails entirely, retry critical data on the next available link and adjust priorities for the backlog.

5. What could go wrong

  • The link adaptation algorithm is too aggressive and causes frame errors during marginal conditions.
  • The prioritization scheme starves routine data because critical housekeeping always wins.
  • A customer expects real-time delivery but the platform queues their data behind higher-priority items.
  • The platform deletes data that ground later asks for because the retention policy was too short.

6. What this changes

  • Link adaptation and data prioritization are two sides of the same communications policy.
  • The desktop needs both a link model and a data value model.
  • The next entry will wonder what autonomous communications management needs from the desktop specifically.