Ground Station Control Surface Design Principles

1. Capability-Driven UI

Enable or disable controls based on:

• node capability (phased array supports coordinate steering; fixed antenna does not)
• operator role (TM Operator can tune demodulator; Launch Director cannot)
• mission state (some controls are disabled during countdown or flight)
• current lock and health state (pointer controls are armed when lock is healthy; disabled during lock loss)

2. Operational Surfaces

Organize controls into three levels:

1. Launch panel: countdown, mission state, lock status, one-button controls for familiar operations (e.g., "Acquire telemetry")
2. Operator pages: per-role pages with all controls relevant to that role (e.g., antenna control for Antenna Engineer, telemetry for TM Operator)
3. Engineering tools: advanced diagnostics, raw metrics, manual overrides; visible only to System Administrator and Antenna Engineer roles

3. Frame and Payload Configuration

Frame configuration should be exposed to the TM Operator through:

• a "Telemetry Setup" page accessible before launch
• visual editing of sync words with hex input and validation
• frame structure builders (drag-and-drop or form fields for frame fields)
• field-type definition (int/uint/float/bool/enum/bitfield) with scaling and units
• ability to test a frame configuration against sample binary data before committing
• ability to label payloads and publish typed parameters into the mission data catalog

Dashboard composition and UI binding should be exposed to the Operation Manager (OPM) or Configuration Manager (CM) through:

• dashboard page editor using rows, columns, or grid layouts
• widget selection and placement with per-widget size constraints
• role visibility rules deciding which role sees which widget instance
• value-to-widget bindings that only allow type-compatible parameters
• per-target binding support so the same payload type can render independently for multiple tracked targets

Binding examples for one payload type:

• latitude, longitude -> map track position layer (per target)
• altitude_m -> altitude strip chart + numeric readout (per target)
• speed_mps -> velocity gauge + trend chart (per target)
• vertical_speed_mps -> climb-rate indicator (per target)
• battery_v -> health card + warning threshold rule

Operator workflow expectations:

1. TM Operator defines payload type and parameters.
2. TM Operator assigns sync words and validates decoding with sample frames.
3. TM Operator publishes schema version to active mission profile.
4. OPM or CM composes dashboard pages from widgets.
5. OPM or CM binds typed parameters to widget inputs with per-target scope.
6. OPM or CM applies role visibility rules and monitors binding health (unbound parameters, type mismatch, stale data).

Do not require the TM Operator to understand the node data dictionary. The UI should present:

• "Add a new payload type"
• "Sync word: 0x1ACFFC1D"
• "Frame size: 256 bytes"
• "Frame contents:" [form to drag fields]

4. Antenna Control Organization

Antenna control should be organized by capability level and mission phase:

Pre-launch:

• Antenna type selector (discover capability)
• Static beam point entry
• Test tracking modes (Manual, Fixed, Trajectory with known test coordinates)
• Frequency validation

Launch and Ascent:

• Active tracking mode display
• Real-time az/el readout
• Optional manual override (with 3-second hold confirmation)
• Frequency hold status and controls
• Lock state and signal metrics

Post-flight:

• Beam archive view (final pointing)
• Heatmap if captured

---

Next: See Project Operational Flow for data flows and mission state behavior.