Directory dependency graph for config:

Detailed Description

Configuration Files

This directory holds the DAQ server configuration. For the full flight-vs-ground configuration walkthrough (operational modes, sensor assignments, config structure), see ../docs/CONFIGURATION_GUIDE.md.

Files

File	Purpose
config.toml	Base config with all sections documented; the default dev config.
config_flight_daq.toml	Flight DAQ — flight sensors/actuators. Network 192.168.3.0/24.
config_ground_daq.toml	Ground DAQ — GSE sensors + hotfire. Network 192.168.2.0/24.
config_sitl.toml	Software-in-the-loop config.
system_config.json	Runtime system state snapshot.
state_transitions.csv	Allowed engine state transitions.
state_machine_actuators.csv	Actuator positions per state.
state_machine_actuator_delays.csv	Per-actuator delays applied on transitions.
countdown_state.json	Persisted countdown state.

Usage

# Ground DAQ (development / hotfire)
./build/bin/daq_bridge config/config_ground_daq.toml
 
# Flight DAQ (flight operations)
./build/bin/daq_bridge config/config_flight_daq.toml

During hotfire, set [hotfire].enabled = true in config_ground_daq.toml to route all sensors (including flight sensors) to the ground DAQ.

Board registry ([boards.*]) and DHCP

Each [boards.*] entry pins a board's ip (always 192.168.2.<board_id>) and board_id. It also carries a mac field:

[boards.pt_board]
ip  = "192.168.2.21"
mac = "aa:bb:cc:dd:ee:ff"   # lowercase, colon-separated; blank = no static lease yet
board_id = 21

mac is the single source of truth for the board's DHCP static reservation served by star-dhcp (../deploy/dhcp/README.md). A blank mac means the board has no reservation yet and will pull a dynamic-pool address — read its MAC from the lease table, fill it in here, and run deploy/dhcp/reload_dhcp.sh. The IP is handed out unchanged, so filling in mac never renumbers a board.

Running config vs the editor's draft

GET /api/config is the config editor's draft (the active profile). Everything that displays the stand reads GET /api/config/running: the file the pipeline is reading right now. That is config.toml, except in a simulated run, where the C++ services read the sim overlay built from config_base.toml (sim_config.toml; start_tmux_dev.sh with USE_SIM=1 passes it to the backend as RUNNING_CONFIG_PATH, a simulated session sets it for the run). The backend's own readConfig() defaults to the same file. Writes and deploys still target config.toml.

Ball valve boards

A motorized ball valve board is type = "BALL_VALVE" ([boards.ball_valve_board], board_id 71, disabled until it is on the stand). It drives two valves, connectors 1 and 2 (active_connectors = [ 1, 2 ]). Each valve is named in [actuator_roles] like any actuator — "Main Ball Valve" = ["NC", 1, 71], "Second Ball Valve" = ["NC", 2, 71] — and needs a row in each state CSV. A role's channel must be in active_connectors. Ball valves have no NO/NC; the GUI shows their position (% open / % closed) instead of a current. Board 71 shares slot 1 with actuator board 11 but has its own Elodin namespace (0x33-0x35), so the two never collide.

Ports (from config.toml)

5006 — sensor data (boards → bridge)
5005 — control/broadcast (bridge → boards: heartbeats, actuator commands)
2240 — Elodin DB

(The split config_*_daq.toml files set [system.network] bind_port = 5005.)