- Generated by
1.15.0
|
STAR
Cal STAR — firmware, DAQ server, and engine design
|
Directories | |
| dhcp | |
The DAQ backend runs natively on the host as systemd --user services — not in Docker — because daq_bridge needs raw UDP to the test-stand boards. This is the same box that runs the Docker apps stack (/opt/STAR), and the Caddy container already proxies daq-server.<domain> to the native backend on the host (host.docker.internal:8081 for the API/WS and :3000 for the SPA, via extra_hosts: host-gateway). So once the native services are up on the host, the public URL just works — nothing to change in the Docker stack.
tmux vs systemd — read this first. The tmux panes you may have seen (deploy/startup/start_tmux_dev.sh) are the dev/laptop launcher only. On the server the DAQ runs as background systemd services; there are no tmux panes. The command that actually starts it is the systemctl --user enable --now … in Step 6 — everything before that is just clone/build/install. You watch it with journalctl, not tmux.
deploy/bootstrap_daq.sh does the whole thing in one shot: apt deps, Node 20, elodin-db (pinned to the CI-validated version and hard-verified), C++ build, SPA build, systemd unit install, and it enables + starts the web layer. It's idempotent — re-run it to update a box.
Fresh box / specific branch (it will clone if the repo isn't there yet):
Env knobs: BRANCH (default main), DAQ_CLONE (~/STAR-daq), REPO_URL, USE_SIM (0; 1 = build/run without hardware), START (1; 0 = build+install only, don't start).
Why this script (vs. the old setup.sh): it pins one elodin-db version matching CI, actually runs every step (no commented-out installs), and hard-verifies elodin-db — a box that can't run the DB fails loudly here instead of silently respawning sensor-elodin every 5 s later.
Before a real run, two host things to get right:
- Network + firewall: the board-LAN NIC must be statically 192.168.2.20/24 — the board firmware (firmware/Hotfire_Code/common/hotfire_config.h) hardcodes the server at 192.168.2.20:5006, so any other address silently drops all board traffic. Set it with nmcli/netplan (OS-level; the script can't). The host firewall must also allow inbound board UDP — bootstrap_daq.sh adds these automatically when ufw is active and the NIC is already on 192.168.2.20 (else run them by hand, substituting your board NIC):
sudo ufw allow in on enp4s0 from 192.168.2.0/24 to any port 5006 proto udp comment 'DAQ sensor data'sudo ufw allow in on enp4s0 from 192.168.2.0/24 to any port 5008 proto udp comment 'DAQ FSW config'- Config: config/config.toml is a generated artifact now; the source of truth is config/profiles/*.toml. Edit config via the GUI Config tab (it edits the active profile and deploys it); a live session-start deploys the active profile. Carrying a pre-existing config forward: save it as config/profiles/<name>.toml and echo <name> > config/.active_profile.
Combined apps + DAQ box: the apps-stack bootstrap can also pull the DAQ in:
The rest of this doc is the manual/reference version of the same steps (and what to do if a bootstrap run warns).
In the DAQ user's home, not /opt:
Clone wherever you like in that home — install_services.sh writes a systemd drop-in that points every unit's WorkingDirectory at wherever you cloned, so no symlink is needed. This doc uses ~/STAR-daq; the DAQ lives in its daq-server/ subdir.
Run every step below as the DAQ user (no sudo) except the apt-get prereqs — the --user services, home-rooted paths, and enable-linger all key off that user. Every DAQ command runs from ~/STAR-daq/daq-server.
--depth 1 grabs only the tip of main (no history). Full tree (not sparse), so all current file contents — including the repo-root lib/ that the C++ build reaches via ../lib — are present up front. Works on an air-gapped test-stand with no further fetches.
All three of these are required — run each (the bootstrap_daq.sh path above does them for you):
If elodin-db is missing, sensor-elodin now fails immediately and visibly (AssertPathExists), and a session start is rejected rather than reporting a phantom "saved" run. On ARM64/Jetson the prebuilt installer won't work (musl-only) — use deploy/setup/setup_jetson.sh (builds it from source).
Binaries land in build/bin/ (what the units resolve as ./build/bin/<name>).
This symlinks the unit files into ~/.config/systemd/user/ and writes a …/<unit>.service.d/workdir.conf drop-in setting WorkingDirectory to your checkout (~/STAR-daq/daq-server), then reloads the daemon. No ~/sensor_system symlink involved.
If the boards get their IPs over DHCP instead of hardcoded firmware, install the board-LAN DHCP service. Unlike the --user units above, this is a root system unit (DHCP needs port 67):
It installs dnsmasq, generates the config from [boards.*], and enables (but does not start) star-dhcp.service. See deploy/dhcp/README.md for the full onboarding flow (discover a board's MAC from the lease table → add it to the config → reload).
sensor-video is the VIDCOMM video gateway (MediaMTX, scripts/video-gateway.sh): the Video view plays from it. It is independent of the backend – restarting either leaves the other running – and needs inbound UDP 8189 open to the LAN for browsers to get video.
That's the start. The services are now running in the background.
bash: scripts/build.sh: No such file or directory — you're in the repo root (~/STAR-daq) instead of the daq-server dir. cd ~/STAR-daq/daq-server first; every DAQ command in this doc runs from there.
1.15.0