Share a platform with different jobs

CASSIOPE launched from Vandenberg on September 29, 2013. Its name combines CAScade, Smallsat and Ionospheric Polar Explorer. The mission brought together a Canadian small-satellite platform, a science package called the enhanced Polar Outflow Probe, or e-POP, and the Cascade communications technology demonstrator.

The spacecraft bus provides shared services such as power, pointing, storage and communication. A payload uses those services to perform its particular job. An ion detector does not replace the battery that powers it, and a communications experiment does not make every scientific instrument interchangeable. This separation helps explain both the benefits and constraints of a multipurpose mission.

The launch photograph documents the flight that carried CASSIOPE. The spacecraft is enclosed in the rocket’s fairing, so the photograph does not show its individual sensors or prove that they later returned calibrated measurements. The separate rendering shows the spacecraft arrangement; its status as a drawing is kept visible in the caption.

Cascade demonstrated a store-and-forward concept for moving large digital files. A user sends a file during a suitable contact, the satellite retains it, and a later contact permits delivery. This differs from assuming that sender and receiver share a continuous real-time connection through the spacecraft.

Consider an original example with an 800-megabit file and a usable link rate of 100 megabits per second. Dividing size by rate gives eight seconds of ideal transfer time. If the receiver becomes reachable thirty minutes later, the file cannot arrive in eight seconds simply because the radio transfer is fast.

This calculation deliberately omits protocol overhead, retransmissions and interruptions. Those can lengthen the actual transfer. A megabit is a unit of data, while megabits per second measure a rate. Confusing bits with bytes would introduce another factor of eight. State units and assumptions before comparing a link demonstration with a delivery service.

Separate transfer time from delivery latency

A hybrid mission can reuse expensive infrastructure, but the payloads still compete for finite resources. Science data collection, transmitter operation and attitude changes may have different demands. A design must provide enough capacity for the chosen combination, including the platform’s own needs.

In a fictional scheduling exercise, a platform has 100 units of available energy for a planned interval. Housekeeping needs 30, the science sequence 45 and a proposed transmission 35. The total is 110, so the plan exceeds the stated budget by 10. A suitable response might change the schedule or reduce a demand; merely calling both activities important does not make the constraint disappear.

The mission’s original two-year design life was a planning requirement, not the date on which it automatically stopped working. Later lessons follow the actual operating history. Keep design intent, demonstration results and subsequent service distinct when judging what this shared platform achieved.