Skip to content
CubeSTEM MissionLabCubeSTEMMissionLab
Engineering workbench — a technical surface, not a school lesson. Go to the lessons

CubeSTEM MissionLab Twin · M3-G Teacher Guide

Multi-Station Contact Scheduling Lab

A 55–75 minute operations lesson on scarce contacts, deadlines, guard time, station contention, backlog and resilient re-planning.

Open learner workbench

Learning objectives

  • Distinguish geometric visibility from a usable communications contact.
  • Explain acquisition and release guards, station availability and spacecraft concurrency.
  • Prioritize emergency command and health telemetry before lower-urgency payload demand.
  • Use deterministic reason codes to explain selected, rejected and deferred decisions.
  • Compare a candidate plan with the reference schedule using a visible scorecard.
  • State why the model is not a station-booking, spectrum-authorization or operational scheduling system.

Suggested lesson flow

  1. Brief and predict — 10 min: learners identify the most urgent demand and predict which contact will be selected.
  2. Reference run — 10 min: run Single Station, Competing Needs or Deadline Before Capacity in Guided mode.
  3. Read the evidence — 10 min: inspect usable intervals, guard losses, capacity, reason codes and unmet backlog.
  4. Build a candidate — 10–15 min: switch to Builder mode, select contacts and assign a first-demand preference.
  5. Stress the plan — 10 min: run Station Outage or Readiness Constraint and compare the resilience replay.
  6. Explain and submit — 5–20 min: learners submit the deterministic hash, scorecard, trade-off judgment and fidelity boundary.

14-mark rubric

Prediction · 2

Makes a testable prediction about the first selected contact and the demand it should protect.

Window reasoning · 2

Correctly uses acquisition/release guards and identifies at least one unusable or conflicted opportunity.

Priority and deadline reasoning · 3

Protects emergency/health demand and explains the effect of earliest time and deadline.

Capacity and backlog · 2

Uses delivered data, utilization and remaining backlog evidence without exceeding declared capacity.

Resilience · 2

Explains how an outage or readiness block changes station diversity and recovered data.

Evidence traceability · 1

Records the deterministic candidate and artifact hashes.

Fidelity statement · 2

States that station profiles and windows are teaching declarations and not real booking, RF or flight evidence.

Discussion prompts

  • Why can a shorter low-rate contact be more valuable than a later high-rate contact?
  • When should partial payload delivery be accepted, and when is a partial command unsafe or useless?
  • Why is a visible pass not automatically a usable communications opportunity?
  • How does using more than one station affect resilience and operational complexity?
  • Which scorecard component improved, and which trade-off became worse?

Common misconceptions

  • Peak elevation alone does not determine the best schedule; deadlines, guards, readiness and demand class also matter.
  • A contact window is not fully usable because acquisition and release time must be reserved.
  • High capacity does not justify missing a time-critical command or health deadline.
  • Using every visible contact may create spacecraft or station concurrency conflicts.
  • The outage-resilience replay is a bounded teaching comparison, not a service-level guarantee.

Fidelity and authority boundary

M3-G uses deterministic teaching windows, approximate city-level station declarations, bounded data rates and a documented heuristic. Measured channel count is zero. The simplified capacity pool does not model detailed uplink/downlink protocols, modulation, coding, interference, licensing or real station operations. The lab provides no official-attempt, Mission Credit, hardware, station, operator, ESTOP, arbitrary-code, spectrum or production authority.