Stage A: fake CDS transport test harness (awg/cdsutils/gpstime stubs)
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 48/100
Research direction
Start by reading tests/test_rtsfreerun_backend.py around MockRTSModel, then create tests/_fake_cds.py as specified in the issue. Done means the AWG, getdata, and gpstime fakes expose the listed counters, controls, and failure modes, and the fake plant’s freqz matches the recovered loop FRF without real hardware or sleeping.
Written by the indexing model from the issue text.
Description
Stage A of the plan — unblocks every other issue in this campaign. Do this first.
Add tests/_fake_cds.py: sys.modules stubs for awg / cdsutils / gpstime. None of the three is
installed on the dev machine, so every CDS test must fake them. Model on the existing
MockRTSModel (tests/test_rtsfreerun_backend.py:35).
Required behaviours:
FakeArbitraryLoop— record(channel, array, rate, start, ramptime)and count construction,
startandstopat class level. Tests must be able to assert the loop was never constructed, not
merely that.startwas not called: a safety gate that constructs the object and then declines has
still reached the AWG API.FakeGetdata— return objects exposing.data/.sample_rate/.start_time, driving an
lfiltered plant, with a settable GPS offset so period misalignment is directly testable, plus
switches for short reads, gaps, and a missing channel.FakeGpstime— a controllable clock, so no test ever sleeps a realstart_buffer.
Self-test: the fake plant's freqz must match the FRF the loop recovers from it.
Why it comes first: both hard physics problems (spec §2) and the entire safety story are settled with
numbers on this harness, off-hardware, before any hardware time is requested.
Campaign: CDS hardware backend · branch feat/cds-hardware-backend
· spec · plan · handoff
Code is deferred until the plan and issues have been reviewed.
- Dominant language
- Python
- Stars
- 0
- Forks
- 1
- PR merge metrics
- No merged PRs in 30d
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from CaltechExperimentalGravity/system_ident
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 15/100
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 35/100
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 35/100
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 25/100
All issues in CaltechExperimentalGravity/system_ident
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 79/100
SACGF/variantgrid#2341 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 2 days
-
comp/cli P3 type/security
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
NousResearch/hermes-agent#141420 · 1 comment ·
Maintainers usually reply within 1 day
-
CKV_GCP_18 (GKEPublicControlPlane) passes when master_authorized_networks_config is absent, control plane is internet-reachablePossibly taken @Varshith-Kali claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
bridgecrewio/checkov#7753 ·
Maintainers usually reply within 1 day