The web console (frontend/) is a React and TypeScript application that runs on your host and
talks to the board's REST API and WebSockets. It is not served by the board.
Running it#
cd frontend
npm install
VITE_API_URL=http://192.168.2.1:8080 npm run dev # development server on http://localhost:5173VITE_API_URL is the daemon's base URL (default http://localhost:8080); WebSocket URLs are
derived from it. For a static build:
VITE_API_URL=http://192.168.2.1:8080 npm run build # output in frontend/dist/
npm run preview # serve the build locallyThe board's shipped configuration allows every CORS origin, so the console works from any host.
If you run satlinkd yourself with the default configuration, only http://localhost:5173 is
allowed ([api] cors_origins).
Pages#
The sidebar has two groups. Keyboard shortcuts are shown next to each entry.
Operate#
| Page | Key | What it is for |
|---|---|---|
| Monitor | 1 | What the board is doing, nothing that changes it: the datapath flow diagram, PHY metrics (EVM, SNR/MER, lock, CFO, AGC gain), frame counters, the constellation, and the event log. Everything on it moves on its own |
| Radio | 2 | The RF front end: spectrum and waterfall, constellation, live metrics, RF status; LO frequency, NCO offsets, gains (RF and digital domains), the AD9361 rate, tuning, calibration and path (PL, device loopback, air) |
| Protocol | 3 | The live chain's framing and FEC registers as the board holds them, the received frame feed, and a link budget view |
| Scenarios | 4 | The scenario library and console: filter by tag, read a scenario's steps, run it, see its run history; open a run's live page; open the YAML editor |
| Bench | 5 | The hardware loopback measurement: tune the AD9361, pick a path, feed a payload while capturing, and compare byte for byte |
| System | 6 | Versions (release id, bitstream BUILD_ID), services, capabilities, PL status, the daemon log |
Library#
| Page | Key | What it is for |
|---|---|---|
| Profiles | P | Browse profiles, view one with the processing stages it actually enables, validate and apply it. The catalogue is re-read from the board each time the page opens |
| IQ Captures | I | Start, list, download and delete IQ captures |
| Reports | R | The index of finished runs; each report has its own address with events, assertions and the telemetry series, Export JSON and Re-run |
Scenario editor and run page#
- The editor (
/scenarios/new,/scenarios/<name>/edit) edits a scenario's YAML. Validation is done by the daemon (POST /api/v1/scenarios/validate), including whether every time can be parsed; saving usesPOST /api/v1/scenarios, which writes to the board's RAM disk (lost at reboot). - The run page (
/scenarios/runs/<run-id>) follows a run live through/ws/scenario-runs/<run-id>(events, samples and verdicts as they happen) and stays readable afterwards.
Header#
The header shows the active profile (flagged when it is dirty), the connection state, a light and dark theme switch, and the RF kill switch, which takes RF off the connector (see Hardware Setup).
What the console will not pretend#
The console displays what the daemon reports and labels what it cannot know:
- An empty spectrum means no real samples were available (analysis switched off, no capture
path, or a timeout), and says which. A synthesised spectrum only appears when the daemon runs
with
[monitor] synthetic_fft = true, and is labelled as such. - A report's charts are the run's own telemetry samples. A run with no sampler shows no series rather than a placeholder.
- Readings taken with nothing transmitted describe the silence:
agc_gainnear 16 and lock off is correct when no traffic flows.
Working without a board#
satlinkd can run on your host with a mock PL driver, which is enough to develop the console:
# from the repository root, so the relative dsl/ directories resolve
cargo run --manifest-path ps/Cargo.toml -p satlinkd -- --config ps/config/satlinkd.default.tomlThat configuration loads dsl/profiles and dsl/scenarios, serves on port 8080, and sets
mock = true: every register reads from an in-memory stub, telemetry is
marked stub, and nothing reaches hardware. Scenario assertions resting on stub samples are
reported not verified.