Configuration

Every tunable parameter comes from one file, config/minscs.conf (override with $MINSCS_CONFIG; run_sim.sh exports an absolute path so all nodes read the same file). The loader is common/config.c; it runs in main() before the scheduler starts, so it carries none of the Posix port hazards.

1. The file

INI-style — [section] headers over key = value lines, # comments, one section per node:

[dhs]                        # platform-wide, held by the DHS
default_mode        = SAFE   # boot mode (compiled-in default is NOMINAL)
soc_resume_pct      = 50.0

[eps]                        # one section per subsystem
active_obc          = A      # primary on-board computer at boot
gauge_capacity_wh   = 45.0   # what the fuel gauge BELIEVES the cell holds
soc_low_pct         = 30.0
radio_science_a     = 0.40

[eps_dyn]                    # the simulated hardware, never database content
batt_capacity_wh    = 43.0   # what the cell ACTUALLY holds, faded from nameplate

[adcs]
bdot_gain           = 0.50   # detumble gain, A*m^2 per uT/s
pid_kp              = 48     # pointing gains

The two capacities above are the shape of a rule, not a duplication: an application’s belief and the plant’s fact stay separate keys in separate sections, or the estimator recovers the truth it’s supposed to be estimating. See eps.md §12.

Every lookup carries a built-in default, so a missing key — or the whole file — just leaves the compiled-in value in place and the platform still boots; the file tunes the mission rather than being a hard dependency. Each node logs the file it read and its effective values at boot:

[EPS    ] config: /path/to/config/minscs.conf (loaded)
[EPS    ] config: soc_low=30 soc_rec=45 soc0=82.0 gauge=45.0Wh ocv=26.0+3.4V tau=120s (rom defaults, awaiting the on-board database)

2. Only the DHS reads the mission parameters

The DHS loads the platform-wide [dhs] section into xSys, and loads every other section into the on-board database, which it then distributes over the bus. The four subsystems open the file only for their own board straps:

Everything else a subsystem needs arrives from the DHS. See obdb.md.

3. The file is the baseline, not the last word

The DHS’s own thresholds and its housekeeping-collection table are registered in the data pool as read-write parameters bound to the very fields loaded here — see The pool binds, it does not copy — and every other section becomes the on-board database. So the ground retunes any of it in flight with a service-20 telecommand, and the non-volatile mirror, not the file, carries that override across a reboot.

Note CFG_VALUE_LEN silently truncates a long value, which is why [dhs] nvram_file and obdb_file take a bare filename resolved against the config file’s directory (prvResolveCfgPath).

4. What belongs in the file, and what does not

Add a tunable by reading it via the xCfg/xSys table in the node’s main() with a built-in default. Add a distributable one by adding one DP_CFG_CATALOG row and one dpRegisterCfg call in the owning node.

5. Per-section reference

Each subsystem’s keys are documented with their semantics and defaults on its own page:

There is no consolidated key table across all sections; the per-node references above are the authority.