CaltechExperimentalGravity / CaltechExperimentalGravity/system_ident
Stage F: wire --cds (CLI, build_cds_backend, BACKENDS registry, mandatory channels.drive)
- Dominant language
- Python
- Stars
- 0
- Forks
- 1
- PR merge metrics
- No merged PRs in 30d
Description
**Stage F (spec §4, §6).** The backend exists but nothing can reach it. Note `--cds` currently
appears **exactly once in the whole repo** — in the roadmap note, as future work.
### `cli.py`
- Add `--cds`.
- Remove the hard refusal at [`src/system_ident/cli.py:62`](https://github.com/CaltechExperimentalGravity/system_ident/blob/feat/cds-hardware-backend/src/system_ident/cli.py#L62) ("the CDS-hardware backend is not
available yet").
- (`_confirm` and `--yes` are handled in the approval-gate issue.)
### `config.py`
- `build_cds_backend(...)` beside `build_twin_backend` ([`src/system_ident/config.py:144`](https://github.com/CaltechExperimentalGravity/system_ident/blob/feat/cds-hardware-backend/src/system_ident/config.py#L144)) and
`build_rtsfreerun_backend` ([`src/system_ident/config.py:162`](https://github.com/CaltechExperimentalGravity/system_ident/blob/feat/cds-hardware-backend/src/system_ident/config.py#L162)).
- A `BACKENDS` registry mirroring `ESTIMATORS` / `DESIGNERS` ([`src/system_ident/config.py:31`](https://github.com/CaltechExperimentalGravity/system_ident/blob/feat/cds-hardware-backend/src/system_ident/config.py#L31)), so
the backend choice stops being a pair of hard-coded booleans. Note `MIMOTwinBackend`, `ReducedPlantBackend`
and `DARMBackend` currently have **no config path at all** — they are constructed directly in
`experiments/` and tests. A registry is the place to fix that later.
- A `cds:` section — `transport: awg_nds | twin`, `start_buffer`, the site IFO key — validated in
`REQUIRED` ([`src/system_ident/config.py:37`](https://github.com/CaltechExperimentalGravity/system_ident/blob/feat/cds-hardware-backend/src/system_ident/config.py#L37)).
- **`channels.drive` mandatory for this backend — a `ConfigError`, not a warning.**
[`src/system_ident/loop.py:90`](https://github.com/CaltechExperimentalGravity/system_ident/blob/feat/cds-hardware-backend/src/system_ident/loop.py#L90) silently falls back to `exc[d]` and `_warn_open_drive_monitor`
([`src/system_ident/loop.py:274`](https://github.com/CaltechExperimentalGravity/system_ident/blob/feat/cds-hardware-backend/src/system_ident/loop.py#L274)) only warns. On hardware that fallback, combined with a synthesised
X, *is* the measured 200%-error configuration (see the `read()` invariants issue).
### New config
`src/system_ident/configs/cds_twin_transport.yml`, modelled on
[`src/system_ident/configs/rtsfreerun_hsts.yml`](https://github.com/CaltechExperimentalGravity/system_ident/blob/feat/cds-hardware-backend/src/system_ident/configs/rtsfreerun_hsts.yml) — which already has the right shape
(`channels.excitation/drive/readback`, `measurement.t_ramp`, `safety.actuator_sat`). Deliberately
**site-agnostic**: no 40m channel names, no `C1`. Site specifics are the deferred site-profile layer.
### Band guard
`warnings.warn` when `freq_max > 0.8 * (fs/2)`, explaining the cost is **SNR, not bias**. The sibling
project needed a hard `--f-max` because `scipy.signal.decimate` uses `cheby1(8, 0.05, 0.8/q)`, measured
−9.04 dB at 0.9·Nyquist and −22.37 dB at Nyquist; `resample_poly`'s Kaiser FIR is +0.02 dB at 0.8 and
−0.67 dB at 0.9, and being LTI and applied to both X and Y it **cancels exactly** in `Ybar/Xbar`. Record
that cancellation argument in the docstring — it is a second, independent reason X must never be a
synthesised array.
[`pyproject.toml:34`](https://github.com/CaltechExperimentalGravity/system_ident/blob/feat/cds-hardware-backend/pyproject.toml#L34) already reserves the `cds = []` extra; no change needed there.
---
**Campaign:** CDS hardware backend · branch [`feat/cds-hardware-backend`](https://github.com/CaltechExperimentalGravity/system_ident/tree/feat/cds-hardware-backend)
· [spec](https://github.com/CaltechExperimentalGravity/system_ident/blob/feat/cds-hardware-backend/docs/superpowers/specs/2026-08-03-cds-hardware-backend-design.md) · [plan](https://github.com/CaltechExperimentalGravity/system_ident/blob/feat/cds-hardware-backend/docs/superpowers/plans/2026-08-03-cds-hardware-backend.md) · [handoff](https://github.com/CaltechExperimentalGravity/system_ident/blob/feat/cds-hardware-backend/notes/cds-hardware-bringup-2026-08.md)
*Code is deferred until the plan and issues have been reviewed.*
Contributor guide
No contributing guide indexed for this repository
Research direction
Read the linked CDS design spec and plan first, then inspect cli.py, config.py, loop.py, and configs/rtsfreerun_hsts.yml. Trace the existing backend selection and channel validation entry points before implementing the --cds wiring, registry, configuration, mandatory drive validation, site-agnostic example, and band warning. Done means the CDS backend is selectable without the old refusal and all stated configuration and safety requirements are covered.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- backend, cli
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100