Document and optionally move train-envelope timing into Doric hardware sequencing
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 35/100
- Issue 类型
- 功能
- 描述清晰度
- 需要澄清
- 活跃度
- 停滞
- 技术栈
- python
- 领域
- embedded-iot
调研方向
首先使用GUI信号预览验证Doric Neuroscience Studio中的序列行为，然后阅读stim_controller.py和现有的时序文档。当软件端还是硬件端负责train-envelope的决策已记录、精确的config contract已定义，并且在选择硬件sequencing时已更新stim_controller.py时，工作即告完成。
由索引模型根据 Issue 内容生成。
描述
As of 2026-03-19, stimulation timing semantics need a clearer documented recommendation and a follow-up implementation decision.
Context
- The app currently uses Doric hardware for pulse shape (
period_ms,time_on_ms) but still enforces the train envelope (train.on_seconds,train.off_seconds) in Python timers. - Doric support clarified that the hardware-native mapping for a 20 Hz, 10 ms ON / 40 ms OFF pulse train with a 1 s ON / 3 s OFF envelope is:
period_ms = 50time_on_ms = 10nb_of_pulses_per_seq = 20delay_between_seq_ms = 3000nb_of_seq = 65535
- Doric also recommended validating sequence behavior in Doric Neuroscience Studio first, using the GUI signal preview before transferring settings into code via
ttlModulationand related DLL/API parameters.
Why this matters
- Sequence semantics are not obvious, especially for
nb_of_pulses_per_seq,delay_between_seq_ms,nb_of_seq, andGated + Restart. - Misunderstanding those fields can produce materially different stimulation behavior.
- If we want train envelopes to be hardware-timed, the controller should intentionally derive or honor those Doric sequence fields instead of relying on Python timers.
Current status
- Docs were updated locally to explain the timing split and to add a strong recommendation to validate waveform design in Doric Studio first.
- No runtime behavior was changed yet.
Follow-up questions
- Should
stimulus.train.*remain an app-level abstraction only, with explicitstimulus.square.*overrides for hardware-native sequencing? - Or should the controller derive Doric sequence parameters automatically from
stimulus.pulse.*+stimulus.train.*when the pattern is representable in hardware? - For closed-loop use, do we want hardware-native train envelopes by default, or only when a dedicated mode/flag is enabled?
Acceptance criteria
- Decide whether train OFF remains software-timed or moves to Doric-native sequencing.
- If moving to hardware, define the exact config contract and update
stim_controller.pyaccordingly. - Keep Doric Studio validation called out prominently in docs and operator workflow.
- 主要语言
- Python
- 星标
- 0
- 派生
- 1
- PR 合并指标
- 30 天内没有已合并 PR
环境准备
这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
matiasandina/uid_python_api 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 78/100
-
bug
难度 3/5 1-2 天 新手友好度 55/100
-
file cleanup未关闭
难度 5/5 一周以上 新手友好度 35/100
-
难度 5/5 一周以上 新手友好度 35/100
matiasandina/uid_python_api#14 · 3 条评论 ·
-
难度 4/5 3-5 天 新手友好度 45/100
matiasandina/uid_python_api#13 · 4 条评论 ·
查看 matiasandina/uid_python_api 的全部 Issue
相似的 Issue
-
bug status/needs-triage
难度 2/5 1-3 小时 新手友好度 86/100
prowler-cloud/prowler#12887 · 1 条评论 ·
维护者通常 1 天内回复
-
area: desktop platform: macos priority: p3 status: ready type: enhancement
难度 1/5 1 小时以内 新手友好度 92/100
use-agent-os/agent-os#3484 ·
维护者通常 2 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 86/100
open-telemetry/opentelemetry-python-contrib#5113 · 2 条评论 · 2 个 reaction ·
维护者通常 1 天内回复
-
external
难度 2/5 1-3 小时 新手友好度 68/100
langchain-ai/docs#6255 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 1 天内回复