Ground Station Frontend Architecture

1. Frontend Architecture Reinterpretation

1.1 Frontend baseline

The browser frontend application should be designed as a real-time mission-control dashboard, not a read-only information portal.

Architectural baseline:

• Built with TanStack Router for routing and server/client boundary management
• Styled with Tailwind CSS v4 for consistent tokens and responsive layouts
• Uses shadcn/ui components on Radix UI primitives for accessibility and control consistency
• Data management via TanStack Query for async state, caching, and refetch logic
• Visualization with Plotly (default for telemetry, maps, and heatmaps) plus specialized libraries where needed
• Real-time updates via WebSocket client for telemetry streams, lock state, events, and node health
• UI state and navigation via route loaders and application state stores to support dynamic mission workflows

Dashboard composition baseline:

• Data-display pages are assembled from reusable widgets (cards, charts, maps, status panels, timelines)
• Page layouts use a responsive row/column grid that must adapt across desktop, tablet, and phone aspect ratios
• Each widget declares contract metadata: supported input types, labels, minimum or maximum size constraints, and rendering hints
• Widget instances are reusable across pages, and each instance can bind to different payload values

Page structure (MVP baseline):

1. Dashboard (launch command center)

   • Mission countdown with state display
   • Lock indicators and signal health
   • Antenna node status cards
   • Quick-action buttons
   • Event timeline (scroll to see pre-launch, launch, ascent events)

2. Telemetry (real-time data view)

   • Parameter value table or graph panels (live update via WebSocket)
   • Alarm and threshold configurations
   • History playback scrubber
   • Export/logging controls

3. Antenna & Pointing (RF control)

   • Beam az/el indicators and manual controls
   • Target coordinate entry (for trajectory or GPS steering)
   • Tracking mode selector
   • Beam pattern or heatmap live view (if available)
   • Antenna type and capability discovery
   • Frequency hold controls and status

4. Position & Orientation (navigation)

   • Live map of rocket trajectory
   • Vehicle attitude display (pitch, roll, yaw)
   • Range, altitude, velocity indicators
   • Predicted impact or station-keeping zones

5. Calibration & Setup (pre-launch)

   • Payload type and sync word definition UI
   • Template library for known rocket telemetry formats
   • Node discovery and capability query
   • Test harness for frame decode validation

6. Dashboard Manager (OPM/CM surface)

   • Page layout editor (grid, rows, columns, responsive breakpoints)
   • Widget catalog with constraints and supported value types
   • Role visibility rules (which role sees which widget)
   • Widget input binding editor with type validation

1.2 Frontend roles

The system should support distinct operator roles to enforce different control authority:

1.3 Role-based access control model

UI enable/disable rules (driven by role and capability):

• TM Operator can only edit frame definitions; cannot change antenna pointing unless explicitly enabled for this mission
• Antenna Operator can only command antenna/beam; cannot change TM parameters
• Operation Manager / Configuration Manager can compose dashboard pages, assign widget visibility by role, and bind typed values to widget inputs
• Launch Director sees a simplified dashboard without deep technical controls
• System Administrator sees debug and engineering panels; can override role restrictions (with audit log)

Mission state gating (driven by countdown status):

• During countdown: no antenna/frequency changes (prevent accident)
• Terminal countdown (T-5 minutes): lock down TM parameter changes
• Post-flight: enable replay and data export

Capability gating (driven by node capabilities):

• If node reports phased_array, enable beamforming/DoA controls
• If node reports motorized_parabolic, show motor speed sliders; hide phased-array weight displays
• If node reports signal-led tracking unavailable, disable auto-track button

---

2. Frontend Extensions

2.1 Cross-cutting extensions

Real-time state indicators throughout all pages:

• Node online/offline status per node (color badge)
• Lock state indicator (searching → symbol lock → frame lock) with color-coded confidence
• Data freshness indicator (live, 1s old, stale/disconnected)
• System load and thermal warnings
• GPS fix quality indicator

Notification system:

• Toast alerts for critical events (lock lost, temperature warning, node offline)
• Modal for mission-critical confirmations (e.g., "Stop beacon 10 seconds before T+0?")
• Event timeline showing historical state changes

2.2 Dashboard page extensions

• Pre-launch countdown with separate mission-critical and engineering readout areas
• Real-time node selection dropdown (if multiple nodes available)
• Go/no-go button (Launch Director only) with 3-second safety confirmation
• Live event ticker showing lock transitions, anomalies, payload detections
• Abort or emergency stop button (visible to Launch Director and above)

Dashboard pages should be assembled from configurable widget instances:

• Layout model supports rows, columns, or free grid with breakpoint-aware reflow
• Widgets enforce declared size constraints (min_w, min_h, optional maxima)
• Widget input slots only accept payload values whose type matches the slot contract
• A single widget definition can be instantiated multiple times with different bound values
• Pages should remain usable at narrow aspect ratios by stacking or collapsing low-priority widgets

2.3 Position and orientation page extensions

• 3D or 2D map widget showing expected rocket trajectory with current estimated position overlay
• Range ring at node location showing beam coverage
• Altitude vs. time chart
• Velocity magnitude and vertical speed indicators
• Estimated impact zone (if ballistic model available)
• Optional: Camera overlay (if video feed available)

2.4 Telemetry page extensions

• Parameter grid showing live decoded telemetry with units and quality indicators
• Scrollable chart area showing selected parameters in real time (Plotly graphs)
• Threshold alarm UI (operator can set limits; color thresholds supported)
• Playback scrubber for post-flight review
• CSV export of selected telemetry range
• Binding inspector showing which payload parameters map to which UI components

2.5 Antenna page extensions

• Beam or antenna pointing visualization (compass rose or polar plot)
• Az/El target input (manual control)
• Tracking mode picker (Manual, Fixed, Trajectory, GPS, Signal-Led)
• Frequency hold enable/disable toggle with lock confidence display
• Antenna type and slew rate info box
• Multi-beam control if phased-array supports it (future extension)
• Beam pattern contour overlay on map (future)

2.6 Video page extensions

• Embedded video player (if camera/HDMI ingest available)
• Synchronized timestamp with telemetry (video scrubber linked to TM scrubber)
• Optional annotation UI for operators to mark events during flight

2.7 Calibration page extensions

• Payload type builder: sync word entry, frame field definition (drag-and-drop or form)
• Frame structure preview (visual layout of header, sync, payload, CRC)
• Test harness: upload binary test frames and decode preview with parameter values
• Template library: pre-built payloads for common rocket telemetry formats
• Push to active mission or save as draft

2.8 Dashboard manager extensions

• Widget palette grouped by capability (status, trend, map, event, custom)
• Drag-and-drop layout editor with responsive preview for desktop, tablet, and phone
• Per-widget input binding form showing value label, expected type, and candidate payload parameters
• Role visibility matrix for widget instances per page
• Validation checks for type mismatch, unbound required slots, and out-of-bounds widget sizes

---

Next: See Ground Station Control Surface Design for control-surface design principles and operator workflows.