Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[deferred] Operator-answer gate + the six hardware-only unknowns, before any live injection

Open
  • Is something wrong?
#27 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
python
Domain
backend, embedded-iot

Research direction

Start with notes/40m-sos-campaign-handoff-2026-07.md Stage 5, notes/strategic-roadmap-2026-07-draft.md §Phase-C, and CLAUDE.md, then review the linked spec, plan, and bringup handoff. Work with authorized operators to answer the six hardware-only questions and record the results; done means every gate is resolved before any live-injection code or individual injection approval.

Written by the indexing model from the issue text.

Description

question

Component 2 — deferred. Enumerate and answer; write no live-injection code until then.

Operator questions

Already enumerated at notes/40m-sos-campaign-handoff-2026-07.md (Stage 5) and
notes/strategic-roadmap-2026-07-draft.md §Phase-C: exact optic and channel names; OSEM basis matrix,
counts↔N calibration and the DAC/coil limit; awg/nds2 GPS timing and fractional-sample drift; damping on vs
off and the stability margin with a comb near the UGF; Guardian / lock-state and abort-on-lock-loss; the
delivered-fit manifest and Foton drop-in. Pull the site foton bank at hardware time.

The six things no fake transport can settle

These are the genuinely hardware-only unknowns, and therefore exactly the human-gated set (spec §6):

  1. Whether awg 3.1.2 accepts the untapered integer-period array with ramptime start/stop semantics
    (the ramp-contract decision rests on this).
  2. Whether a channel's AWG slot is released after stop(), so a second ArbitraryLoop on the same
    channel succeeds rather than failing with "channel in use".
  3. Multi-channel common start_gps when inj.start(ramptime>0, wait=False) blocks until
    start_gps     — three loops started in a Python for loop leave loops 2 and 3 starting late, with their
    start_gps already past. Each individual FRF is still unbiased (X is a readback) but the drives are then
    not the synchronous simultaneous excitation the mode assumes, and the loop cannot tell. Candidate
    fix: start all with ramptime=0 at a common start_gps and ramp separately.
  4. Whether the _EXC channel is NDS-readable at this site — it is a testpoint rather than a recorded
    channel at many sites. The read() invariants depend on reading it back.
  5. getdata live short-read / gap behaviour under real conditions.
  6. Actual DAC counts against the design power budget.

Every one of these is gated by the hardware-safety rules in CLAUDE.md: only humans authorize, and
each individual injection needs separate approval.

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
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

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from CaltechExperimentalGravity/system_ident

All issues in CaltechExperimentalGravity/system_ident

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.