Architecture Overview

NORTHSTARSHOW SYSTEMS

Architecture Overview

How Compose, HelmOS, Polaris, and Cuemaster fit together

System Tiers

Northstar is a four-tier architecture. Each tier has one responsibility, communicates with adjacent tiers over a known protocol, and is independently testable.

Tier 1 — Design (Compose)

A desktop application running on the show designer's laptop. Stores the canonical show source — zones, nodes, cues, media. Outputs a single .nsss.compose archive containing both the show data and compiled Polaris firmware binaries.

Tier 2 — Runtime (HelmOS)

A headless service running on a venue-local Intel NUC. Receives .nsss.compose deployments over HTTP. Distributes firmware to Polaris nodes via ArduinoOTA. Dispatches cues based on incoming events (sensors, schedules, operator inputs). Serves the Cuemaster dashboard.

Tier 3 — Field (Polaris Nodes)

Arduino UNO R4 WiFi boards deployed throughout the venue. Each board executes one of five firmware variants (GPIO, Video, Audio, Bridge, Cuemaster placeholder). Receives UDP commands from HelmOS, drives output channels (relays, HDMI triggers, audio playback). Reports input events (sensors, buttons) back to HelmOS over UDP.

Tier 4 — Operation (Cuemaster)

A browser application served by HelmOS. Provides live show monitoring (Show Mode) and diagnostic access (Maintenance HMI). Stateless — close a tab and reopen, lose nothing.

Data Flow at a Show

Compose ─────[POST /api/deploy with .nsss.compose]────▶ HelmOS
                                                          │
HelmOS ──[UDP cue commands]──────────────────────────────▶ Polaris ×N
HelmOS ◀─[UDP heartbeats + input events]────────────────── Polaris ×N
                                                          │
HelmOS ──[WebSocket events]──────────────────────────────▶ Cuemaster
Cuemaster ──[WebSocket fire-cue / stop-all / maint]──────▶ HelmOS

Bridge ──[USB serial, JSON]──────────────────────────────▶ HelmOS  (button presses, key)

Why Distributed

• Latency — Polaris nodes respond to a UDP command in single-digit milliseconds. Centralised relay control via long cable runs would add per-meter delay.
• Cable reduction — venue wiring becomes Cat5 + power instead of multi-conductor signal runs to every effect.
• Isolation — a failed node affects only its zone. The rest of the show keeps running.
• Scalability — adding a new effect means installing one node and editing one cue. No central rewiring.

Where Show Logic Lives

All cue logic — what fires when, in what order, with what conditions — lives in HelmOS, not in Polaris firmware. Polaris boards are intentionally dumb: they know how to flash a relay or play a track, nothing more. This makes show edits zero-firmware: change cues in Compose, deploy the new project, the same firmware runs the new show.

Related Documents

• NSSS-DOC-0005Distributed Show Control Concepts
• NSSS-DOC-0006TrueNorth Network Design
• NSSS-DOC-0070.nsss.compose File Format

Revision History