update

2026-02-23 19:24:38 +08:00 · 2026-01-22 20:42:07 +08:00 · 2026-01-22 20:41:54 +08:00 · 2026-01-20 11:47:49 +08:00 · 2026-01-19 15:56:14 +08:00 · 2026-01-17 21:59:04 +08:00
28 changed files with 14315 additions and 194 deletions
@@ -0,0 +1,335 @@
 ====================
 人工输入（2026-01-16）
 我的windows11电脑遇到了一个非常偶发的卡死问题，接下来你需要和我一起尝试定位解决这个问题。你需要把你的发言也记录在这篇文档内，以便后续查阅。
 以下是我遇到的问题以及我尝试过的解决方案
 我的电脑是一台联想拯救者刃9000k 2023，搭载RTX 4090, i9-13900KF
 最近半年左右，电脑会偶发的出现黑屏卡死的问题。表现为，从睡眠/休眠/息屏状态下敲击键盘或者移动鼠标尝试唤醒的时候，有一定概率会卡在正在锁定的界面上。此时画面会完全卡死，双屏显示器中，主显示器卡在正在锁定的转圈界面，副显示器直接失去信号输入。
 此时，键盘的Caps Lock键是没有反应的（正常状态下Caps Lock键应该按下以后会显示是否开启大写锁定，所以我认为这可能是一个重要的信号，但我不知道这意味着什么）
 在这个状态下如果我不做任何操作，电脑会一直卡死在这个状态下，电脑上安装的机械硬盘持续仍然在工作，风扇也在转，但是不会有任何响应。唯一的方法就是长按电源键强制重启
 在强制重启完成以后查看windows事件查看器，找不到任何有用的信息，只能看到一个非正常关机的报错。
 我当前尝试过的操作包括：
 1. 关闭了快速启动
 2. 把我的windows版本更新到了最新版本
 3. 重装了电源管理驱动
 4. 在卡死状态下通过长按win+ctrl+shift+B尝试重启显卡驱动，没有成功
 在卡死状态下，尝试通过windows自带的远程桌面进入系统，会一直卡在正在配置远程电脑这一步，看起来像是初始的网络连接已经建立成功，但是电脑在某个阶段没有响应导致一直卡在这里。我之前遇到过一次，还没有卡死的情况下直接远程到这台电脑，成功建立远程连接，然后我关闭远程连接，尝试将其从息屏状态下唤醒，就卡死了，然后再尝试远程桌面，就卡在配置远程电脑这一步了
 因为这个卡死是一个偶发的问题，我也不能100%复现，所以非常头疼，我需要你的帮助
 ====================
 AI记录（2026-01-22）
 已阅读当前文档内容：目前记录仅包含 2026-01-16 的一次人工描述与已尝试措施。现问题“刚刚又出现一次”，但文档尚未记录本次复现的时间点、当时电源状态（睡眠/休眠/仅息屏）、以及是否有新增的系统日志/症状。
 初步判断要点（基于已有描述）：
 1) “Caps Lock 无反应”通常意味着系统在更底层已失去调度（可能为内核/驱动级卡死），而不仅是图形界面假死；也可能是输入堆栈/中断被阻塞。
 2) 副屏无信号 + 主屏停在锁屏转圈，且 Win+Ctrl+Shift+B 无法恢复，提示可能涉及：显卡驱动/显示链路在唤醒路径失败、Modern Standby/睡眠唤醒路径中的设备电源状态切换异常、或某个内核驱动死锁。
 3) 远程桌面“正在配置远程电脑”卡住，说明网络握手可能建立，但目标机在登录/会话初始化阶段无响应（与系统级卡死一致）。
 下一步目标：把“偶发”变成“可定位”，优先收集一次卡死前后 5~10 分钟的可关联证据。
 A. 立刻补充的记录项（请在每次发生后追加到本文档）
 - 发生时间（精确到分钟）
 - 发生前状态：睡眠/休眠/仅关闭显示器/锁屏后待机（以及持续了多久）
 - 唤醒方式：键盘/鼠标/电源键/定时器/网络唤醒
 - 现象细节：主屏内容、分辨率是否变化、副屏是“无信号”还是黑屏有背光
 - 机器指示：键盘灯、NumLock/CapsLock、机箱电源灯、硬盘灯、风扇转速是否明显变化
 - 是否插拔过外设/USB扩展坞/VR设备/采集卡等
 B. 建议立刻做的“取证型设置”（为下一次复现做准备）
 1) 启用/检查系统转储（用于驱动/内核死锁分析）
   - 系统属性 → 启动和故障恢复：写入调试信息建议至少“自动内存转储”（或“内核内存转储”）。
   - 确认页面文件存在且足够（通常需位于系统盘）。
 2) 可靠性监视器定位崩溃/硬件错误线索
   - 查看“可靠性历史记录”，重点关注：Windows 错误报告、硬件错误（WHEA）、显示驱动重启等。
 3) 事件查看器重点频道（下次按时间点回溯）
   - Windows 日志：系统（Kernel-Power 41、BugCheck、Display、WHEA-Logger）
   - 应用程序和服务日志：Microsoft-Windows-Kernel-PnP/Configuration、Power-Troubleshooter
 4) 生成/保存电源与唤醒报告（事后分析用）
   - powercfg /systemsleepdiagnostics（睡眠诊断）
   - powercfg /sleepstudy（如果设备支持 Modern Standby）
   - powercfg /lastwake（最近一次唤醒来源）
 C. 下一次卡死时（在保证安全前提下）可尝试的操作（按优先级）
 1) 等待 60~120 秒观察是否自动恢复（某些驱动超时会自行回滚）。
 2) 若键盘仍有响应：尝试 Ctrl+Alt+Del（看是否能切到安全桌面）。
 3) 仍无反应：记录现象后再强制重启（避免反复硬断电）。
 D. 需要你立刻回答的 6 个关键问题（用于缩小范围）
 1) “刚刚那次”发生前，电脑处于：睡眠/休眠/仅息屏/锁屏？
 2) 你是否使用了 HDR、G-Sync/VRR、多显示器不同刷新率（例如 4K144 + 2K60）？
 3) 显示器连接方式：HDMI/DP？是否有 DP 线材/转接头/延长线？
 4) BIOS 与显卡驱动版本（大概即可），以及是否开启了 HAGS（硬件加速 GPU 调度）？
 5) 是否开启了“允许网络唤醒/USB唤醒/快速启动/现代待机”中的任何一项（快速启动已关闭，其他待确认）？
 6) 强制重启后，“可靠性监视器”在对应时间点是否出现硬件错误或显示驱动相关条目？
 （后续计划）
 - 若能拿到一次 BugCheck/转储文件：优先走“驱动/死锁”方向。
 - 若完全没有 BugCheck 且仅 Kernel-Power 41：优先走“睡眠唤醒链路/BIOS/显示链路/电源策略”方向，并通过 powercfg 报告与事件日志交叉验证。
 ====================
 ====================
 人工输入（2026-01-22）
 刚刚的这次卡死，
 A.
 - 发生在2026年1月22日晚上20点28分。
 - 发生前的状态是正在从休眠中唤醒，之前休眠了大约24小时。
 - 唤醒的方式是通过电源键。
 - 主副屏分辨率都没有发射变化。副屏幕是亮起来了一小下，然后就变成无信号输入了。主屏出现了正在锁定的转圈，但是连转圈都卡死了
 - 键盘灯亮起，CapsLock键没有反应，机箱电源灯常亮，硬盘灯持续闪烁，风扇转速没有明显变化
 - 没有插拔过任何外设
 B.
 1) 系统转储已经启用，设置为自动内存转储
 2) 可靠性历史记录中记录了如下信息：
 <Event>
 <Time>2026-01-22T20:31:28.420</Time>
 <Impact>关键</Impact>
 <Source>Windows</Source>
 <Problem>Windows 停止工作</Problem>
 </Event>
 <Event>
 <Time>2026-01-22T20:31:29.531</Time>
 <Impact>关键</Impact>
 <Source>Windows</Source>
 <Problem>Windows 未正常关闭</Problem>
 </Event>
 3) 事件查看器节选以下记录：
 2026/1/22 20:26:40 信息 系统启动时间为 413599 秒。
 2026/1/22 20:26:41 警告 发生了已更正的硬件错误。 组件: PCI Express Root Port 错误源: Advanced Error Reporting (PCI Express)
 2026/1/22 20:26:41 信息 系统会话已从10转换为 11. 原因 SxTransition  BootId： 32
 2026/1/22 20:26:42 警告 NtpClient 无法将手动对等机设置为用作时间源，因为“time.windows.com,0x9”上出现 DNS 解析错误。NtpClient 将在 15 分钟后重试，此后重试间隔增加一倍。错误为: 不知道这样的主机。 (0x80072AF9)
 2026/1/22 20:26:43 信息 系统会话已从11转换为 13.
 2026/1/22 20:27:53 错误 服务器 Microsoft.YourPhone_1.25112.36.0_x64__8wekyb3d8bbwe!App.AppXn958k7nsj8mxxmsepqdam8xk948t30sc.mca 没有在要求的超时时间内向 DCOM 注册。
 2026/1/22 20:27:53 错误 服务器 Microsoft.BingWeather_4.54.63029.0_x64__8wekyb3d8bbwe!App.AppXydmptpzm8pts0mhzrytvzy52ye9x3ttq.mca 没有在要求的超时时间内向 DCOM 注册。
 2026/1/22 20:27:53 错误 服务器 Microsoft.WindowsStore_22511.1401.6.0_x64__8wekyb3d8bbwe!App.AppXbes12ecwhvvewxbmkmnasc9amnxfsx1c.mca 没有在要求的超时时间内向 DCOM 注册。
 2026/1/22 20:27:53 错误 服务器 Microsoft.WindowsFeedbackHub_1.2512.16303.0_x64__8wekyb3d8bbwe!App.AppX8a6w88secebzyje9nrqc47xt488tkbmc.mca 没有在要求的超时时间内向 DCOM 注册。
 2026/1/22 20:27:53 错误 服务器 Microsoft.XboxGamingOverlay_7.325.11061.0_x64__8wekyb3d8bbwe!App.AppXpa8c6rgd3yzmnwb7kznbz0y2c2tmedk3.mca 没有在要求的超时时间内向 DCOM 注册。
 2026/1/22 20:27:53 错误 服务器 MicrosoftWindows.Client.OOBE_1000.26100.28.0_x64__cw5n1h2txyewy!OobeHost.AppX57bnpdhb2y2keeh7gnjg18wys2747njp.mca 没有在要求的超时时间内向 DCOM 注册。
 2026/1/22 20:28:18 错误 服务器 {338B40F9-9D68-4B53-A793-6B9AA0C5F63B} 没有在要求的超时时间内向 DCOM 注册。
 2026/1/22 20:29:51 信息 NIC C08CB7B8-9B3C-408E-8E30-5E16A3AEB445 successfully disconnected from port .
 2026/1/22 20:29:53 错误 服务器 Microsoft.AAD.BrokerPlugin_1000.19580.1000.2_neutral_neutral_cw5n1h2txyewy!Windows.Security.Authentication.Web.Core.BackgroundGetTokenTask.ClassId.WebAccountProvider 没有在要求的超时时间内向 DCOM 注册。
 2026/1/22 20:31:12 信息 操作系统已在系统时间 2026-01-22T12:31:11.500000000Z 启动。
 2026/1/22 20:31:28 错误 计算机已经从检测错误后重新启动。检测错误: 0x00000133 (0x0000000000000001, 0x0000000000001e00, 0xfffff801d8bc43b0, 0x0000000000000000)。已将转储的数据保存在: C:\WINDOWS\Minidump\012226-17125-01.dmp。报告 ID: 2d9c5441-44b1-4552-a0ea-3ff739039cbd。
 注意：012226-17125-01.dmp文件我已经保存到同目录下了。
 4)
 - powercfg /systemsleepdiagnostics: 系统睡眠诊断报告已弃用且替换为系统电源报告。请改用命令 "powercfg /systempowerreport"。
 - powercfg /systempowerreport: 已生成报告，保存到了同目录下的sleepstudy-report.html
 - powercfg /sleepstudy: 已生成报告，保存到了同目录下的sleepstudy-report.html
 - powercfg /lastwake: 唤醒历史记录计数 - 0
 C.
 1) 这次卡死后我一直等待，系统自动重启了，然后正常进入了系统
 2) 键盘完全没有任何响应
 D.
 1) 电脑处于休眠状态
 2) 没有使用HDR，G-Sync/VRR，多显示器不同刷新率
 3) 显示器连接方式是主显示器通过DP连接，副显示器通过HDMI连接，没有使用任何转接头
 4) BIOS版本是最新的，显卡驱动版本是581.57，开启了HAGS
 =====================
 ====================
 AI记录（2026-01-22）
 我已读到你在文档里补充的 2026-01-22 这次复现细节与日志，关键信息很明确了：
 触发路径：休眠 24 小时 → 按电源键唤醒 → 卡在“正在锁定”转圈且转圈也停住；副屏短暂亮后变为无信号；键盘完全无响应（Caps/Num 都不行）。
 结果：你这次没硬重启，而是系统随后自动重启。
 事件里最重要的一条是：BugCheck 0x00000133，并且已生成小转储：C:\WINDOWS\Minidump\012226-17125-01.dmp（你已拷贝到工作目录同级）。
 同一时间段还出现：“已更正的硬件错误：PCI Express Root Port / AER”（这是非常有价值的线索）。
 powercfg /lastwake 为 0（不意外：休眠恢复路径+非正常重启后，lastwake 往往拿不到可用记录）。
 你还确认：NVIDIA 581.57 + HAGS 开启，无 HDR/G-Sync/VRR，主 DP 副 HDMI，无转接头。
 基于这些，我的判断优先级变了：这已经不只是“黑屏卡死”，而更像 休眠恢复过程中某个驱动在高 DPC/ISR 下卡死或超时，最终触发 DPC_WATCHDOG_VIOLATION（0x133）。同时出现的 PCIe Root Port AER 更正错误提示：可能存在 PCIe 链路在低功耗/唤醒转换时不稳定（常见相关方：显卡/主板 PCIe、某些 NVMe、以及电源管理/BIOS/ASPM）。
 接下来我建议走“两条线并行”，但都尽量做“可回退、改动小”的验证：
 1) 先把转储分析出来（定性：到底卡在哪个驱动）
 你已经有 012226-17125-01.dmp，这是最关键证据。下一步我可以在你这个工作区里做自动化解析，但需要先确认你希望用哪种方式：
 如果你机器上已装 WinDbg（预览版/商店版），我们可以直接用它出 !analyze -v 结果；
 如果没装，我也可以帮你在文档里生成一套最短安装与分析流程（不需要你手动猜命令）。
 为了避免你来回复制粘贴，我建议：我来直接在工作区新增一个 “dump 分析脚本/README”，把步骤固化下来。你确认后我就做。
 2) 同时做 2 个最小化“排除项”（不改硬件、不大动系统）
 这两个改动的目的：验证是不是“GPU 调度/休眠恢复链路”导致的 0x133。
 A. 先关闭 HAGS（强烈建议先试） 你已确认 HAGS 开启；HAGS 在部分驱动版本+多显示器+休眠恢复组合下，确实更容易触发卡死/0x133（不是必现，但与你现象吻合）。
 验证方式：仅关闭、重启、观察下一次休眠唤醒。
 B. 暂时禁用休眠（只为验证链路），改用“睡眠/仅息屏”一段时间 因为这次明确发生在“休眠恢复”。如果禁用休眠后现象明显消失，就能把范围锁在“hiber + 驱动恢复路径”。
 这不一定是最终方案，但对定位很有用。
 你日志里另一条关键：PCIe Root Port AER “已更正”错误
 这类错误即使“已更正”，也常常意味着链路质量/省电策略/设备固件存在抖动。后续我们会重点看：
 错误对应的 设备实例路径/端口号（事件详情里能看到具体 Root Port，能映射到某个 PCIe 设备）
 Sleepstudy 报告里是否出现某个设备在进入/退出低功耗时异常（你给我的 html 目前只读到开头样式部分，还没读到数据段；需要我继续往下定位“设备/会话/错误”章节）
 我需要你补 2 个信息（都跟“PCIe/AER”和“dump 定位”强相关）
 事件查看器里那条“PCI Express Root Port / AER”的事件详情（复制“常规”里更完整内容，尤其是端口/总线/设备/功能号，或“设备实例路径”字段）。
 你是否愿意让我接下来直接读取并分析工作区里的 copilot_workspace/repair/012226-17125-01.dmp，然后把分析结论追加写回记录文档（会包含可能的“故障模块/驱动名”与建议下一步）。
 只要 dump 能指向具体驱动（例如显示、存储、网卡、某个滤镜驱动），我们就能把排查从“猜”变成“改动—验证—收敛”。
 ====================
 ====================
 AI记录（2026-01-22）- WinDbg分析结论（012226-17125-01.dmp）
 用户提供的 WinDbg `!analyze -v` 关键结论：
 - BugCheck：0x133 DPC_WATCHDOG_VIOLATION
  - P1=1（系统累计在 DISPATCH_LEVEL 或更高 IRQL 停留时间过长）
  - DPC_TIMEOUT_TYPE：DPC_QUEUE_EXECUTION_TIMEOUT_EXCEEDED
 - Failure.Bucket：`0x133_ISR_nvlddmkm!unknown_function`
 - 栈：在时钟中断/ISR 路径内触发，顶层第三方模块为 `nvlddmkm.sys`（NVIDIA 显卡内核驱动）
 - 提示信息：`*** WARNING: Unable to verify timestamp for nvlddmkm.sys`
  - 这通常不等同于“驱动必然损坏”，常见原因包括符号/时间戳验证不可用；但结合栈与 Bucket，显卡驱动在 ISR/DPC 路径异常超时的可能性很高。
 - 环境：Hypervisor 标志为 1（系统启用了 Hyper-V/虚拟化相关能力；可能来自 Hyper-V、WSL2、VBS/内存完整性等）。
 基于上述结论的优先排查顺序（从“改动最小、收益最大”开始）：
 1) 立即关闭 HAGS（硬件加速 GPU 调度）并复测
 - 你的环境此前已确认 HAGS=开启；0x133 + nvlddmkm ISR 的组合下，优先把 HAGS 作为第一可回退变量。
 - 目标：观察“休眠→唤醒”在相同使用场景下是否不再触发卡死/自动重启。
 2) 显卡驱动做一次“干净重装”或回退一个稳定版本
 - 当前版本：NVIDIA 581.57。
 - 建议路径：
  - A) 先尝试回退到一个你历史上稳定的 WHQL 版本（减少回归风险）。
  - B) 或使用 DDU（安全模式）做一次完全卸载后再安装（可排除升级残留/组件损坏）。
 - 同时建议暂时禁用：GeForce Experience Overlay / Xbox Game Bar / 第三方叠加层（只作为验证变量）。
 3) 检查虚拟化相关功能（Hyper-V / VBS）对显示驱动路径的影响（仅做验证）
 - WinDbg 显示 Hypervisor.AnyHypervisorPresent=1。
 - 若你确实启用了 Hyper-V/WSL2/内存完整性(VBS/HVCI)：
  - 建议选择一个窗口期做 A/B Test：临时关闭其中一项（尤其是“内存完整性/核心隔离”）后复测“休眠→唤醒”。
  - 目的：排除虚拟化安全特性对 GPU 调度/中断路径的放大效应。
 4) 结合此前事件中的 “PCIe Root Port / AER 已更正硬件错误” 做链路侧验证
 - 0x133 指向表现层（nvlddmkm ISR/DPC 超时），AER 指向底层链路（PCIe 纠错）。两者可同源：唤醒时 PCIe 链路抖动→驱动 ISR/DPC 被拖死。
 - 建议：
  - 在 BIOS/电源计划中，优先检视与 PCIe 省电相关选项（如 ASPM/Link State Power Management）。先“仅做一次调整并复测”，避免多变量同时变化。
  - 下一次出现 AER 时，把事件查看器中该条目的“详细信息”（端口/总线/设备/功能号）记录下来，以便映射到具体设备（GPU/NVMe/网卡等）。
 5) 若仍复现：升级取证等级
 - 将转储类型从“小型转储”提升为“内核内存转储”（若当前并非内核转储），以便拿到更完整的 DPC/ISR 上下文（代价是 dump 更大）。
 - 若能稳定抓到更完整 dump，再根据 `!analyze -v`、`lmvm nvlddmkm`、以及相关黑盒（blackboxpnp/winlogon/ntfs）进一步收敛。
 （当前阶段结论）
 - 这次卡死/自动重启并非“纯黑屏无日志”，而是已明确落到：`0x133 + nvlddmkm.sys ISR/DPC 超时`。
 - 因此后续排查应优先围绕：HAGS/驱动版本与安装完整性/叠加层/虚拟化安全特性/PCIe 省电与链路稳定性。
 ====================
 人工输入（2026-01-22）
 - 已关闭 HAGS（硬件加速 GPU 调度），准备观察对“休眠→唤醒”卡死/0x133 的改善效果。
 ====================
 AI记录（2026-01-22）- 关闭 HAGS 的影响与验证方案
 关闭 HAGS 可能带来的影响（总体：更保守、更兼容）：
 1) 性能/延迟：
   - 大多数日常使用无感。
   - 少部分游戏/高帧率场景可能出现极小的延迟上升或帧时间波动变化，也可能完全无差异。
 2) 稳定性：
   - 在本案已明确为 `0x133_ISR_nvlddmkm`（显卡驱动 ISR/DPC 超时）的前提下，关闭 HAGS 属于高收益、低风险的 A/B 验证变量，目标是降低休眠唤醒路径触发概率。
 3) 兼容性：
   - 不影响显卡基本功能、多屏、分辨率/刷新率设置；属于可随时回退的系统级开关。
 验证方式（建议固定变量，避免混杂）：
 - 在驱动版本、外设、显示模式不变的情况下，复测“长时间休眠（例如隔夜）→电源键唤醒”若干次。
 - 若再次出现卡死/自动重启：
  - 记录发生时间点；
  - 检查是否再次生成 0x133 dump；
  - 同步查看是否仍伴随 PCIe Root Port/AER 的“已更正硬件错误”。
 回退与下一步：
 - 若关闭 HAGS 后明显改善：维持关闭状态，并继续观察一段时间确认稳定。
 - 若关闭 HAGS 后仍复现：进入下一优先级——显卡驱动“干净重装/回退稳定版”（必要时 DDU），并考虑临时关闭叠加层与虚拟化安全特性做 A/B Test。
 ====================
 人工输入（2026-02-14）
 - 今天又一次出现了类似的错误。
 - 上一次因为等不下去直接强制重启，因此没有产生新的 .dmp 文件。
 - 这一次等待系统自己重启，已产生新的 .dmp 文件（待进一步分析定位）。
 - 已确认 HAGS（硬件加速 GPU 调度）已经关闭。
 - 下一步：继续分析新产生的 dmp 与相关日志。
 ====================
 ====================
 AI记录（2026-02-14）- 本轮取证计划（等待用户提供日志分析结果）
 1) 先固化证据：
   - 新生成的 dmp 文件请复制/保存到工作区（建议放在：copilot_workspace/repair/ 目录），并记录原始路径（通常为：C:\Windows\Minidump\*.dmp 或 C:\Windows\MEMORY.DMP）。
   - 同步记录本次复现的关键信息：发生时间、触发前电源状态（睡眠/休眠/息屏）、唤醒方式、是否多显示器、是否出现 PCIe Root Port/AER 已更正硬件错误、是否出现 BugCheck 事件。
 2) 为避免“强制重启导致无 dmp”：
   - 若再次卡死且可以等待，尽量等待系统自动重启（或触发蓝屏）以生成转储。
 3) 待用户提供：
   - 新 dmp 的 WinDbg `!analyze -v` 结果（或把 dmp 放到工作区我来解析）。
   - 事件查看器中对应时间窗口（前后 10 分钟）的关键条目：BugCheck、WHEA-Logger、Display、Kernel-Power、PCIe/AER。
 ====================
 ====================
 AI记录（2026-02-14）- WinDbg分析结论（021426-11890-01.dmp）
 用户提供的 WinDbg `!analyze -v` 关键结论：
 - FILE_IN_CAB：021426-11890-01.dmp
 - BugCheck：0x133 DPC_WATCHDOG_VIOLATION
  - P1=1（系统累计在 DISPATCH_LEVEL 或更高 IRQL 停留时间过长）
  - P2=0x1e00（watchdog 周期 tick）
  - DPC_TIMEOUT_TYPE：DPC_QUEUE_EXECUTION_TIMEOUT_EXCEEDED
 - Failure.Bucket：`0x133_ISR_nvlddmkm!unknown_function`
 - 堆栈：在时钟中断/ISR 路径内触发，第三方栈顶持续指向 `nvlddmkm.sys`（NVIDIA 显卡内核驱动）
  - 本次偏移：`nvlddmkm+0x267e6a`（同时栈中出现 `nvlddmkm+0x168495` 等）
 - 仍出现提示：`*** WARNING: Unable to verify timestamp for nvlddmkm.sys`
 - Hypervisor 标志仍为 1（RootFlags.IsHyperV=1）：系统处于启用 Hyper-V/虚拟化相关能力状态（可能来自 Hyper-V、WSL2、VBS/内存完整性 等）。
 与 2026-01-22 的对比结论：
 - 即使已关闭 HAGS，本次依然复现同类 0x133，并且 Bucket 仍为 nvlddmkm ISR 超时。
 - 说明 HAGS 不是唯一触发条件；需要把排查重点转向：显卡驱动安装/版本、叠加层与内核组件、虚拟化安全特性、以及 PCIe 链路/省电策略（与先前 AER 线索可能同源）。
 下一步建议（按优先级，尽量一次只改一个变量）：
 1) 显卡驱动“干净重装/回退稳定版”（优先级最高）
   - 使用 DDU（安全模式）彻底卸载 NVIDIA 驱动后重装。
   - 若当前为较新分支版本：建议回退到一个更成熟的 WHQL 版本做 A/B（以稳定为目标）。
   - 同时禁用可能注入/叠加的组件做验证：GeForce Experience Overlay、Xbox Game Bar、Discord/Steam/NVIDIA overlay、录屏/监控类工具（只作为排除变量）。
 2) 虚拟化相关能力做 A/B 验证（针对 Hypervisor 标志=1）
   - 若你开启了“内存完整性/核心隔离（HVCI）”、Hyper-V、WSL2：选择其中一项在可控窗口期临时关闭后复测“休眠→唤醒”。
   - 目的：验证虚拟化/安全内核是否放大了 GPU ISR/DPC 触发概率。
 3) 继续跟踪 PCIe/AER（若事件里仍出现“PCI Express Root Port / AER 已更正硬件错误”）
   - 把对应事件的“详细信息”记录下来（总线/设备/功能号/设备实例路径），用于映射到具体硬件（GPU/NVMe/网卡等）。
   - 后续再决定是否调整 PCIe 省电策略（ASPM/Link State Power Management）做验证。
 4) 提升转储取证能力（若仍频繁复现）
   - 将转储类型调整为“内核内存转储”（或完整内存转储），以便拿到更完整的 DPC/ISR 上下文与相关对象信息（代价：dump 文件更大）。
 待补充信息（用于下一轮收敛）：
 - 本次复现发生前的电源状态：睡眠/休眠/仅息屏？持续多久？唤醒方式？
 - 本次对应时间窗口是否仍有 WHEA-Logger / PCIe Root Port AER 的日志（若有请粘贴事件详情）。
 ====================
 ====================
 人工输入（2026-02-14）- 补充：触发条件 & 事件日志
 - 本次复现前：从“休眠”状态唤醒。
 - 唤醒方式：电源键。
 事件查看器摘要：
 1) 11:31:47 警告：发生了已更正的硬件错误（AER）
   - 组件：PCI Express Root Port
   - 错误源：Advanced Error Reporting (PCI Express)
   - 主总线:设备:函数：0x0:0x1C:0x4
   - 辅助总线:设备:函数：0x0:0x0:0x0
   - 主要设备名称：PCI\VEN_8086&DEV_7A3C&SUBSYS_376A17AA&REV_11
 2) 11:33:38 错误：nvlddmkm 事件 ID 153（本机缺少描述/消息表）
   - \Device\00000244
   - Resetting TDR occurred on GPUID:100
 3) 11:38:00 错误：系统意外关机（上一次 11:35:55）
 ====================
 ====================
 AI记录（2026-02-14）- 组合证据解读 & 下一步收敛
 本次新增的关键点在于：
 - 休眠唤醒路径中先出现 PCIe Root Port 的 AER“已更正硬件错误”（指向 PCIe 链路/电源状态切换抖动）。
 - 随后出现 nvlddmkm 的 TDR 重置记录（GPU 超时检测与恢复），并且 dump 里仍然是 0x133 ISR nvlddmkm。
 => 这三者组合更像“GPU 在唤醒/链路恢复阶段出现响应异常（可能被 PCIe 链路错误/省电策略放大）→ 触发 TDR → 最终在 ISR/DPC 路径上超时导致 0x133”。
 下一步建议（只改一项就复测，避免混杂变量）：
 1) 优先：NVIDIA 驱动做一次 DDU 干净重装 + 回退到稳定 WHQL 版本做 A/B
   - 目标：排除驱动升级残留/组件损坏，并验证是否为特定分支回归。
 2) 叠加层/注入类组件最小化（仅作为验证变量）
   - 临时关闭：NVIDIA/GeForce Experience Overlay、Xbox Game Bar、以及常见第三方 Overlay/监控/录屏（如有）。
 3) 虚拟化/安全内核 A/B（dump 中 Hyper-V 标志一直为 1）
   - 若启用了“内存完整性(HVCI)/核心隔离”、Hyper-V、WSL2：选一项在可控窗口期临时关闭复测。
 4) PCIe 省电策略验证（基于 AER Root Port 线索）
   - Windows 电源计划中把“PCI Express → 链路状态电源管理”临时设置为“关闭”做 A/B。
   - BIOS 中若存在 ASPM/PCIe 电源相关选项，可在确认当前值后，仅改动一次做验证。
 需要进一步补齐的定位信息（用于把 AER Root Port 映射到具体设备）：
 - 请补充该 AER 事件的“详细信息”完整 XML（或至少包含：Port/Device Instance Path/Segment/Bus/Device/Function 的字段），以便确认该 Root Port 下挂设备是不是 GPU（或 NVMe/网卡等）。
 - 另外建议在 WinDbg 中对该 dump 执行：`lmvm nvlddmkm`（记录驱动具体版本/时间戳信息，避免仅凭版本号猜测）。
 ====================
@@ -0,0 +1,51 @@
 ?? ID:                USB\ROOT_HUB30\5&323bdd91&2&0
 ?? ID:                HID\VID_046D&PID_C548&MI_02&Col02\7&3196e441&0&0001
 ?? ID:                HID\VID_276D&PID_2233&MI_02&Col01\7&24b33a07&0&0000
 ?? ID:                HID\VID_17EF&PID_C955&Col02\6&1cdb4211&0&0001
 ?? ID:                USB\VID_1D5C&PID_5001\6&10f81194&0&8
 ?? ID:                USB\VID_174F&PID_1809\200901010001
 ?? ID:                USB\VID_CB07&PID_1BCF&MI_00\6&3a4e7912&1&0000
 ?? ID:                USB\VID_046D&PID_C548&MI_01\6&20151c60&0&0001
 ?? ID:                HID\VID_276D&PID_2233&MI_01\7&11831dc9&0&0000
 ?? ID:                HID\VID_10D6&PID_4801&MI_00&Col04\7&1c4fe18&0&0003
 ?? ID:                USB\VID_10D6&PID_4801\0123456789AB
 ?? ID:                HID\VID_10D6&PID_4801&MI_00&Col03\7&1c4fe18&0&0002
 ?? ID:                HID\VID_046D&PID_C548&MI_03\7&19d357fc&0&0000
 ?? ID:                HID\VID_10D6&PID_4801&MI_00&Col02\7&1c4fe18&0&0001
 ?? ID:                HID\VID_276D&PID_2233&MI_02&Col02\7&24b33a07&0&0001
 ?? ID:                HID\VID_10D6&PID_4801&MI_00&Col01\7&1c4fe18&0&0000
 ?? ID:                USB\VID_046D&PID_C548\5&213b2cfc&0&3
 ?? ID:                HID\VID_046D&PID_C548&MI_01&Col04\7&dbfa67f&0&0003
 ?? ID:                HID\VID_1B3F&PID_2008&MI_03\8&34a58257&0&0000
 ?? ID:                HID\VID_046D&PID_C548&MI_01&Col03\7&dbfa67f&0&0002
 ?? ID:                HID\VID_046D&PID_C548&MI_01&Col02\7&dbfa67f&0&0001
 ?? ID:                HID\VID_046D&PID_C548&MI_01&Col01\7&dbfa67f&0&0000
 ?? ID:                USB\VID_046D&PID_C548&MI_02\6&20151c60&0&0002
 ?? ID:                USB\VID_10D6&PID_4801&MI_00\6&288021da&2&0000
 ?? ID:                USB\VID_1D5C&PID_5011\6&10f81194&0&4
 ?? ID:                USB\VID_1B3F&PID_2008&MI_03\7&37d8ae8d&0&0003
 ?? ID:                HID\VID_276D&PID_2233&MI_02&Col03\7&24b33a07&0&0002
 ?? ID:                USB\VID_276D&PID_2233\0429133856
 ?? ID:                USB\VID_174F&PID_1809&MI_00\7&2e689c9d&1&0000
 ?? ID:                USB\VID_1B3F&PID_2008\6&1f87c48d&0&3
 ?? ID:                USB\VID_CB07&PID_1BCF&MI_02\6&3a4e7912&1&0002
 ?? ID:                HID\VID_276D&PID_2233&MI_00\7&39edcb92&0&0000
 ?? ID:                USB\VID_046D&PID_C548&MI_03\6&20151c60&0&0003
 ?? ID:                USB\VID_10D6&PID_4801&MI_01\6&288021da&2&0001
 ?? ID:                USB\ROOT_HUB30\4&35627a0b&2&0
 ?? ID:                HID\VID_276D&PID_2233&MI_02&Col04\7&24b33a07&0&0003
 ?? ID:                USB\VID_2808&PID_93A9\5&213b2cfc&0&5
 ?? ID:                USB\VID_8087&PID_0033\5&213b2cfc&0&14
 ?? ID:                USB\VID_CB07&PID_1BCF\20240420112909
 ?? ID:                USB\VID_17EF&PID_C955\5&213b2cfc&0&13
 ?? ID:                USB\VID_1B3F&PID_2008&MI_00\7&37d8ae8d&0&0000
 ?? ID:                HID\VID_046D&PID_C548&MI_02&Col01\7&3196e441&0&0000
 ?? ID:                HID\VID_276D&PID_2233&MI_02&Col05\7&24b33a07&0&0004
 ?? ID:                HID\VID_046D&PID_C548&MI_00\7&16179743&0&0000
 ?? ID:                HID\VID_17EF&PID_C955&Col01\6&1cdb4211&0&0000
 ?? ID:                USB\VID_1A40&PID_0101\5&213b2cfc&0&4
 ?? ID:                USB\VID_174F&PID_1809&MI_02\7&2e689c9d&1&0002
 ?? ID:                USB\VID_276D&PID_2233&MI_02\6&9350b71&1&0002
 ?? ID:                USB\VID_276D&PID_2233&MI_01\6&9350b71&1&0001
 ?? ID:                USB\VID_276D&PID_2233&MI_00\6&9350b71&1&0000
 ?? ID:                USB\VID_046D&PID_C548&MI_00\6&20151c60&0&0000
@@ -0,0 +1,51 @@
 ?? ID:                USB\ROOT_HUB30\5&323bdd91&2&0
 ?? ID:                HID\VID_046D&PID_C548&MI_02&Col02\7&3196e441&0&0001
 ?? ID:                HID\VID_276D&PID_2233&MI_02&Col01\7&24b33a07&0&0000
 ?? ID:                HID\VID_17EF&PID_C955&Col02\6&1cdb4211&0&0001
 ?? ID:                USB\VID_1D5C&PID_5001\6&10f81194&0&8
 ?? ID:                USB\VID_174F&PID_1809\200901010001
 ?? ID:                USB\VID_CB07&PID_1BCF&MI_00\6&3a4e7912&1&0000
 ?? ID:                USB\VID_046D&PID_C548&MI_01\6&20151c60&0&0001
 ?? ID:                HID\VID_276D&PID_2233&MI_01\7&11831dc9&0&0000
 ?? ID:                HID\VID_10D6&PID_4801&MI_00&Col04\7&1c4fe18&0&0003
 ?? ID:                USB\VID_10D6&PID_4801\0123456789AB
 ?? ID:                HID\VID_10D6&PID_4801&MI_00&Col03\7&1c4fe18&0&0002
 ?? ID:                HID\VID_046D&PID_C548&MI_03\7&19d357fc&0&0000
 ?? ID:                HID\VID_10D6&PID_4801&MI_00&Col02\7&1c4fe18&0&0001
 ?? ID:                HID\VID_276D&PID_2233&MI_02&Col02\7&24b33a07&0&0001
 ?? ID:                HID\VID_10D6&PID_4801&MI_00&Col01\7&1c4fe18&0&0000
 ?? ID:                USB\VID_046D&PID_C548\5&213b2cfc&0&3
 ?? ID:                HID\VID_046D&PID_C548&MI_01&Col04\7&dbfa67f&0&0003
 ?? ID:                HID\VID_1B3F&PID_2008&MI_03\8&34a58257&0&0000
 ?? ID:                HID\VID_046D&PID_C548&MI_01&Col03\7&dbfa67f&0&0002
 ?? ID:                HID\VID_046D&PID_C548&MI_01&Col02\7&dbfa67f&0&0001
 ?? ID:                HID\VID_046D&PID_C548&MI_01&Col01\7&dbfa67f&0&0000
 ?? ID:                USB\VID_046D&PID_C548&MI_02\6&20151c60&0&0002
 ?? ID:                USB\VID_10D6&PID_4801&MI_00\6&288021da&2&0000
 ?? ID:                USB\VID_1D5C&PID_5011\6&10f81194&0&4
 ?? ID:                USB\VID_1B3F&PID_2008&MI_03\7&37d8ae8d&0&0003
 ?? ID:                HID\VID_276D&PID_2233&MI_02&Col03\7&24b33a07&0&0002
 ?? ID:                USB\VID_276D&PID_2233\0429133856
 ?? ID:                USB\VID_174F&PID_1809&MI_00\7&2e689c9d&1&0000
 ?? ID:                USB\VID_1B3F&PID_2008\6&1f87c48d&0&3
 ?? ID:                USB\VID_CB07&PID_1BCF&MI_02\6&3a4e7912&1&0002
 ?? ID:                HID\VID_276D&PID_2233&MI_00\7&39edcb92&0&0000
 ?? ID:                USB\VID_046D&PID_C548&MI_03\6&20151c60&0&0003
 ?? ID:                USB\VID_10D6&PID_4801&MI_01\6&288021da&2&0001
 ?? ID:                USB\ROOT_HUB30\4&35627a0b&2&0
 ?? ID:                HID\VID_276D&PID_2233&MI_02&Col04\7&24b33a07&0&0003
 ?? ID:                USB\VID_2808&PID_93A9\5&213b2cfc&0&5
 ?? ID:                USB\VID_8087&PID_0033\5&213b2cfc&0&14
 ?? ID:                USB\VID_CB07&PID_1BCF\20240420112909
 ?? ID:                USB\VID_17EF&PID_C955\5&213b2cfc&0&13
 ?? ID:                USB\VID_1B3F&PID_2008&MI_00\7&37d8ae8d&0&0000
 ?? ID:                HID\VID_046D&PID_C548&MI_02&Col01\7&3196e441&0&0000
 ?? ID:                HID\VID_276D&PID_2233&MI_02&Col05\7&24b33a07&0&0004
 ?? ID:                HID\VID_046D&PID_C548&MI_00\7&16179743&0&0000
 ?? ID:                HID\VID_17EF&PID_C955&Col01\6&1cdb4211&0&0000
 ?? ID:                USB\VID_1A40&PID_0101\5&213b2cfc&0&4
 ?? ID:                USB\VID_174F&PID_1809&MI_02\7&2e689c9d&1&0002
 ?? ID:                USB\VID_276D&PID_2233&MI_02\6&9350b71&1&0002
 ?? ID:                USB\VID_276D&PID_2233&MI_01\6&9350b71&1&0001
 ?? ID:                USB\VID_276D&PID_2233&MI_00\6&9350b71&1&0000
 ?? ID:                USB\VID_046D&PID_C548&MI_00\6&20151c60&0&0000
@@ -0,0 +1,56 @@
 ?? ID:                USB\ROOT_HUB30\5&323bdd91&2&0
 ?? ID:                HID\VID_046D&PID_C548&MI_02&Col02\7&3196e441&0&0001
 ?? ID:                HID\VID_276D&PID_2233&MI_02&Col01\7&24b33a07&0&0000
 ?? ID:                USB\VID_0BDA&PID_8153\000001
 ?? ID:                HID\VID_17EF&PID_C955&Col02\6&1cdb4211&0&0001
 ?? ID:                USB\VID_1D5C&PID_5001\6&10f81194&0&8
 ?? ID:                USB\VID_174F&PID_1809\200901010001
 ?? ID:                USB\VID_05E3&PID_0749\000000001539
 ?? ID:                USB\VID_CB07&PID_1BCF&MI_00\6&3a4e7912&1&0000
 ?? ID:                USB\VID_046D&PID_C548&MI_01\6&20151c60&0&0001
 ?? ID:                HID\VID_276D&PID_2233&MI_01\7&11831dc9&0&0000
 ?? ID:                HID\VID_10D6&PID_4801&MI_00&Col04\7&1c4fe18&0&0003
 ?? ID:                USB\VID_10D6&PID_4801\0123456789AB
 ?? ID:                HID\VID_10D6&PID_4801&MI_00&Col03\7&1c4fe18&0&0002
 ?? ID:                HID\VID_046D&PID_C548&MI_03\7&19d357fc&0&0000
 ?? ID:                HID\VID_10D6&PID_4801&MI_00&Col02\7&1c4fe18&0&0001
 ?? ID:                HID\VID_276D&PID_2233&MI_02&Col02\7&24b33a07&0&0001
 ?? ID:                HID\VID_10D6&PID_4801&MI_00&Col01\7&1c4fe18&0&0000
 ?? ID:                USB\VID_046D&PID_C548\5&213b2cfc&0&3
 ?? ID:                HID\VID_046D&PID_C548&MI_01&Col04\7&dbfa67f&0&0003
 ?? ID:                HID\VID_1B3F&PID_2008&MI_03\8&34a58257&0&0000
 ?? ID:                HID\VID_046D&PID_C548&MI_01&Col03\7&dbfa67f&0&0002
 ?? ID:                HID\VID_046D&PID_C548&MI_01&Col02\7&dbfa67f&0&0001
 ?? ID:                HID\VID_046D&PID_C548&MI_01&Col01\7&dbfa67f&0&0000
 ?? ID:                USB\VID_046D&PID_C548&MI_02\6&20151c60&0&0002
 ?? ID:                USB\VID_10D6&PID_4801&MI_00\6&288021da&2&0000
 ?? ID:                USB\VID_1D5C&PID_5011\6&10f81194&0&4
 ?? ID:                USB\VID_1B3F&PID_2008&MI_03\7&37d8ae8d&0&0003
 ?? ID:                HID\VID_276D&PID_2233&MI_02&Col03\7&24b33a07&0&0002
 ?? ID:                USB\VID_276D&PID_2233\0429133856
 ?? ID:                USB\VID_174F&PID_1809&MI_00\7&2e689c9d&1&0000
 ?? ID:                USB\VID_2109&PID_0817\MSFT30000000000
 ?? ID:                USB\VID_1B3F&PID_2008\6&1f87c48d&0&3
 ?? ID:                USB\VID_CB07&PID_1BCF&MI_02\6&3a4e7912&1&0002
 ?? ID:                HID\VID_276D&PID_2233&MI_00\7&39edcb92&0&0000
 ?? ID:                USB\VID_046D&PID_C548&MI_03\6&20151c60&0&0003
 ?? ID:                USB\VID_10D6&PID_4801&MI_01\6&288021da&2&0001
 ?? ID:                USB\ROOT_HUB30\4&35627a0b&2&0
 ?? ID:                HID\VID_276D&PID_2233&MI_02&Col04\7&24b33a07&0&0003
 ?? ID:                USB\VID_2109&PID_2817\MSFT20000000000
 ?? ID:                USB\VID_2808&PID_93A9\5&213b2cfc&0&5
 ?? ID:                USB\VID_8087&PID_0033\5&213b2cfc&0&14
 ?? ID:                USB\VID_CB07&PID_1BCF\20240420112909
 ?? ID:                USB\VID_17EF&PID_C955\5&213b2cfc&0&13
 ?? ID:                USB\VID_2109&PID_1817\MSFT30000000000
 ?? ID:                USB\VID_1B3F&PID_2008&MI_00\7&37d8ae8d&0&0000
 ?? ID:                HID\VID_046D&PID_C548&MI_02&Col01\7&3196e441&0&0000
 ?? ID:                HID\VID_276D&PID_2233&MI_02&Col05\7&24b33a07&0&0004
 ?? ID:                HID\VID_046D&PID_C548&MI_00\7&16179743&0&0000
 ?? ID:                HID\VID_17EF&PID_C955&Col01\6&1cdb4211&0&0000
 ?? ID:                USB\VID_1A40&PID_0101\5&213b2cfc&0&4
 ?? ID:                USB\VID_174F&PID_1809&MI_02\7&2e689c9d&1&0002
 ?? ID:                USB\VID_276D&PID_2233&MI_02\6&9350b71&1&0002
 ?? ID:                USB\VID_276D&PID_2233&MI_01\6&9350b71&1&0001
 ?? ID:                USB\VID_276D&PID_2233&MI_00\6&9350b71&1&0000
 ?? ID:                USB\VID_046D&PID_C548&MI_00\6&20151c60&0&0000
@@ -0,0 +1,463 @@
 ====================
 人工输入（2026-02-23）
 接下来我需要你和我一起尝试定位解决我的电脑故障。你需要把你的发言也记录在这篇文档内，以便后续查阅。
 我有一台拯救者刃9000k 2024台式机，遇到了非常奇怪的问题：我的主板上有一个usb-c口，之前一直使用这个c口连接拓展坞使用。今天突然不能用了。
 我尝试定位，发现：
 1. 这个c口连接拓展坞，拓展坞上再连接其他设备就都不能使用；
 2. 这个c口直接连接其他设备（如键盘）可以使用，直接连接我的外置ssd，可以按照usb3.0速率进行文件传输；
 3. 这个c口直连我的手机，可以充电，但是无法激活usb连接模式；
 4. 其他的usb-a口连接我的手机都可以激活usb连接模式；
 5. 同一个拓展坞使用同一根数据线连接到其他电脑上可以正常使用连接到拓展坞的设备。
 6. 重启电脑后，这个c口连接拓展坞依然无法使用，上述现象全部可以复现
 根据以上信息，我怀疑这个c口的物理连接应当是正常的，但是可能存在某些软件或驱动方面的问题导致无法正常使用拓展坞。
 我打开设备管理器，在其他设备下并没有发现任何异常设备，也没有看到任何与usb-c相关的错误提示。
 在通用串行总线控制器下，也没有任何错误提示，但是我注意到有2个重复的USB根集线器(USB 3.0)，各自打开，进入到事件，都存在以下特征：
 USB根集线器(USB 3.0) #1
 - 位置：Port_#0004.Hub_#0001
 - 事件：
    - 2026-02-23 00:38:34 - 设备设置未迁移
        由于设备部分匹配或不明确，USB\VID_1D5C&PID_5011\6&10f81194&0&4的设备设置未从以前的 OS 安装迁移。
        最后一个设备实例 ID： USB\VID_05E3&PID_0610\5&218bfa3c&0&9
        类 GUID： {36fc9e60-c465-11cf-8056-444553540000}
        位置路径：
        迁移排名： 0xF000FFFF0000F120
        Present： false
        状态： 0xC0000719
    - 2026-02-23 00:38:34 - 已配置设备（usbhub3.inf)
        已配置设备USB\VID_1D5C&PID_5011\6&10f81194&0&4。
        驱动程序名称： usbhub3.inf
        驱动程序包 ID： usbhub3.inf_amd64_77ea074f504b65c1
        类 GUID： {36fc9e60-c465-11cf-8056-444553540000}
        驱动程序日期： 01/26/2026
        驱动程序版本： 10.0.26100.7705
        驱动程序提供程序： Microsoft
        驱动程序部分： Generic.Install.NT
        驱动程序级别： 0x802000
        匹配设备 ID： USB\USB20_HUB
        超限驱动程序：
        设备已更新： false
        父设备： USB\ROOT_HUB30\5&323bdd91&2&0
    - 2026-02-23 00:38:34 - 已启动设备
        已启动设备 USB\VID_1D5C&PID_5011\6&10f81194&0&4。
        驱动程序名称: usbhub3.inf
        类 GUID: {36fc9e60-c465-11cf-8056-444553540000}
        服务: USBHUB3
        低层筛选程序:
        高层筛选程序:
 USB根集线器(USB 3.0) #2
 - 位置：Port_#0005.Hub_#0002
 - 事件：
    - 2026-02-23 00:39:36 - 设备设置未迁移
        由于设备部分匹配或不明确，USB\VID_1A40&PID_0101\5&213b2cfc&0&4的设备设置未从以前的 OS 安装迁移。
        最后一个设备实例 ID： USB\VID_05E3&PID_0610\5&218bfa3c&0&9
        类 GUID： {36fc9e60-c465-11cf-8056-444553540000}
        位置路径：
        迁移排名： 0xF000FFFF0000F120
        Present： false
        状态： 0xC0000719
    - 2026-02-23 00:39:36 - 已配置设备（usbhub3.inf)
        已配置设备USB\VID_1A40&PID_0101\5&213b2cfc&0&4。
        驱动程序名称： usbhub3.inf
        驱动程序包 ID： usbhub3.inf_amd64_77ea074f504b65c1
        类 GUID： {36fc9e60-c465-11cf-8056-444553540000}
        驱动程序日期： 01/26/2026
        驱动程序版本： 10.0.26100.7705
        驱动程序提供程序： Microsoft
        驱动程序部分： Generic.Install.NT
        驱动程序级别： 0x802000
        匹配设备 ID： USB\USB20_HUB
        超限驱动程序：
        设备已更新： false
        父设备： USB\ROOT_HUB30\4&35627a0b&2&0
    - 2026-02-23 00:39:36 - 已启动设备
        已启动设备 USB\VID_1A40&PID_0101\5&213b2cfc&0&4。
        驱动程序名称: usbhub3.inf
        类 GUID: {36fc9e60-c465-11cf-8056-444553540000}
        服务: USBHUB3
        低层筛选程序:
        高层筛选程序:
 ====================
 AI记录（2026-02-23）
 已阅读当前记录（至 00:39:36 的设备事件）。根据你描述的复现规律：
 - USB-C 口直连单设备多为正常（键盘、外置 SSD 可按 USB3 速率传输）；
 - 但 USB-C 连接拓展坞后，拓展坞下游设备全部不可用；
 - 手机在该 USB-C 口可充电但无法进入 USB 数据连接模式；
 - 其他 USB-A 口连接手机可正常进入数据模式；
 - 同一拓展坞+同一数据线连接其他电脑正常；
 - 重启后问题持续可复现。
 对设备管理器事件的初步解读：
 - “设备设置未迁移（Present:false / 状态 0xC0000719）”常见于 Windows 升级/驱动栈重建后的历史迁移记录，本身不一定代表当前设备故障；
 - 但结合“拓展坞不可用 + 手机仅充电不枚举”，更像是该 USB-C 所在链路出现“枚举/协商”相关问题（尤其是 USB2 通道或 Hub 枚举环节），或被电源管理/过滤驱动/控制器驱动状态影响。
 后续排查优先级建议（按从易到难、从软件到硬件）：
 1) 明确该 USB-C 端口属性：前置/后置？端口旁是否有 SS/10/20/40/⚡/DP 标识？（用于判断是否涉及 USB4/雷电/DP Alt 相关栈）
 2) 抓“插拔拓展坞当下”的系统日志（比设备管理器事件更直接）：
   - 事件查看器 → Windows 日志 → 系统
   - 重点来源：Kernel-PnP、USBHUB3、DriverFrameworks-UserMode
   - 操作：拔掉拓展坞 → 重新插上 → 立即查看同一时间段的错误/警告/信息并记录（文本内容即可）
 3) 若日志显示枚举失败/端口复位失败/设备描述符请求失败等，再进一步定位到：
   - USB 选择性挂起/电源管理导致端口进入异常状态
   - 芯片组/USB 控制器驱动（含厂商 Type-C 相关组件）异常或被替换
   - 第三方安全/虚拟化/USB 过滤驱动干预
   - 端口供电协商异常（拓展坞对 VBUS/电流/角色切换更敏感）
 待补充信息（写入本记录中，便于后续推断）：
 - 该 USB-C 是前置还是后置？端口标识是什么？
 - 插上拓展坞时“系统日志”中 Kernel-PnP / USBHUB3 / DriverFrameworks 的实时事件内容（时间点、事件 ID、详细文本）。
 ====================
 人工补充（2026-02-23）
 1) 该 USB-C 口为后置端口，配置上写的是 USB3.2 Type-C。
 2) 拔插拓展坞时，事件查看器（系统日志，级别包含“信息”）没有任何与 USB/设备枚举相关的日志打印；同一时间仅看到少量来自 WindowsUpdateClient 的信息。
 ====================
 AI记录（2026-02-23）
 基于新增信息的判断更新：
 - 后置 USB3.2 Type-C（非明确 USB4/雷电口）→ 优先按“USB3 控制器/USB2 兼容通道/Hub 枚举”思路排查，不必先假设雷电/USB4 协议栈。
 - 插拔拓展坞在“系统”日志完全无记录 → 不像常规的“设备已连接但驱动失败”，更像是：
  1) 端口对该拓展坞在连接阶段就未触发正常枚举（例如 USB2 D+/D- 通道未建立、CC 角色/电流协商异常导致设备未进入数据角色），或
  2) 相关事件没有进入系统日志（可能在专用日志通道/被关闭），或
  3) 设备瞬断（反复复位）导致你看到不到稳定事件。
 下一步建议（优先做“能在本机直接采集”的证据，减少猜测）：
 1) 用 USB 设备树工具查看实时拓扑（建议 USB Tree View / UsbTreeView 或 Windows SDK 的 USBView）：
   - 分别在“直连外置 SSD（正常）”与“连接拓展坞（异常）”两种情况下截图/导出：
     - 是否出现新的 Hub 节点（常见 Vendor: VIA/Genesys/Realtek 等）
     - 该端口的连接速度（HighSpeed/SuperSpeed）
     - 设备是否反复 Connect/Disconnect
 2) 用 Windows 的“设备管理器 → 查看 → 按连接”观察：
   - 展开到“USB xHCI 兼容主机控制器 → USB 根集线器(USB 3.0)”
   - 插拔拓展坞时，树结构是否有任何变化（哪怕一瞬间）
 3) 关闭可能影响枚举的省电策略（可回退）：
   - 设备管理器中对“USB Root Hub(USB 3.0)”和“通用 USB 集线器(如有)”取消勾选“允许计算机关闭此设备以节约电源”
   - 电源选项中临时关闭“USB 选择性暂停设置”
 4) 收集更底层的枚举日志：
   - 开启“Microsoft-Windows-USB-USBHUB3/Operational”与“Microsoft-Windows-USB-UCX/Operational”（事件查看器 → 应用程序和服务日志 → Microsoft → Windows → USB*）
   - 重新插拔拓展坞后导出对应时间段事件。
 需要你补充到本记录的关键信息（越精确越好）：
 - 主板型号/芯片组（或联想整机的主板信息），以及是否近期有 Windows 大版本更新或芯片组驱动更新。
 - 该拓展坞是否带外接供电（PD 充电器）？连接方式是“拓展坞自供电”还是“只靠主机供电”。
 - 连接拓展坞时：拓展坞上的指示灯/网口灯是否有变化？拓展坞是否能对外供电？
 ====================
 人工补充（2026-02-23）
 - 尚未下载新软件；在设备管理器中“查看 → 按连接”观察：
  - 外接 SSD 时，USB 根集线器(USB 3.0) #2 会挂到“Intel(R) USB 3.20 可扩展主机控制器 - 1.20 (Microsoft)”下，且其下出现 SSD 设备；连接稳定，速度正常。
  - 插入拓展坞时系统“完全没有反应/无任何变化”。
 - 进一步测试：插入拓展坞，并在拓展坞上插入手机时，手机连充电都不会有。
 - 事件查看器 → 应用程序和服务日志 → Microsoft → Windows 下仅看到：USB-UCMUCSICX、USB-USBXHCI、USBVideo；不清楚如何开启我先前提到的 USBHUB3/UCX 日志。
 ====================
 AI记录（2026-02-23）
 基于最新现象的关键推断（优先级更靠近硬件/供电/协商链路）：
 - SSD 能稳定枚举到 Intel xHCI 且速度正常 → 该后置 Type-C 口的 USB3 SuperSpeed 通道、主机控制器与驱动栈“大概率正常”。
 - “插入拓展坞完全无反应”且“拓展坞接手机连充电都没有” → 这更像是端口与拓展坞之间在最早期阶段就失败：
  - 可能是 Type-C 的 CC 识别/供电策略（VBUS）未对该坞打开，导致坞本体不工作；
  - 或坞依赖 USB-C 的默认供电/PD 相关路径（某些坞不接外部电源时需要主机端提供更高电流或正确的 Rp/Rd 判断）；
  - 也可能是“你拿来接坞的这根 C-C 或 C-A 线材/转接链路”在当前端口上触发不了（但你之前说同线材+同坞在其他电脑正常，因此更可能是本机端口的 CC/供电策略变化或异常状态）。
 关于你看到的日志通道：
 - 你当前只看到 USB-USBXHCI / USB-UCMUCSICX / USBVideo 是正常的；不同 Windows 版本/组件安装状态下，USBHUB3/UCX 的 Operational 通道可能“默认不存在/被折叠/名称不同”。
 下一步：不装新软件也能做的定位（建议按顺序做，尽量一次只改一个变量）
 1) 先确认拓展坞供电形态与 PD：
   - 拓展坞是否有外接 PD 充电器口？
   - 若有：请分别测试「坞接 PD 电源」与「坞不接 PD 电源」两种情况下，插入该后置 Type-C 口，是否仍旧“完全无反应/无充电”。
   - 记录：坞指示灯、网口灯、HDMI 是否亮、手机是否充电。
 2) 换一种连接组合（排除“端口对某种线材/方向敏感”）：
   - 同一根线翻转插头方向再试（Type-C 端子翻面）。
   - 换一根数据线（最好是已验证可传数据的全功能线），再试。
   - 如果这台机器还有其他 Type-C（例如前置），也用同一线同一坞对比。
 3) 在设备管理器继续观察“按连接”的瞬时变化：
   - 展开 Intel(R) USB 3.20 xHCI → USB Root Hub(USB 3.0)
   - 插入拓展坞时哪怕出现/消失一瞬间的“USB Hub/Unknown USB Device”，也请记下名字（或截图）。
 下一步：用系统自带命令把可用日志通道列出来（不依赖你手动找）
 - 目标：列出所有包含 USBHUB/UCX/UCSI/XHCI 的事件通道名称，然后再对存在的通道启用 Operational。
 - 推荐执行（管理员 PowerShell）：
  - `wevtutil el | findstr /i usb`（列出包含 usb 的日志通道）
  - 若看到类似 `Microsoft-Windows-USB-USBXHCI/Operational`、`...UCMUCSICX/Operational`：可用
    `wevtutil sl "<通道名>" /e:true` 启用。
 - 你把 `wevtutil el | findstr /i usb` 的输出粘贴到本记录里，我再告诉你应启用哪些更有用。
 如果以上测试显示“无论是否外接 PD、无论换线/翻转，拓展坞在该口都完全不供电”，而 SSD 仍正常：
 - 需要重点怀疑：该 Type-C 口的 VBUS/电源开关或 CC 控制器/Type-C Port Controller 进入异常状态（固件/驱动/电源管理）或硬件故障。
 - 软件侧可尝试的修复路径将集中在：芯片组驱动/ME/Type-C 相关组件重装、BIOS/EC 更新、关机断电后放电复位（断电+长按电源键）。
 ====================
 人工补充（2026-02-23）
 - 拓展坞有 PD 供电接口：此前未使用；刚才接入 PD 电源后再插电脑后置 Type-C：
  - 设备管理器里“闪了一下”，短暂出现了几个“通用 USB 集线器”，随后又闪一下并消失。
  - 目前未修改事件查看器设置，仍未看到明显信息输出。
  - 在“拓展坞接 PD 电源 + 插电脑后置 Type-C”情况下，拓展坞可以给手机充电。
 - 数据线翻面已尝试过，对现象无影响。
 ====================
 AI记录（2026-02-23）
 对现象的关键更新：
 - “接 PD 后能给手机充电” + “通用 USB 集线器短暂出现又消失” → 说明：
  1) 纯供电（VBUS）链路在接 PD 后是成立的；
  2) 枚举并非完全没有发生，而是很可能在某个阶段反复复位/崩溃式断开（典型表现就是设备树闪现）。
 - 这进一步把嫌疑集中到：
  - 该 Type-C 口在面对“外接供电+Hub”的拓展坞时，发生端口复位风暴、供电策略/电流限制触发、或 USB2/设备描述符阶段失败；
  - 或者拓展坞的 Hub/下游设备拉起后瞬间过流/短时压降导致口保护断开（但因为 SSD 正常，可能是“仅在坞这种复杂负载/Hub”下触发）。
 下一步最有效的证据采集（不装新软件）：把“闪现的那一下”变成可读日志
 1) 启用你目前已经能看到的两个日志通道的 Operational（若存在）：
   - Microsoft → Windows → USB-USBXHCI → Operational（启用）
   - Microsoft → Windows → USB-UCMUCSICX → Operational（启用）
   启用后，重复一次“坞接 PD → 插后置 Type-C”，然后导出/复制这两个 Operational 中同一时间段的事件。
 2) 同时查看 PnP 设备安装日志（很多时候比系统日志更有用）：
   - 事件查看器 → 应用程序和服务日志 → Microsoft → Windows → DeviceSetupManager → Admin
   - 以及：Microsoft → Windows → Kernel-PnP → Configuration（若存在）
   关注是否出现：设备安装开始/失败、设备已移除、问题代码、容器 ID 等。
 3) 在设备管理器做一次“抓瞬时设备名”的操作：
   - 视图改为“按连接”，展开到 Intel USB xHCI 下的根集线器
   - 用手机录屏（或连拍）捕捉闪现时出现的设备名称（例如 Unknown USB Device、USB Composite、Generic SuperSpeed Hub、Billboard Device 等）。记录出现过的名字即可。
 快速修复尝试（低风险、对 Type-C 控制器异常状态常有效）：
 4) 完整断电复位（台式机建议这样做）：
   - 关机 → 拔掉电源线 → 等待 30 秒
   - 长按机箱电源键 15–30 秒（放电）
   - 再插电开机后，先不要插其他 USB 复杂设备，只测试“后置 Type-C + 拓展坞(接 PD)”
 后续若日志显示端口复位/描述符失败/过流：
 - 再走驱动/固件路线：更新/重装 Intel 芯片组驱动、ME 组件、联想电源管理/USB 相关组件；检查 BIOS/EC 是否有更新。
 ====================
 人工补充（2026-02-23）
 DeviceSetupManager/Admin（11:22:08 附近）
 - 事件ID 100（信息）：DSM 服务已启动，模式 Normal，上一个会话 72 秒前。
 - 事件ID 30（信息）：设备容器 {18eaf965-7eca-5c7b-956c-6f78644d5109} 已排队等待安装。
 - 事件ID 112（信息）：已为设备容器 'USB3.0 Card Reader' ({18eaf965-7eca-5c7b-956c-6f78644d5109}) 提供服务、处理 5 任务，并在 0 ms 中写入 0 属性。
 - 事件ID 11（信息）：DSM 服务处于空闲状态，正在等待 stop。
 补充：setupapi.dev.log 已复制到同目录（copilot_workspace\\usb_c_debug\\setupapi.dev.log）。
 ====================
 AI记录（2026-02-23）
 对你提供的 DeviceSetupManager/Admin 的解读：
 - 这组 11:22:08 的记录只体现“某个设备容器（USB3.0 Card Reader）被排队/处理”，没有出现典型的“设备安装失败/问题代码/驱动匹配失败”等错误条目。
 - 结合你前面描述“插坞/接 PD 会闪一下但最终消失”，更像是设备在更底层就掉线，DSM 没来得及进入稳定的安装失败流程。
 我已读取当前目录下的 setupapi.dev.log（开头几百行）并发现：
 - 目前日志片段主要是历史记录（2/21、2/22 晚间、2/23 凌晨）以及你手动在设备管理器做过的 USB Root Hub / 若干 USB 设备移除操作；
 - 其中出现过多个 Hub/设备 VID/PID，例如：
  - `USB\VID_2109&PID_2817` / `USB\VID_2109&PID_4817` / `USB\VID_2109&PID_8817`（这类 VID=2109 常见于 VIA Labs 的 USB Hub/控制器，和很多拓展坞/读卡器链路相关）；
 - 但在我已读取的片段中，尚未看到与“2026/02/23 11:22”时间窗口直接对应的 setupapi 记录（我用关键词搜索未命中该时间）。
 下一步要把日志对齐到你刚刚测试的时间点（11:22 附近）：
 1) 请在 setupapi.dev.log 里用查找（Ctrl+F）定位 `2026/02/23 11:` 或接近你复现的时间段；
 2) 或者你再复现一次“先插电脑再接 PD（会闪烁）”，记下精确到秒的时间点，然后我们就抓该时间点附近的 setupapi block。
 我们在 setupapi/devsetup 中要重点盯的关键词：
 - `USB\\VID_2109`（Hub/坞相关）
 - `USB\\ROOT_HUB30`、`xHCI`、`USBXHCI`
 - `UCM` / `UCSI` / `Type-C`
 - `Unknown USB Device` / `Device Descriptor Request Failed`
 - `Port reset` / `over-current` / `CM_PROB_` / `Problem code`
 只要在 11:22 附近抓到 1-2 个失败 block（包含设备实例路径和错误码），基本就能判断是“端口复位/描述符失败（多为链路/供电/兼容性/硬件）”还是“驱动/策略层失败（可通过重装组件解决）”。====================
 ====================
 人工补充（2026-02-23）
 - 已执行“触发变化的序列”（先插电脑 Type-C 再插 PD，会出现设备管理器闪烁/瞬时设备变化）。
 - 但 setupapi.dev.log 文件完全没有发生更新，文件最后更新时间一直停留在 11:07。
 - 提醒：需要把本轮对话内容也持续写入 communication_record.txt。
 ====================
 AI记录（2026-02-23）
 问题纠偏与当前关键点：
 - 如果你确认复现时设备管理器确实发生了瞬时变化，但 setupapi.dev.log 的“文件时间戳完全不变”，优先怀疑不是“没有日志”，而是：
  1) 你正在查看/复制的是一份静态副本（而不是系统正在写入的那份原始日志），或
  2) 系统原始日志写入受限/被锁定/写入到其他位置（相对少见），或
  3) 你的复现并未触发 PnP 安装流程（仅发生 Type-C/供电状态变化，未进入设备安装阶段），因此 setupapi 不一定新增，但通常仍应有部分记录。
 建议的验证动作（目标：确认“系统原始日志是否在写”）：
 1) 直接核对系统原始路径的时间戳：
   - `C:\Windows\INF\setupapi.dev.log`（系统原始位置）
   - 以及你工作区副本：`D:\MyCodingProject\general_tools\copilot_workspace\usb_c_debug\setupapi.dev.log`
   若两者时间戳不同或只有系统原始文件在变，则说明你看的副本未刷新。
 2) 用最朴素的方式验证末尾是否新增：
   - 复现一次“先插电脑 Type-C → 再插 PD（会闪烁）”
   - 立即打开 `C:\Windows\INF\setupapi.dev.log` 跳到文件末尾，查看是否新增 `>>>` 段落。
 3) 如果系统原始 setupapi 也完全不更新：
   - 改抓“设备列表差分”这条证据链（例如使用 pnputil 枚举 connected devices），因为这类瞬时设备即使不触发安装，也会在枚举里出现/消失。
 后续策略：
 - 一旦确认“系统原始 setupapi”能更新，我们就以复现时间点为锚，抓取对应 `USB\VID_2109...` / `Unknown USB Device` / `ROOT_HUB30` 的 install/remove block。
 - 若确认 setupapi 确实不写入，则转向 UCSI/Type-C 控制链路或供电状态机层面，用 UCMUCSICX / USBXHCI / 设备枚举差分来定位。
 ====================
 人工补充（2026-02-23）
 - 结论更新：系统原始 setupapi.dev.log 也完全不更新。
 - 诉求：不知道如何执行后续操作，需要一步一步指导。
 ====================
 AI记录（2026-02-23）
 当 setupapi.dev.log（系统原始）也不更新时，说明问题很可能停留在“Type-C 供电/角色/连接状态机”或“极短暂的枚举闪断”阶段，Windows 的设备安装日志链路没有进入可记录的安装流程。
 因此下一步改用两条更可靠的证据链：
 A) 设备枚举差分（抓“闪现的设备实例 ID/VID/PID”）
 B) 更贴近 Type-C/UCSI 的事件通道（UCM/UCSI/USBXHCI 等）
 下面给出可直接照做的步骤（每一步只做一件事，做完把结果贴回本记录）：
 步骤 1：准备复现条件（用于稳定触发“闪烁”）
 - 按你已验证最容易触发变化的顺序：先把拓展坞的 Type-C 数据线插到电脑后置 Type-C（此时不接 PD），然后再把 PD 电源插到拓展坞（触发设备管理器闪烁）。
 步骤 2：用 PowerShell 采集“连接设备列表”（复现前）
 - 以管理员打开 PowerShell。
 - 执行：`pnputil /enum-devices /connected | findstr /i "USB\\ VID_ PID_"`
 - 将输出全文复制保存（命名为 BEFORE）。
 步骤 3：复现闪烁
 - 立刻按步骤 1 的顺序操作一次（触发设备管理器闪一下）。
 步骤 4：再次采集“连接设备列表”（复现后）
 - 回到 PowerShell 再执行同一条命令：
  `pnputil /enum-devices /connected | findstr /i "USB\\ VID_ PID_"`
 - 将输出全文复制保存（命名为 AFTER）。
 步骤 5：对比 BEFORE/AFTER
 - 重点找 AFTER 里新增或消失的条目，尤其是：
  - `USB\VID_2109&PID_....`（拓展坞 Hub 常见）
  - `Unknown USB Device`（如果能枚举到名字）
  - 任意 `USB\VID_xxxx&PID_yyyy` 新出现又消失
 - 把“新增/消失的那几行”贴出来即可，不需要全量。
 步骤 6：补抓 DeviceSetupManager/Admin（即使只有信息也要）
 - 事件查看器 → 应用程序和服务日志 → Microsoft → Windows → DeviceSetupManager → Admin
 - 复现一次闪烁后，刷新并将同一时间点附近新增事件贴出来。
 步骤 7（可选但很有价值）：抓 USB-UCMUCSICX / USB-USBXHCI Operational
 - 事件查看器 → 应用程序和服务日志 → Microsoft → Windows → USB-UCMUCSICX → Operational
 - 以及：Microsoft → Windows → USB-USBXHCI → Operational
 - 复现闪烁后，刷新并粘贴新增事件。
 执行到步骤 5 后，我们基本就能拿到“闪现设备的 VID/PID/实例路径”，才能进一步判断：
 - 是 Hub 被识别但立刻断开（偏供电/保护/兼容），还是
 - 根本没能建立稳定数据角色（偏 UCSI/Type-C 控制器/驱动/固件）。====================
 ====================
 人工补充（2026-02-23）
 - 已执行步骤 1-4，抓取到 BEFORE/INPROGRESS/AFTER 三个阶段的 pnputil 结果。
 - 现象：插入拓展坞后，设备管理器会闪烁一下，随后恢复正常（无拓展坞设备）。
 - 注意：拓展坞接入 PD 电源后，拓展坞上的指示灯会亮起。
 ====================
 AI记录（2026-02-23）
 已分析你保存的 3 次抓取（BEFORE / INPROGRESS / AFTER）。结论非常明确：
 1) BEFORE 与 AFTER：几乎完全一致
 - 说明“最终稳定状态”下，拓展坞链路并没有保持连接（即没有把 Hub/网卡/读卡器等作为已连接设备留在系统里）。
 2) INPROGRESS 相比 BEFORE/AFTER：新增了一组典型“拓展坞内部器件”实例 ID（但只在中间瞬时出现）
 新增项包括：
 - `USB\VID_2109&PID_2817\MSFT20000000000`
 - `USB\VID_2109&PID_1817\MSFT30000000000`
 - `USB\VID_2109&PID_0817\MSFT30000000000`
  说明：这是拓展坞内部的 USB Hub 链路（VID=2109 常见于 VIA Labs，很多拓展坞使用）。
 - `USB\VID_0BDA&PID_8153\000001`
  说明：Realtek USB 千兆网卡（RTL8153 系列非常常见）。
 - `USB\VID_05E3&PID_0749\000000001539`
  说明：Genesys Logic 的 Hub/读卡器相关控制器（很多拓展坞/读卡器会出现 05E3）。
 => 这证明：在你执行“先插电脑再插 PD（会闪）”的序列时，拓展坞不是完全无响应，而是：
 - 设备确实被枚举出来了（Hub + 网卡 + 读卡器/Hub 组件都出现过）
 - 但随后整条链路又掉线（因此 AFTER 里看不到它们）。
 3) 现象定位：不是驱动缺失，而是“枚举后立即断连（闪断）”
 - 这些 VID/PID 都是 Windows 自带驱动可识别的通用设备（USB Hub / Realtek 8153 / Genesys 控制器），若是单纯驱动问题通常会留下“Unknown device/带问题代码”的连接痕迹。
 - 现在的模式更像：端口复位/供电策略/过流保护/Type-C 状态机导致链路重置，导致所有下游设备瞬时出现又消失。
 下一步最小验证（只做 2 件事即可进一步定性）：
 A) 复现闪断时，同时只让“拓展坞空载”（不要插手机/硬盘/键鼠），并保持拓展坞接 PD：
 - 目标：排除下游负载触发过流/压降。
 - 看是否仍会出现 INPROGRESS 里的同一组 VID/PID 闪现。
 B) 如果空载仍闪断：优先走固件/驱动/电源管理侧
 - 检查并更新：联想 Vantage / 官网提供的 BIOS/EC、芯片组驱动、Intel ME、以及与 Type-C/UCSI 相关组件。
 - 在设备管理器“系统设备”里找到类似 “UCSI / USB Connector Manager / Type-C Port Controller” 的设备，记录其驱动提供商/版本/日期（用于判断是否发生过更新/回退）。
 （补充）如果你能再抓一次“空载 + 接 PD + 闪断”的 BEFORE/INPROGRESS/AFTER，我们可以确认是否为“下游设备启动导致掉线”还是“仅 Hub 链路就不稳定”。
 ====================
 人工补充（2026-02-23）
 - 复现抓取（BEFORE/INPROGRESS/AFTER）时，拓展坞确实是空载状态。
 - 此前已尝试更新所有能找到的驱动，包括：芯片组、BIOS、Intel Serial IO 等；仍无改善。
 ====================
 AI记录（2026-02-23）
 在“空载仍闪断 + BIOS/芯片组/Serial IO 已更新”的前提下，优先级从“常规驱动缺失”进一步转向以下几类：
 1) Type-C/UCSI 控制链路或端口供电/保护策略异常（软件状态或硬件级）
 - 证据：Hub+网卡+读卡器等能同时闪现，说明坞已上电且可枚举；但随后整条链路被重置/断开。
 2) 第三方过滤驱动/安全软件/虚拟化组件干预 USB 栈（会导致枚举后立刻移除）
 - 你日志里曾出现 spacedesk 相关服务操作；这类软件有时会插入过滤层。
 3) Windows 电源管理/选择性挂起/端口复位风暴
 - 尤其是“先连电脑再上 PD 才会触发闪断”模式，像是协商状态机切换触发的复位。
 下一步建议（尽量都可回退，且每步只改一个变量）：
 A) 检查并临时禁用第三方 USB 相关过滤驱动（无须卸载软件）
 - 设备管理器 → 查看“按驱动程序”或在设备属性中查看是否有 UpperFilters/LowerFilters（尤其在 USB、WPD、Net、HID 类）。
 - 若你装有：虚拟网卡/屏幕投送/手机助手/某些安全软件，建议做一次“干净启动”验证：
  - msconfig → 服务：勾选“隐藏所有 Microsoft 服务”→ 全部禁用；启动项全部禁用；重启后只测试拓展坞。
 B) USB 控制器与 UCSI 设备重装（让 Windows 重新枚举端口控制器）
 - 设备管理器：
  - 在“通用串行总线控制器”下，对 Intel(R) USB 3.20 xHCI 兼容主机控制器、USB Root Hub(USB 3.0) 逐个“卸载设备”（不要勾选删除驱动），重启让系统自动重装。
  - 在“系统设备”下找到 UCSI/USB Connector Manager/Type-C Port Controller（名称可能不同），同样可尝试卸载后重启。
 C) 电源管理彻底关闭（用于验证是否为省电导致的复位/掉线）
 - 电源选项：USB 选择性暂停 = 禁用。
 - 设备管理器：对所有 USB Root Hub(USB 3.0) 取消“允许计算机关闭此设备以节约电源”。
 D) 如果以上软件侧验证均无变化：倾向硬件层（端口的 CC/供电开关/保护电路）
 - 由于该口对 SSD 正常、对复杂 Hub 链路闪断，典型是端口在“多设备/Hub 拉起”时触发保护或协商异常。
 - 此时较实用的最终验证是：
  - 用同主板的其他 Type-C（若有）对比；或
  - 使用带独立供电、且对上游兼容性更强的不同型号拓展坞/Type-C Hub 交叉验证；
  - 若仅此口对所有 Hub/坞均闪断，而直连设备正常，则可基本判定该 Type-C 口的相关硬件链路存在问题。
@@ -0,0 +1,176 @@
 <!doctype html>
 <html lang="zh-CN">
 <head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Billing Validator — 周报 (2026-01-21)</title>
  <style>
    :root{
      /* 调整为浅色但非纯白的配色 */
      --bg: #eef3f8; /* 页面背景：柔和的浅蓝灰 */
      --text: #0f1722; /* 深色文字 */
      --accent: #1f6feb; /* 主色 */
      --muted: #556678; /* 次要文字 */
      --card-bg: #fbfdff; /* 卡片背景：非常浅但不是纯白 */
      --panel-bg: #fcfdff; /* 面板背景：接近卡片但有轻微差别 */
      --tag-bg: rgba(31,111,235,0.08);
    }
    /* 全局 box-sizing，避免 padding/margin 导致元素尺寸计算超出容器 */
    *, *::before, *::after { box-sizing: border-box; }
    /* 不显示浏览器滚动条，幻灯片与容器自己收缩/适配 */
    html,body{height:100%;margin:0;background:var(--bg);font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", Arial; color:var(--text);overflow:hidden}
    /* 视口内边距：在大屏上留出更多背景边缘，避免幻灯片看起来过于靠边 */
    .viewport{display:flex;align-items:center;justify-content:center;height:100%;padding:clamp(24px, 4vw, 120px);box-sizing:border-box;overflow:hidden}
    /* 固定 16:9 的幻灯片尺寸 */
    .slide{
      /* 在 4K 等大屏上占更多空间，同时在小屏时使用视口百分比；受限于可见高度 */
      /* 略减宽度上限并留出更多外围空白 */
      width: min(3600px, 92vw);
      aspect-ratio: 16 / 9;
      height: auto;
      max-height: 98vh;
      background:linear-gradient(180deg,var(--card-bg),#fbfdff);
      box-shadow:0 10px 30px rgba(15,23,34,0.12);
      border-radius:12px;
      /* 增大最小内边距，确保内容远离边缘；在大屏上仍可放大 */
      padding: clamp(24px, 3.5vw, 80px);
      box-sizing:border-box;
      display:flex;
      flex-direction:column;
      gap:1.6em;
      overflow:hidden; /* 确保 slide 内部内容不会溢出可视区域 */
      position:relative; /* 作为裁剪和定位上下文 */
      max-width:3600px; /* 在大屏幕上允许更大展示 */
    }
    /* 基于 slide 宽度与高度的字体缩放：在空间不足时文字会自动变小，优先同时兼顾宽高，尽量避免出现滚动条 */
    .slide { --slide-font: clamp(10px, calc(0.8vw + 0.6vh), 20px); font-size: var(--slide-font); }
     .header{display:flex;align-items:flex-start;justify-content:space-between}
    /* 使用 em，使字号随 .slide 的 font-size 缩放 */
    .title{font-size:1.6em;font-weight:700;color:var(--text)}
    .subtitle{font-size:0.85em;color:var(--muted);margin-top:0.4em}
    /* 内容区使用可收缩的弹性布局，防止子元素撑开父容器 */
     .content{display:flex;gap:2em;flex:1;min-height:0;width:100%;box-sizing:border-box;padding:0.2em}
     /* 列和面板需要在 flex 布局中可收缩：min-width:0/box-sizing:border-box */
    .col{flex:1;background:transparent;padding:1.1em 1.4em;border-radius:8px;display:flex;flex-direction:column;min-height:0;min-width:0;box-sizing:border-box}
    /* 不使用内部滚动条：让文字自动换行并通过字体缩放适配空间；若仍溢出，会被裁剪，避免滚动条 */
    .panel{background:linear-gradient(180deg,var(--panel-bg),#fbfdff);padding: clamp(16px, 1.6vw, 48px);border-radius:10px;box-shadow:0 6px 16px rgba(15,23,34,0.04);flex:1;min-height:0;min-width:0;overflow:hidden;border:1px solid rgba(15,23,34,0.04);box-sizing:border-box;max-height:100%;max-width:100%}
    /* 确保列表内不会意外增加宽度或高度 */
    .panel ul, .panel ol {margin:0;box-sizing:border-box}
    h3{font-size:1.1em}
    ul{margin:0;padding-left:1.125em;color:var(--text);line-height:1.6}
    ol{margin:0;padding-left:1.125em;color:var(--text);line-height:1.6}
    li{margin-bottom:0.4em}
    /* 每个子项内部的元信息（状态/负责人/备注） */
    .item-meta{margin-top:0.5em;color:var(--muted);font-size:0.95em;display:block}
    .tag{background:var(--tag-bg);color:var(--accent);padding:0.25em 0.6em;border-radius:999px;font-weight:600;font-size:0.85em;display:inline-block;margin-bottom:0.45em}
    .meta-text{color:var(--muted);display:block;margin:0.25em 0 0 0;padding-left:0.4em}
    .muted{color:var(--muted);font-size:0.95em}
    .footer{display:flex;justify-content:space-between;align-items:center;margin-top:1.4em}
    .pill{background:rgba(31,111,235,0.10);color:var(--accent);padding:0.5em 0.9em;border-radius:999px;font-weight:600;font-size:0.95em;border:1px solid rgba(31,111,235,0.06)}
    /* 使幻灯片在小屏幕上缩放以适应视口 */
    @media (max-width:1300px){
      /* 小屏幕上适当减小字体和内边距 */
      .slide{width:92vw}
      .slide { --slide-font: clamp(11px, 1.6vw, 16px); }
      .slide{padding:1.1em}
    }
    @media (max-width:900px){
      .slide{width:96vw}
      .slide { --slide-font: clamp(10px, 2.0vw, 14px); }
      .slide{padding:0.6em}
    }
  </style>
 </head>
 <body>
  <div class="viewport">
    <div class="slide" role="document" aria-label="Billing Validator 周报 2026-01-21">
      <div class="header">
        <div>
          <div class="title">Billing Validator — 周报</div>
          <div class="subtitle">2026-01-21</div>
        </div>
        <div class="pill">单页汇报 · 16:9</div>
      </div>
      <div class="content">
        <div class="col">
          <div class="panel">
            <h3>一、上周完成的工作</h3>
            <ul>
              <li>
                <strong>部署与测试</strong>
                <div class="item-meta">
                  <span class="tag">Action</span>
                  <div class="meta-text">Billing Validator 新架构已部署到 workstation</div>
                  <div class="meta-text">Status: 已启动 Sutherland LLA 测试</div>
                </div>
              </li>
              <li>
                <strong>与业务侧沟通（Paulina）</strong>
                <div class="item-meta">
                  <span class="tag">Deliverable</span>
                  <div class="meta-text">完成需适配场景清单（节前已适配 19 个 FTE 场景）</div>
                  <div class="meta-text">Vendor list: 已提供</div>
                  <div class="meta-text">SOP: 已提供新版撰写指导；4 个 meta-info table 可做成全局</div>
                </div>
              </li>
              <li>
                <strong>与 IT 对接</strong>
                <div class="item-meta">
                  <span class="tag">Coordination</span>
                  <div class="meta-text">说明需求并传达上线初步计划</div>
                  <div class="meta-text">Sizing: 预计本周完成</div>
                  <div class="meta-text">上线初步目标: 2026-03-31</div>
                </div>
              </li>
              <li>
                <strong>数据对接（chenyao3）</strong>
                <div class="item-meta">
                  <span class="tag">Data</span>
                  <div class="meta-text">澄清若干数据需求；Productive time per day 与 workday 的需求暂时搁置</div>
                  <div class="meta-text">历史数据范围: 最近 6 个月</div>
                </div>
              </li>
            </ul>
          </div>
        </div>
        <div class="col">
          <div class="panel">
            <h3>二、本周 Key Action</h3>
            <ol>
              <li>完成 4 个场景的适配
                <ul>
                  <li>Sutherland-LAS-Premium</li>
                  <li>Sutherland-LAS-STD</li>
                  <li>IBM-NA-STD</li>
                  <li>IBM-LAS-STD</li>
                </ul>
              </li>
              <li>针对业务反馈定位并修复 Sutherland LLA 场景中的测试问题</li>
              <li>修改并验证文件上传到数据库的逻辑（当前代码已开发完成，状态：待测试/部署）</li>
              <li>跟进 IT sizing 结果并确认资源/上线窗口</li>
              <li>跟进 Paulina 提供剩余 FTE 场景的 SOP</li>
            </ol>
            <h3 style="margin-top:14px">三、Risks / Help needed</h3>
            <ul>
              <li>需要 Paulina 持续提供其他 FTE 场景的 SOP（Help Needed）</li>
            </ul>
           </div>
         </div>
       </div>
       <div class="footer">
         <div class="muted">进度简明扼要 — 如需更详细数据请在会后补充</div>
         <div class="muted">生成时间: 2026-01-21</div>
       </div>
     </div>
   </div>
 </body>
 </html>
@@ -0,0 +1,22 @@
 # Billing Validator — 周报 (2026-01-21)
 ## 一、上周完成的工作
 - Billing Validator 新架构已部署到 workstation，已启动 Sutherland LLA 测试
 - 与业务侧沟通（Paulina）：确定需适配场景清单（节前已完成 19 个 FTE 场景的适配），并提供完整 Vendor list；提供新版 SOP 撰写指导；确认 4 个 meta-info table 可做成全局
 - 与 IT 对接（qifeng2 / zhangyj21）：讲解需求并传达上线初步计划，预计本周完成 sizing；初步上线目标：2026-03-31
 - 数据对接（chenyao3）：澄清若干数据需求；Productive time per day 与 workday 的需求暂时搁置；历史数据范围确定为最近 6 个月
 ## 二、本周 Key Action
 1. 完成 4 个场景的适配
   - Sutherland-LAS-Premium
   - Sutherland-LAS-STD
   - IBM-NA-STD
   - IBM-LAS-STD
 2. 针对业务反馈定位并修复 Sutherland LLA 场景中的测试问题
 3. 修改并验证文件上传到数据库的逻辑（当前代码已开发完成，状态：待测试/部署；）
 4. 跟进 IT sizing 结果并确认资源/上线窗口
 5. 跟进 Paulina 提供剩余 FTE 场景的 SOP
 ## 三、Risks / Help needed
 - Help Needed：需要Paulina持续提供其他FTE场景的SOP
@@ -0,0 +1,48 @@
 接下来你的任务是和我一起完成一份周会的PPT。
 我们的任务边界是针对一个项目（Billing Validator）进行一页的PPT。
 我会告知你本周的项目进展，你来整理提炼出PPT的大致内容，然后根据这些内容使用HTML生成一页PPT。
 生成出来的PPT只需要一页即可，需要严格保证是16:9的比例。
 PPT需要包括以下几个板块：
 - 上周完成的任务
 - 本周的Key Action
 - Risks/Help needed
 - 你认为有必要补充的其他内容。
 你的工作输出应当分成两部分：
 1. 首先生成PPT的内容大纲，将这份大纲保存成{当前的日期}.md文件。
   在这一步，你需要和我交互，我会告诉你本周的项目进展情况，然后你根据这些信息生成大纲。你生成完大纲就可以等待我的确认。
 2. 接下来我会review这份大纲，确认无误后你再重新读取大纲文件生成最终的PPT HTML文件，文件名为{当前的日期}.html。
 **注意** 
 - 如果我没有明确提及负责人或者交付物，你就不应当在大纲中添加这些信息。
 - 采用浅色背景深色文字的配色方案。
 - 结构应当清晰，内容简洁明了。
 - PPT内容应当尽量避免出现滚动条，如果内容过多需要进行适当的压缩和调整，确保在16:9的比例下完整展示所有内容。
 - PPT应当适配大屏展示，内容不应当贴边，保持一定的留白。
 ## 归档：2026-01-21 — 本次任务关键点
 - 生成产物
  - 单页 16:9 HTML PPT：`copilot_workspace/weekly_update/2026-01-21.html`
  - 源大纲（Markdown）：`copilot_workspace/weekly_update/2026-01-21.md`
 - 内容结构（已在 PPT 中体现）
  - 上周完成的工作：已将每个子项结构化（小标题 + 多行元信息，如状态/说明/范围），每条元信息另起一行，便于阅读与追踪
  - 本周 Key Action：列出主要行动项（含需要适配的 4 个场景清单）
  - Risks / Help needed：列出需要外部支持的点
  - 其他备注：历史数据范围、上线初步目标等
 - 样式与实现要点（便于复用/维护）
  - 采用响应式 16:9 布局（CSS `aspect-ratio`），在大屏（如 4K）上尽量放大展示，同时限制 `max-height: 98vh` 保持可见
  - 颜色使用变量（浅色非纯白背景 + 深色文字），便于统一主题调整
  - 去掉滚动条（`overflow:hidden`），在空间不足时通过字体缩放（`clamp()` + 相对单位 em/rem）自动收缩内容，避免出现内嵌滚动
  - 使用弹性布局（flex）并设置 `min-width:0` / `min-height:0`，防止子元素撑开父容器导致溢出
  - 面板与列使用响应式内边距（`clamp()` / em），并增大外层留白以避免内容贴边
  - HTML 保持语义化的列表/标题结构，便于后续脚本化处理或导出
 - 迭代记录
  - 按用户反馈多次调整：从简单生成到结构化内容、再到配色与可视区域问题，最终实现“无滚动条 + 自动缩放 + 大屏友好 + 内容不贴边”的效果
 - 后续复用建议
  - 若需复用：更新对应日期的 Markdown 大纲（`{date}.md`）中的板块内容，然后运行相同生成流程（读取大纲并生成 `{date}.html`）即可
  - 如需自动化：可考虑添加一个小脚本（例如 Python 或 Node）读取指定 `.md` 并输出 HTML，或把样式抽成公共 CSS 模板以便复用
@@ -0,0 +1,192 @@
 # Xihe-class Interplanetary Exploration Mothership (Xihe)
 Xihe (Chinese: 羲和) is the first generation of interplanetary exploration motherships, designed for crewed missions to planets and large moons within the Solar System. Intended to operate as a mobile base of operations, Xihe provides life support, long-duration habitation, scientific laboratories, power generation, and towing capability for planetary surface vehicles. The design emphasizes sustained crew survivability and mission flexibility through modular habitat segments, closed-loop life support with an integrated greenhouse, and a high delta-v propulsion system based on a mass-driver architecture powered by a large fusion Arc-reactor.
 ---
 ## Lead
 The Xihe-class motherships were conceived for sustained, crewed exploration of Mars, Venus, and the moons of the outer planets. Each vessel integrates modular habitat sections arranged along a central spine, a rotating artificial-gravity habitat, redundant power systems, and a mass driver main propulsion system. Xihe is capable of carrying a 300-ton payload (including surface exploration vehicles and supplies) and has a stated delta-v capacity of 1700 km/s in that configuration. Crew support facilities are sized for a nominal complement of 15 for missions up to several years in duration, with short-term capacity for up to 30 personnel.
 ---
 ## Design and layout
 The Xihe-class follows an elongated, multi-segmented cylindrical "spine" arrangement. Major modules are stacked along the central axis to concentrate structural loads during thrust and towing operations while keeping the overall cross-sectional area small to reduce collision risk with micrometeoroids.
 ---
 ### Front docking hub
 The forward section houses a reinforced front docking hub with five docking ports intended for shuttles, landers, and towable surface vehicles. The primary forward docking port is a 2.5 m diameter port that is structurally reinforced for towing under thrust. Four additional telescopic side ports (two 1.875 m and two 1.25 m) are provided for boarding and cargo transfer while the ship is stationary.
 ---
 ### Command center
 Directly aft of the forward hub is the command center. This 5-meter-diameter module accommodates navigation, communications, mission control, and core avionics. It contains two airlocks for EVA (crew and cargo) and is equipped with advanced sensors and redundant computing systems for trajectory, attitude, and systems management.
 ---
 ### Artificial gravity habitat module
 The primary habitation for long-duration missions is a rotating ring habitat with a 25-meter diameter that spins at approximately 4 revolutions per minute to generate roughly 0.41 g of artificial gravity via centrifugal force. The ring contains crew sleeping quarters, dining and recreational spaces, and laboratory facilities oriented to support both nominal habitation and mission science tasks.
 ---
 ### Stationary habitat module
 A non-rotating habitat module immediately aft of the rotating ring provides medical facilities, additional laboratories, storage, and mission-support spaces. With a 5-meter diameter, it is sized to help sustain up to 15 crew members comfortably over prolonged missions.
 ---
 ### Center docking hub and extension modules
 A secondary, center-mounted docking hub follows the habitats. It includes four side-mounted telescopic 1.875 m ports (two directly on the hub and two on extension modules). Each extension module terminates in a 2.5 m observation cupola on its upper face and a communications dish on the lower face. All center-hub docking ports are reinforced for towing under acceleration and are typically used to interface with planetary surface vehicles such as the [Echo Shuttle](/home/Space_Shuttles/Echo_Shuttle) and the [Amalthea MPV](/home/Vehicles/Amalthea). Echo Shuttles are prioritized for atmospheric landings while Amalthea-class vehicles are used primarily for landings on airless bodies.
 ---
 ### Greenhouse module
 A 5-meter-diameter automated greenhouse module supports hydroponic cultivation and contributes to closed-loop life support by recycling carbon dioxide into oxygen and producing fresh foodstuffs. The hydroponic systems include LED lighting, climate control, and automated nutrient delivery. The greenhouse is sized to support the dietary needs of up to 15 crew members for approximately five years given the onboard fertilizer supplies; water and air reclaim systems are effectively indefinite, but nutrient (fertilizer) reserves limit continuous autonomous operations without resupply or in-situ resource production.
 ---
 ### Main storage and secondary storage
 Following the greenhouse is a main storage module (5 m diameter) providing accessible cargo stowage for mission equipment and emergency reserves. The design allows for up to 10.5 months of extra supplies for the full crew complement to permit direct aborts to Earth or rendezvous with the nearest support station in contingency scenarios. A secondary storage module located near the truss stores EVA gear, spare parts, and maintenance supplies.
 ---
 ### Truss structure and small Arc-reactor
 A truss framework separates the habitation and storage modules from the propulsion module. This truss supports radiators, external systems and provides standoff distance to protect the crew from reactor and engine radiation during operation. Two additional docking ports (top and bottom of the truss) support towing operations. Mounted on the lower truss is a small Arc-reactor that provides emergency electrical power sufficient for life support and attitude control in the event of a main reactor failure.
 ---
 ### Propulsion module
 The aft-most section contains the propulsion module with the main mass driver engines, fuel tanks (reaction mass), the primary cold-fusion Arc-reactor rated to produce up to 8 terawatts (TW), radiators, attitude-control thrusters, and communication arrays. The mass driver system expels reaction mass at high exhaust velocities to produce thrust and offers two operating modes:
 - Standard Mode: 2400 kN thrust at an effective specific impulse (Isp) of ~500,000 s for high-efficiency transfers.
 - High-Thrust Mode: up to 3800 kN thrust at an Isp of ~250,000 s for accelerated maneuvers at the expense of fuel economy.
 The engines are smoothly throttleable in both modes to allow precise delta-v budgeting and maneuvering. The propulsion module stores roughly 196.3 tonnes of reaction mass, supporting a stated delta-v capability of 1700 km/s with a 300-ton payload.
 ---
 ## Systems and subsystems
 - Power: Primary power is provided by a large Arc-reactor (cold-fusion) with an 8 TW output; the small Arc-reactor on the truss is a secondary/backup unit for essential loads.
 - Life support: Closed-loop air, water, and waste recycling systems with hydroponics-assisted oxygen regeneration and food production.
 - Radiation shielding: Enhanced shielding around habitat volumes, with the truss providing separation from the main reactor and engine radiation sources.
 - Docking and EVA: Multiple docking ports with telescopic mechanisms and two airlocks in the command center.
 ---
 ## Construction and assembly
 Initial Xihe-class vessels were assembled in low Earth orbit (LEO) using repeated launches of the [Vulture Shuttle](/home/Space_Shuttles/Vulture_Shuttle) to deliver discrete modules and components. Assembly procedures included deploying a center docking hub early in the build sequence, then progressively attaching habitats, storage, truss, and propulsion modules. Larger modules such as the artificial gravity habitat required delivery by heavier-lift launch vehicles.
 Later production shifted to [Star Port Station](/home/Stations/Star_Port_Station), an orbital shipyard in LEO that streamlines assembly and outfitting. Components for later motherships are delivered by larger cargo craft such as [Qingtian](/home/Cargo_Ships/Qingtian), reducing the number of shuttle-class launches required for assembly.
 ---
 ## Operational history
 The first batch of three Xihe motherships was constructed between 2050 and 2055. [XH-01 — Xihe](/home/Exploration_Motherships/Xihe/XH-01) completed in early 2052 and entered service on crewed missions to Mars and the Jovian system. During XH-01 construction, engineering improvements were identified that informed later designs and led to the development of the [Stellaria-class motherships](/home/Exploration_Motherships/Stellaria/ST-01), which adopt a newer [Lightspeed Engine](/home/Engines/Lightspeed_Engine).
 Two of the early Xihe hulls were redesigned during construction to integrate the Lightspeed Engine and other enhancements; these vessels were redesignated as [Stellaria-class](/home/Exploration_Motherships/Stellaria/ST-01) ([ST-01 — Stellaria](/home/Exploration_Motherships/Stellaria/ST-01) and [ST-02 — Kristen](/home/Exploration_Motherships/Stellaria/ST-02)) and entered service supporting [Mars One](/home/Bases/Mars_One) and [Europa Research Outpost](/home/Bases/Europa_Research_Outpost) projects. Subsequent Xihe-class vessels (for example, [XH-02 — Taibai](/home/Exploration_Motherships/Xihe/XH-02)) incorporated incremental upgrades such as improved radiation shielding and augmented life support.
 As missions progressed, Xihe-class ships were used extensively for crew rotation, logistics, and transport of large surface exploration vehicles and construction materials for off-world bases.
 ---
 ## Missions and mission profiles
 Typical Xihe mission packages combine scientific research, surface exploration, base construction support, and technology demonstration. Two common transfer profiles are described:
 - Standard profile: departure burns under ~200 km/s, yielding one-way Earth–Mars transit times commonly between 20 and 140 days depending on planetary alignment and mission constraints.
 - Fast-travel profile: higher-energy burns (up to ~250 km/s per major burn) that reduce travel time; under optimal alignment, Earth–Mars transit can be reduced to as little as 8 days, with significantly increased propellant consumption.
 Mission planners commonly target a practical one-way transit of roughly 30 days for Mars missions and about 70 days for missions to Jupiter's moons while using delta-v budgets that balance time and fuel consumption.
 ---
 ## Specifications
 ### Performance
 - Propulsion: Endurance Mass Driver Propulsion System
 - Main engine thrust: 2400 kN (Standard Mode), 3800 kN (High-Thrust Mode)
 - Specific impulse (Isp): ~500,000 s (Standard Mode), ~250,000 s (High-Thrust Mode)
 - Delta-v: ~1700 km/s (with 300-ton payload)
 ### Mass and dimensions
 - Fuel / reaction mass: ~196.3 t
 - Wet mass (without payload): ~365.3 t
 - Overall length: ~83.4 m
 - Habitation ring diameter: 25 m
 ### Payload and towing
 - Maximum payload: 300 t (including planetary surface exploration vehicles and supplies)
 - Towing capacity: up to 200 t at the reinforced front port; 100 t per side docking port
 ### Crew and endurance
 - Crew (nominal): 15 (sustainable for up to ~5 years with greenhouse support)
 - Short-term capacity: up to 30 crew
 - Life support consumables (without greenhouse): ~315 days for 15 crew
 ---
 ## Fleet
 | Name      | Serial number | Status           | Notes |
 |-----------|---------------|------------------|-------|
 | Xihe      | [XH-01](/home/Exploration_Motherships/Xihe/XH-01) | Active | First of its class; early missions included Mars and Jovian moon exploration. |
 | Stellaria | [ST-01](/home/Exploration_Motherships/Stellaria/ST-01) | Active | Transitional design to Stellaria class; equipped with the Lightspeed Engine. |
 | Kristen   | [ST-02](/home/Exploration_Motherships/Stellaria/ST-02) | Active | Transitional design to Stellaria class; equipped with the Lightspeed Engine. |
 | Taibai    | [XH-02](/home/Exploration_Motherships/Xihe/XH-02) | Active | Second of its class; supported Mars One base expansion. |
 | Changxi   | [XH-03](/home/Exploration_Motherships/Xihe/XH-03) | Testing in LEO | Third of its class; intended to support Europa Research Outpost rotation and Venus exploration. |
 | Unnamed   | [XH-04](/home/Exploration_Motherships/Xihe/XH-04) | Under construction | Fourth of its class; expected completion in mid 2061. |
 ---
 ## Naming and variant notes
 Several Xihe-series hulls were reconfigured during production to incorporate newer propulsion options. Notably, two hulls were redesignated as early [Stellaria](/home/Exploration_Motherships/Stellaria/ST-01) variants ([ST-01 — Stellaria](/home/Exploration_Motherships/Stellaria/ST-01) and [ST-02 — Kristen](/home/Exploration_Motherships/Stellaria/ST-02)) after installation of the [Lightspeed Engine](/home/Engines/Lightspeed_Engine); these transitional vessels bridge the Xihe and Stellaria classes in capability and role.
 ---
 ## Gallery (image placeholders)
 ![Xihe profile diagram](./images/Xihe_profile.png)
 Image description: A three-quarter profile diagram of the Xihe-class mothership showing the elongated multi-segmented spine, forward docking hub with telescopic side ports, command center, rotating habitat ring (25 m diameter), stationary habitat, greenhouse and storage modules, truss structure, and the rear propulsion module with mass driver engines and radiators. The diagram is annotated to indicate module diameters, docking-port sizes (2.5 m front port; 1.875 m and 1.25 m side ports), and approximate module lengths. Scale bars and a legend for major subsystems are included.
 ![Xihe habitat ring interior view](./images/Xihe_habitat_interior.png)
 Image description: Interior rendering of the rotating habitat ring showing living quarters, communal dining, laboratory racks, and exercise equipment arranged radially. The image includes callouts describing the artificial gravity level (~0.41 g), rotation rate (~4 rpm), and typical hab-space allocations per crewmember. A small greenhouse access corridor connecting to the stationary module is visible.
 ![Xihe propulsion module schematic](./images/Xihe_propulsion_schematic.png)
 Image description: Cutaway schematic of the propulsion module and primary Arc-reactor with labeled components: fusion Arc-reactor (8 TW nominal), main mass driver throats, reaction mass tanks (total ~196.3 t), large radiators, and attitude control thrusters. The schematic contrasts Standard Mode (high Isp, moderate thrust) and High-Thrust Mode (reduced Isp, higher thrust) performance envelopes.
 Notes for image use: The images above are placeholders. When adding actual images to the repository, store them in `data/vehicle_descriptions/en/images/` (or a shared images folder) and ensure the filenames match the references used above. Each image should be accompanied by descriptive alt text and the caption/description block shown here.
 ---
 ## See also
 - [Stellaria-class mothership](/home/Exploration_Motherships/Stellaria/ST-01)
 - [Echo Shuttle](/home/Space_Shuttles/Echo_Shuttle)
 - [Amalthea MPV](/home/Vehicles/Amalthea)
 - [Lightspeed Engine](/home/Engines/Lightspeed_Engine)
 - [Mars One](/home/Bases/Mars_One)
 - [Europa Research Outpost](/home/Bases/Europa_Research_Outpost)
 ## References
 This article is based on the provided Xihe raw specification document supplied by the project. Specific numeric values (engine thrust, Isp, delta-v, masses, module diameters, rotation rate, etc.) are taken from that source and are reported without independent verification.
 ---
 (Article prepared in English and saved to `data/vehicle_descriptions/en/Xihe.md` as a Wikipedia-style entry. Images are referenced as placeholders; please add actual image files in the recommended images directory if available.)
@@ -0,0 +1,14 @@
 接下来需要你和我一起完成一项任务。
 我们的工作是以维基百科的风格撰写航天载具介绍。
 我们将会一步步完成这个任务。
 首先，我会给你提供载具的相关信息，这些信息往往是存储在一个文档中，以markdown格式呈现。有可能有图片，有可能没有图片。如果有的话我会把图片也一并提供给你。
 接下来你会需要读取data/vehicle_descriptions/meta_info.md文件中的内容。这些内容可以更好地帮助你理解关于载具的超链接信息格式，以及一些常用翻译名称。
 然后，你会根据我提供的载具信息，撰写一段符合维基百科风格的载具介绍。如果在撰写过程中遇到了问题，你可以随时向我提问。
 你需要撰写一段包含载具设计、特点和性能的说明性引言。引言应采用中立语气，不得使用任何宣传性语言或主观意见。你应该根据所提供的信息进行适度的内容扩展。你撰写的内容必须尽可能详尽，给到你的载具信息都是关键的信息，你只能在此基础上进行扩充，绝对不可以省略，每一个信息都必须考虑到。
 我会告诉你应当用什么语言来完成撰写。你的输出应当是一个Markdown格式的文件，保存到/data/vehicle_descriptions/对应的语言目录下。你输出的内容应当仿照维基百科的模式，分成多个章节。涉及到其他载具的部分，你应当以超链接超链接的形式进行渲染。维基百科的url根为：/home/Vehicles，在你不确定载具的具体URL的时候，你可以自己指定一个。比如说如果提到Odin Shuttle，你可以指定为/home/Vehicles/Odin_Shuttle。如果给了你图片，你需要尝试从图片中更多的提取载具的相关信息，并呈现在内容中
 注意一下，wiki里面可以有一些图片的部分，这些你需要按照markdown的格式先假定图片存在来进行插入，并针对每一张图片进行详细的描述，后面我会自己去想办法来完成图片的插入工作。
@@ -29,6 +29,8 @@ Here are some translations for vehicle names used in the wiki
 - Endurance Mass Driver Propulsion System - “毅力”质量驱动推进系统
 - Lightspeed Engine - “光速”引擎
 - Arc-reactor - "方舟"冷核聚变反应堆
 - Kristen - 克丽丝腾
 - Muelsyse - 缪尔赛斯
 # Note
 羲和级普遍采用中国神话中与太阳相关的名字，象征着探索太阳系的使命。
@@ -1,88 +1,88 @@
 # Xihe Interplanetary Exploration Mothership
 ## Overview
-Xihe Interplanetary Exploration Mothership is the first generation of interplanetary ship. It is designed for crewed exploration to other planets, such as Mars, Venus, or celestial bodies like the moons of Jupiter and Saturn. The mothership serves as a mobile base of operations, providing life support, navigation, and scientific research capabilities for extended missions in deep space. 
+Xihe Interplanetary Exploration Mothership is the first generation of interplanetary ships. It is designed for crewed exploration to other planets, such as Mars, Venus, or celestial bodies like the moons of Jupiter and Saturn. The mothership serves as a mobile base of operations, providing life support, navigation, and scientific research capabilities for extended missions in deep space. 
 Xihe is named after the Chinese Solar Deity, symbolizing its role in exploring the solar system. The ship is equipped with advanced propulsion systems, radiation shielding, and modular habitats to ensure the safety and comfort of its crew during long-duration missions.
 ## Key Features:
-1. **Propulsion System**: Xihe utilizes a mass driver propulsion system, allowing for efficient travel over vast distances in space. The main engines are powered by a large fusion reactor to expel mass at high velocities. It has a delta-v capacity of 1700km/s when carrying a 300-ton payload(including 100 tons for planetary surface exploration vehicles and supplies).
+1. **Propulsion System**: Xihe utilizes a mass driver propulsion system, allowing for efficient travel over vast distances in space. The main engines are powered by a large fusion reactor to expel mass at high velocities. It has a delta-v capacity of 1700 km/s when carrying a 300-ton payload (including 100 tons for planetary surface exploration vehicles and supplies).
 2. **Life Support**: The mothership is equipped with closed-loop life support systems that recycle air, water, and waste, ensuring sustainability for missions lasting several years. The on-board greenhouse can support a crew of up to 15 members. 
-3. **Artificial Gravity**: To mitigate the effects of long-term weightlessness, Xihe features a rotating habitat module that generates artificial gravity through centrifugal force. This helps maintain crew health and well-being during extended missions. The habitat module is able to produce up to 0.41g of artificial gravity.
+3. **Artificial Gravity**: To mitigate the effects of long-term weightlessness, Xihe features a rotating habitat module that generates artificial gravity through centrifugal force. This helps maintain crew health and well-being during extended missions. The habitat module is able to produce up to 0.41 g of artificial gravity.
 4. **Towing Capability**: Xihe is designed to tow smaller spacecraft, such as landers and shuttles. It has multiple docking ports and a robust structural framework to accommodate the stresses of towing during interplanetary travel.
 5. **Scientific Research**: The mothership is equipped with state-of-the-art laboratories and observation decks, allowing for in-depth scientific research and data collection during missions. It also has facilities for remote operation of planetary exploration vehicles.
 ## Design:
-The overall shape of Xihe is an elongated, muti-segmented cylinder or spine, with major modules stacked together along a central axis. This allows for better structural integrity during main engine thrust and towing operations, while minimizing the ship's cross-sectional area to reduce collision risks with micrometeoroids and space debris.
+The overall shape of Xihe is an elongated, multi-segmented cylinder or spine, with major modules stacked together along a central axis. This allows for better structural integrity during main engine thrust and towing operations, while minimizing the ship's cross-sectional area to reduce collision risks with micrometeoroids and space debris.
 ### Front docking hub
-At the front of the ship is a large docking hub with 5 docking ports for smaller spacecraft. The front docking port is structurally reinforced to handle the stresses of towing operations, while 4 telescopic side ports are only used when the ship is stationary. The front docking ports is a 2.5m docking port, and the side ports are 2 1.875m ports and 2 1.25m ports.
+At the front of the ship is a large docking hub with five docking ports for smaller spacecraft. The front docking port is structurally reinforced to handle the stresses of towing operations, while four telescopic side ports are only used when the ship is stationary. The front docking port is a 2.5 m port, and the side ports are two 1.875 m ports and two 1.25 m ports.
 ### Command Center
-Directly behind the front docking hub is the command center, which houses the ship's navigation, communication, and control systems. The command center is equipped with advanced sensors and computer systems to ensure safe and efficient operation during interplanetary travel. The command center also packs with two airlocks for crew and cargo EVA operations. With a diameter of 5 meters, the command center is spacious enough to accommodate the ship's crew and essential systems.
+Directly behind the front docking hub is the command center, which houses the ship's navigation, communication, and control systems. The command center is equipped with advanced sensors and computer systems to ensure safe and efficient operation during interplanetary travel. The command center is also equipped with two airlocks for crew and cargo EVA operations. With a diameter of 5 meters, the command center is spacious enough to accommodate the ship's crew and essential systems.
 ### Artificial Gravity Habitat Module
-Located behind the command center is the artificial gravity habitat module. This module is a large rotating ring structure that generates artificial gravity through centrifugal force. The habitat module is designed to provide a comfortable living and working environment for the crew, with sleeping quarters, recreational areas, dining facilities, and science labs. The habitat module has a diameter of 25 meters and rotates at a speed of 4 revolutions per minute to generate 0.41g of artificial gravity.
+Located behind the command center is the artificial gravity habitat module. This module is a large rotating ring structure that generates artificial gravity through centrifugal force. The habitat module is designed to provide a comfortable living and working environment for the crew, with sleeping quarters, recreational areas, dining facilities, and science labs. The habitat module has a diameter of 25 meters and rotates at a speed of 4 revolutions per minute to generate 0.41 g of artificial gravity.
 ### Stationary Habitat Module
 Following the artificial gravity habitat module is the stationary habitat module. This module is non-rotating and provides additional living space for the crew. It includes medical facilities, storage areas, and additional laboratories for scientific research. The stationary habitat module has a diameter of 5 meters and is designed to accommodate up to 15 crew members comfortably.
 ### Center Docking Hub
-After the habitat modules is the center docking hub, which features 4 additional side-mounted docking ports.
+After the habitat modules is the center docking hub, which features four additional side-mounted docking ports.
-2 1.875m telescopic docking ports are directly mounted on the side of the hub, while another 2 1.875m telescopic docking ports are mounted on the side of extension modules. At the top of each extension module is a 2.5 copula module for observation and external monitoring, and the bottom of each extension module houses a communication disk for long-range communication with Earth and other spacecraft. 
+Two 1.875 m telescopic docking ports are directly mounted on the side of the hub, while another two 1.875 m telescopic docking ports are mounted on the side of extension modules. At the top of each extension module is a 2.5 m cupola module for observation and external monitoring, and the bottom of each extension module houses a communications dish for long-range communication with Earth and other spacecraft. 
-All 4 docking ports are structurally reinforced to handle towing operations when the ship is under acceleration.
+All four docking ports are structurally reinforced to handle towing operations when the ship is under acceleration.
-Typically, these docking ports are used to dock with Exploration Vehicles with VTOL and side towing capabilities, like Echo Shuttles or Amalthea MPVs. These vehicles can be used to ferry crew and cargo between the mothership and planetary surfaces. Echo Shuttles are preferred for Atmospheric landings, while Amalthea MPVs are used for airless body landings, though both vehicles are capable of landing on any type of celestial body.
+Typically, these docking ports are used to dock with exploration vehicles with VTOL and side towing capabilities, like Echo Shuttles or Amalthea MPVs. These vehicles can be used to ferry crew and cargo between the mothership and planetary surfaces. Echo Shuttles are preferred for atmospheric landings, while Amalthea MPVs are used for airless body landings, though both vehicles are capable of landing on any type of celestial body.
 ### Greenhouse Module
 Next in line is the greenhouse module, which is essential for long-duration missions. The greenhouse module is designed to grow food and recycle air and water for the crew. It features hydroponic systems, LED grow lights, and climate control to ensure optimal growing conditions for a variety of crops. The greenhouse module has a diameter of 5 meters and is capable of supporting the dietary needs of up to 15 crew members for 5 years. Greenhouse operations are fully automated, requiring minimal crew intervention, allowing the crew to focus on other mission tasks. 
-Greenhouse produce fresh fruits and vegetables, supplementing the crew's diet and improving their overall health and well-being during extended missions. The greenhouse module also plays a crucial role in maintaining the ship's life support systems by recycling carbon dioxide into oxygen through photosynthesis.
+The greenhouse produces fresh fruits and vegetables, supplementing the crew's diet and improving their overall health and well-being during extended missions. The greenhouse module also plays a crucial role in maintaining the ship's life support systems by recycling carbon dioxide into oxygen through photosynthesis.
 The 5-year limit is largely due to fertilizer quantity, as the hydroponic systems require a steady supply of nutrients to sustain plant growth. While water and air can be recycled indefinitely, the finite amount of fertilizer onboard limits the duration of effective greenhouse operations. Resupply missions or the ability to produce fertilizer in-situ would be necessary to extend the operational lifespan of the greenhouse module beyond 5 years.
 ### Main Storage Module
-Behind the greenhouse module is the main storage module. This module is used to store supplies, equipment, and scientific instruments needed for the mission. It is designed to be easily accessible from both the habitat modules and the command center. The main storage module has a diameter of 5 meters and provides ample space for all necessary cargo. Since the life support systems are designed to be closed-loop, there isn't a need for large amounts of consumables storage in normal circumstances. But to prepare for emergencies, the storage module is designed to hold up to 10.5 months worth of extra supplies for the entire crew, allowing a direct abort to Earth or the nearest space station if needed.
+Behind the greenhouse module is the main storage module. This module is used to store supplies, equipment, and scientific instruments needed for the mission. It is designed to be easily accessible from both the habitat modules and the command center. The main storage module has a diameter of 5 meters and provides ample space for all necessary cargo. Since the life support systems are designed to be closed-loop, there isn't a need for large amounts of consumables storage in normal circumstances. But to prepare for emergencies, the storage module is designed to hold up to 10.5 months' worth of extra supplies for the entire crew, allowing a direct abort to Earth or the nearest space station if needed.
 ### Truss Structure
-Following the main storage module is the truss structure, which provides structural support for the ship's propulsion system and other external components. The truss structure is designed to withstand the stresses of interplanetary travel and towing operations. There are also 2 docking ports at the top and bottom of the truss structure for additional docking options, both supporting towing operations. The truss structure is vital for keeping the crew away from the radiation emitted by the main engines during operation.
+Following the main storage module is the truss structure, which provides structural support for the ship's propulsion system and other external components. The truss structure is designed to withstand the stresses of interplanetary travel and towing operations. There are also two docking ports at the top and bottom of the truss structure for additional docking options, both supporting towing operations. The truss structure is vital for keeping the crew away from the radiation emitted by the main engines during operation.
-An additional small Arc-reactor and as well as a secondary storage module are located at the bottom of the truss structure. The small Arc-reactor provides power to the ship in the event of a main reactor failure. It is nowhere near as powerful as the main reactor, but it is sufficient to power essential systems and maintain life support for the crew. The secondary storage module is used to store EVA equipment, spare parts, and other essential supplies needed for maintenance and repairs during the mission.
+An additional small Arc-reactor as well as a secondary storage module are located at the bottom of the truss structure. The small Arc-reactor provides power to the ship in the event of a main reactor failure. It is nowhere near as powerful as the main reactor, but it is sufficient to power essential systems and maintain life support for the crew. The secondary storage module is used to store EVA equipment, spare parts, and other essential supplies needed for maintenance and repairs during the mission.
 ### Propulsion Module
 At the rear of the ship is the propulsion module, which houses the main engines, fuel storage tanks, fusion reactor, additional comms, radiators, attitude control thrusters, and other essential systems needed for interplanetary travel. The propulsion module is designed to provide the necessary thrust and maneuverability for the mothership during its missions. 
-The main engine is a mass driver propulsion system, which expels reaction mass at high velocities to generate thrust. The fusion reactor provides the necessary power to operate the engines and other systems on the ship. The engine is capable of operating at 2 different mode: Standard Mode and High-Thrust Mode. In Standard Mode, the engine provides can produce 2400KN of thrust at an ISP of 500,000s, allowing for efficient travel over long distances. In High-Thrust Mode, the engine can provide a higher thrust output at the cost of reduced specific impulse, allowing for quicker maneuvers and acceleration when needed. In High-Thrust Mode, the engine can produce up to 3800KN of thrust at an ISP of 250,000s. Due to the nature of mass driver propulsion, the engine can be throttled smoothly in both of 2 modes, allowing for precise control over thrust and fuel consumption.
+The main engine is a mass driver propulsion system, which expels reaction mass at high velocities to generate thrust. The fusion reactor provides the necessary power to operate the engines and other systems on the ship. The engine is capable of operating in two different modes: Standard Mode and High-Thrust Mode. In Standard Mode, the engine can produce 2400 kN of thrust at an Isp of 500,000 s, allowing for efficient travel over long distances. In High-Thrust Mode, the engine can provide a higher thrust output at the cost of reduced specific impulse, allowing for quicker maneuvers and acceleration when needed. In High-Thrust Mode, the engine can produce up to 3800 kN of thrust at an Isp of 250,000 s. Due to the nature of mass driver propulsion, the engine can be throttled smoothly in both modes, allowing for precise control over thrust and fuel consumption.
-The main engine requires a significant amount of power to operate, which is provided by the fusion reactor. The main reactor is a large cold fusion Arc-reactor capable of producing up to 8TW of power, most of which is used to power the engines and other critical systems. In the event of a main reactor failure, the small Arc-reactor located at the bottom of the truss structure can provide backup power to essential systems. But it is too weak to power the main engines, but it can power the ship's attitude control thrusters and life support systems, allowing the crew to maintain control of the ship and ensure their safety until repairs can be made or rescue arrives.
+The main engine requires a significant amount of power to operate, which is provided by the fusion reactor. The main reactor is a large cold-fusion Arc-reactor capable of producing up to 8 TW of power, most of which is used to power the engines and other critical systems. In the event of a main reactor failure, the small Arc-reactor located at the bottom of the truss structure can provide backup power to essential systems. It is too weak to power the main engines, but it can power the ship's attitude control thrusters and life support systems, allowing the crew to maintain control of the ship and ensure their safety until repairs can be made or rescue arrives.
-A total of nearly 200 tons of reaction mass is stored in the propulsion module, allowing for a total delta-v of 1700km/s when carrying a 300-ton payload.
+A total of nearly 200 tons of reaction mass is stored in the propulsion module, allowing for a total delta-v of 1700 km/s when carrying a 300-ton payload.
 The propulsion module also includes large radiators to dissipate heat generated by the reactor and engines, ensuring the ship remains within safe operating temperatures.
 ## Construction
-Xihe was originally constructed in LEO using via multiple launches of Vulture Shuttles to deliver components and modules. 
+Xihe was originally constructed in LEO via multiple launches of Vulture Shuttles to deliver components and modules. 
-The first Vulture Shuttle would deploy the Center Docking Hub from its payload bay and dock with it as an operation base. Several other Vulture Shuttles would then deliver additional modules and supplies as needed. The Artificial Gravity Habitat Module was delivered by another super heavy launch vehicle, as even in stored configuration it is too large for the Vulture Shuttle. Once the mothership was fully assembled, it would perform a series of test maneuvers in LEO before embarking on its maiden interplanetary mission. The first batch of Xihe mothership were constructed in this manner, demonstrating the feasibility of Interplanetary Exploration mothership assembly in low Earth orbit.
+The first Vulture Shuttle would deploy the Center Docking Hub from its payload bay and dock with it as an operational base. Several other Vulture Shuttles would then deliver additional modules and supplies as needed. The Artificial Gravity Habitat Module was delivered by another super heavy launch vehicle, as even in stored configuration it is too large for the Vulture Shuttle. Once the mothership was fully assembled, it would perform a series of test maneuvers in LEO before embarking on its maiden interplanetary mission. The first batch of Xihe motherships were constructed in this manner, demonstrating the feasibility of interplanetary exploration mothership assembly in low Earth orbit.
 Subsequent Xihe motherships were constructed in the Star Port Station. Located at LEO, the Star Port Station is a large orbital shipyard capable of assembling and outfitting large spacecraft. The station provides a controlled environment for construction, allowing for more efficient assembly and testing of the motherships before they embark on their missions. Instead of Vulture Shuttles, components and modules for the motherships are delivered to the Star Port Station using larger cargo spacecraft such as Qingtian, streamlining the construction process.
 ## History
-The first batch of 3 Xihe motherships were constructed between 2050 and 2055, with XH-01(Xihe) being the first to be completed in early 2052. During the construction of XH-01, several design improvements were identified that would enhance the performance and capabilities of subsequent motherships, and a possible new configuration for the propulsion system was proposed. These improvements lead to the development of Stellaria class motherships, which incorporated the new Lightspeed Engine, a more advanced propulsion system that offered improved performance and efficiency over the original mass driver propulsion system used in XH-01. As a result, XH-02 and XH-03--the second and third Xihe motherships--were redesigned to incorporate the new engine and other enhancements, leading to the creation of the Stellaria class. They were later redesignated as ST-01(Stellaria) and ST-02(Kristen) respectively.
+The first batch of three Xihe motherships were constructed between 2050 and 2055, with XH-01 (Xihe) being the first to be completed in early 2052. During the construction of XH-01, several design improvements were identified that would enhance the performance and capabilities of subsequent motherships, and a possible new configuration for the propulsion system was proposed. These improvements led to the development of the Stellaria-class motherships, which incorporated the new Lightspeed Engine, a more advanced propulsion system that offered improved performance and efficiency over the original mass driver propulsion system used in XH-01. As a result, XH-02 and XH-03—the second and third Xihe motherships—were redesigned to incorporate the new engine and other enhancements, leading to the creation of the Stellaria class. They were later redesignated as ST-01 (Stellaria) and ST-02 (Kristen), respectively.
-Due to growing need of Mars One base expansion and Europa Research Outpost construction, Stellaria and Kristen were built as transitional designs between Xihe class and Stellaria class motherships, essentially Xihe class motherships with the new Lightspeed Engine. This allowed them to enter into service much earlier than originally planned. Both of which are already enter into service to support Mars One and Europa Research Outpost. Upgrades are planned to bring them closer to the full Stellaria class specifications.
+Due to the growing need for Mars One base expansion and Europa Research Outpost construction, Stellaria and Kristen were built as transitional designs between Xihe class and Stellaria class motherships, essentially Xihe class motherships with the new Lightspeed Engine. This allowed them to enter service much earlier than originally planned. Both have already entered service supporting the Mars One and Europa Research Outpost missions. Upgrades are planned to bring them closer to the full Stellaria-class specifications.
-Near the completion of Kristen, construction of the second batch of Xihe motherships began in 2054 at Star Port station, with XH-02(Taibai) being completed in 2056. XH-02 incorporated several design improvements identified during the construction of the first batch, including enhanced radiation shielding, upgraded life support systems, and improved scientific research capabilities. XH-03(Changxi) was under construction between February 2058 and November 2059, and is currently undergo testing in LEO. XH-04, whose name is unannounced yet, is currently under construction at Star Port station, with completion expected in mid 2061.
+Near the completion of Kristen, construction of the second batch of Xihe motherships began in 2054 at Star Port station, with XH-02 (Taibai) being completed in 2056. XH-02 incorporated several design improvements identified during the construction of the first batch, including enhanced radiation shielding, upgraded life support systems, and improved scientific research capabilities. XH-03 (Changxi) was under construction between February 2058 and November 2059, and is currently undergoing testing in LEO. XH-04, whose name has not yet been announced, is currently under construction at Star Port station, with completion expected in mid 2061.
 ## Naming confusion
-The second and third Xihe motherships were originally intended to be XH-02 and XH-03 respectively. However, during the construction of XH-02, the decision was made to redesignate it as ST-01(Stellaria) after significant design changes were made to incorporate the new Lightspeed Engine and other enhancements.  Similarly, XH-03 was also redesignated as ST-02(Kristen) for the same reasons.
+The second and third Xihe motherships were originally intended to be XH-02 and XH-03 respectively. However, during the construction of XH-02, the decision was made to redesignate it as ST-01 (Stellaria) after significant design changes were made to incorporate the new Lightspeed Engine and other enhancements. Similarly, XH-03 was also redesignated as ST-02 (Kristen) for the same reasons.
-Stellaria and Kristen serve as transitional designs between the Xihe class and the more advanced Stellaria class motherships. They are essentially Xihe class motherships with the new Lightspeed Engine. Both of which are already enter into service to support Mars One and Europa Research Outpost. Upgrades are planned to bring them closer to the full Stellaria class specifications. 
+Stellaria and Kristen serve as transitional designs between the Xihe class and the more advanced Stellaria-class motherships. They are essentially Xihe-class motherships with the new Lightspeed Engine. Both are already in service supporting the Mars One and the Europa Research Outpost.
 ## Specifications
 ### Performance
 - Propulsion: Endurance Mass Driver Propulsion System
- Main Engine Thrust: 2400KN (Standard Mode), 3800KN (High-Thrust Mode)
+- Main Engine Thrust: 2400 kN (Standard Mode), 3800 kN (High-Thrust Mode)
- Specific Impulse: 500,000s (Standard Mode), 250,000s (High-Thrust Mode)
+- Specific Impulse: 500,000 s (Standard Mode), 250,000 s (High-Thrust Mode)
 - Delta-V: 1700 km/s (with 300-ton payload)
 ### Weight and Dimensions
@@ -97,28 +97,28 @@ Stellaria and Kristen serve as transitional designs between the Xihe class and t
 ### Crew
 - Crew Capacity: 15 (sustainable for up to 5 years), 30 (short-term missions)
- Life Support supplies: 315days for 15 crew members without greenhouse support
+- Life Support supplies: 315 days for 15 crew members without greenhouse support
 ## Missions
 Xihe motherships are primarily used for crewed exploration missions to other planets and celestial bodies within the solar system. These missions typically involve a combination of scientific research, celestial body surface exploration, and technology demonstration. The mothership serves as a mobile base of operations, allowing the crew to conduct extended missions in deep space.
-The first Xihe mothership, Xihe(XH-01), carried crew to Mars and Moons of Jupiter for exploration and research. It is heavily involved in the construction of the Mars One base and Europa Research Outpost, providing transportation, logistics support, and scientific expertise for these ambitious projects.
+The first Xihe mothership, Xihe (XH-01), carried crew to Mars and the moons of Jupiter for exploration and research. It has been heavily involved in the construction of the Mars One base and Europa Research Outpost, providing transportation, logistics support, and scientific expertise for these ambitious projects.
 Xihe was used for crew rotation and supply runs to Mars One, as well as ferrying construction materials and equipment for the base's expansion. The mothership's towing capabilities allowed it to transport large planetary surface exploration vehicles and modules needed for the base's development.
-As the construction of Europa Research Outpost started, another Xihe class mothership, Taibai, was built to support crew rotation and base expansion of Mars One, while Xihe was reassigned to support the Europa mission. Xihe transported crew and supplies to Europa, as well as scientific instruments and equipment needed for the outpost's research activities.
+As the construction of Europa Research Outpost started, another Xihe-class mothership, Taibai, was built to support crew rotation and base expansion of Mars One, while Xihe was reassigned to support the Europa mission. Xihe transported crew and supplies to Europa, as well as scientific instruments and equipment needed for the outpost's research activities.
 After the completion of Europa Research Outpost and an expedition to Europa, Xihe was brought back to Star Port for refit and maintenance. Several upgrades from Taibai were retrofitted onto Xihe, including improved radiation shielding, upgraded life support systems, enhanced scientific research capabilities, and better docking hubs. These upgrades ensured that Xihe remained at the forefront of interplanetary exploration technology.
 ### Mission Planning
-With a total delta-v budget of 1700km/s when carrying a 300-ton payload, Xihe motherships will usually perform direct transfers to their destinations. There are 2 typical Trajectory profiles: standard and fast-travel. Standard travel profiles are missions with less than 200km/s departure burns, allowing single Earth-Mars trips to be completed between 20 and 140 days depending on planetary alignment. Fast-travel profiles can reduce travel time to as little as 8 days for Earth-Mars trips when the planets are perfectly aliened, but require higher delta-v burns of up to 250km/s each, significantly increasing fuel consumption.
+With a total delta-v budget of 1700 km/s when carrying a 300-ton payload, Xihe motherships usually perform direct transfers to their destinations. There are two typical trajectory profiles: standard and fast-travel. Standard travel profiles are missions with less than 200 km/s departure burns, allowing single Earth-Mars trips to be completed between 20 and 140 days depending on planetary alignment. Fast-travel profiles can reduce travel time to as little as 8 days for Earth-Mars trips when the planets are perfectly aligned, but require higher delta-v burns of up to 250 km/s each, significantly increasing fuel consumption.
 With the high delta-v capacity, Xihe motherships usually plan their mission profiles to stay within a certain travel time, which means altering the burn durations to achieve the desired travel time. Typical Mars missions will aim for a total travel time of around 30 days one-way, while missions to Jupiter's moons will aim for around 70 days one-way. 
 ## Stellaria
 Stellaria is a class of next-generation interplanetary exploration mothership, building upon the design and capabilities of the Xihe class. It features several advancements in propulsion, life support, and scientific research capabilities, making it well-suited for extended missions to distant planets and celestial bodies within the solar system.
-It is envisioned that Stellaria will take over the roles of Outer Solar System Explorations once enter into service, allowing Xihe class motherships to focus on inner solar system missions and support roles.
+It is envisioned that Stellaria will take over the roles of Outer Solar System explorations once it enters service, allowing Xihe-class motherships to focus on inner solar system missions and support roles.
 ## Fleet
 | Name        | Serial Number | Status             | Notes                                      |  
@@ -0,0 +1,166 @@
 # 羲和级行星际探索母舰（Xihe）
 **羲和级星际探索母舰**（Xihe Interplanetary Exploration Mothership）是人类第一代专为载人行星际探索任务设计的大型航天载具，旨在支持前往火星、金星以及木星与土星卫星等天体的长期深空任务。该级母舰作为移动式深空前哨站，集成生命维持、导航控制与科学实验能力，可在数年尺度的任务周期内为最多**15 名乘员**提供持续支持。其命名源自中国古代神话中的太阳女神“羲和”，象征其在太阳系探索中的核心角色。
 羲和级采用模块化架构，配备先进推进系统、辐射屏蔽结构与人工重力舱段，以保障乘员在长期微重力环境下的健康与任务效能。该级母舰亦具备拖曳能力，可协同多型着陆器与穿梭机执行行星表面作业。首舰“羲和号”（`XH-01`）于 **2052 年**建成。
 ---
 ## 概要
 羲和级主要承担火星、金星及外行星卫星的载人长期任务。在典型任务配置中，羲和可携带约 **300 吨** 有效载荷（含表面载具与补给），在此状态下的总 `Δv` 约为 **1700 km/s**。标准编制为 **15 名船员**，在温室支持下可长期自持；短期舱容可扩展至约 **30 人**。
 ---
 ## 设计与布局
 羲和采用细长的多段式“脊柱”结构，主要模块沿中心轴线堆叠，以便在推进与拖曳时集中承载力，同时减小暴露面积以降低微流星体与空间碎片的风险。
 ### 前部对接舱
 舰首为强化的 **前部对接舱**，设有五个对接端口：主前端口直径 **2.5 m** 并加固以承受推进时的拖曳载荷；四个伸缩侧口（两个 **1.875 m**、两个 **1.25 m**）用于停靠、登船与货物转运。
 ### 指挥中心
 前部对接舱后为 **指挥中心**（直径约 5 m），布置导航、通信与任务控制系统，配备冗余计算与高级传感器，并设有两个气闸以支援人员与货物舱外活动（EVA）。
 ### 人工重力居住环
 主要居住区为直径 **25 m** 的旋转环形舱，通过约 **4 rpm** 的自旋产生约 **0.41 g** 的离心力，缓解长期失重带来的健康问题。环内包含船员起居区、公共活动区、餐厅与实验室，适配长期科学任务与日常生活需求。
 ### 固定式居住模块
 在旋转舱后方设固定（非旋转）居住模块，提供医疗、实验室、仓储与任务支援空间（直径约 **5 m**），与旋转居住环配合维持船员长期生活。
 ### 中部对接舱与延伸模块
 中部对接舱设有四个 **1.875 m** 的侧向伸缩对接口（两个直接在舱体上，两个在延伸单元上）。各延伸单元上方设有直径 **2.5 m** 的观测圆顶，下方配备远距通信天线。中部对接口常用于对接表面运输载具，例如 [回声航天飞机](/home/Space_Shuttles/Echo_Shuttle)（适用于有大气体的着陆）和 [阿玛尔塞亚](/home/Vehicles/Amalthea)（阿玛尔塞亚类多用途载具适用于无气体天体）。
 ### 温室
 舰上配备一座直径约 **5 m** 的自动化温室，用于水培与食物生产，并为闭环生命维持系统提供生物再生支持。以当前配置和肥料储备估算，温室可在一定程度上满足约 **15 名船员约 5 年** 的食物需求；水和空气的回收系统可长期运作，但营养盐耗损会限制完全自主运行，需要补给或原位资源生产以延长续航。
 ### 主/辅助储存
 温室后为主储存模块（直径 **5 m**），存放任务设备与应急物资；设计允许储备额外约 **10.5 个月** 的补给以应对紧急返航或与支援站会合。桁架附近设有辅助仓用于舱外装备、备件与维修用品。
 ### 桁架与小型方舟反应堆
 桁架将居住区与推进模块分隔开来，支撑散热器与外部设备，并在结构上为船员与反应堆/发动机之间提供防护距离。桁架下方安装一台小型 **方舟冷聚变反应堆** 作为后备电源，可维持生命维持与姿态控制的基本功耗。
 ### 推进模块
 舰尾为 **推进模块**，包含主质量驱动发动机、约 **196.3 吨** 的推进剂罐、主方舟反应堆（额定约 **8 TW**）、大型散热器与姿态控制喷嘴。质量驱动推进器支持两种主要工况：
 - **标准模式（Standard Mode）**：约 **2400 kN** 推力，等效比冲约 **500,000 s**，适合高效长程转移；
 - **高推力模式（High-Thrust Mode）**：推力可达约 **3800 kN**，但等效比冲降至约 **250,000 s**，用于快速机动或高加速时段。
 两个模式均支持平滑推力调节，以便精确管理 `Δv` 预算与机动。按当前设计，舰上推进剂与结构配置在携带 **300 吨** 载荷时可实现约 **1700 km/s** 的总 `Δv`。
 ---
 ## 主要系统
 - **动力**：舰内主电由方舟冷聚变反应堆提供（约 **8 TW**）；桁架上的小型方舟作为后备电源。
 - **生命维持**：闭环的空气、水与废物回收系统，配合温室的生物再生能力以延长自主作业周期。
 - **辐射防护**：在居住区采用加强屏蔽，并通过桁架与舱段间距降低来自反应堆与推进器的辐射剂量。
 - **对接与舱外作业**：多端口对接系统与指挥中心的双气闸支持频繁的货运与舱外活动（EVA）。
 ---
 ## 建造与组装
 首批羲和级在低地球轨道（LEO）组装完成：模块由多次 [Vulture Shuttle](/home/Space_Shuttles/Vulture_Shuttle) 发射到轨并在轨组装，通常先搭建中心对接舱再依次安装居住、仓储、桁架与推进模块。体积较大的旋转舱通常由更重的运载工具送入轨道。
 此后产线迁移至轨道造船厂 [Star Port Station](/home/Stations/Star_Port_Station)，并通过更大载运能力的货运飞船（例如 [擎天](/home/Cargo_Ships/Qingtian)）供给组件，从而简化组装流程与出厂交付。
 ---
 ## 服役与改进历史
 首批三艘羲和级在2050—2055年间建造完成，[XH-01 — 羲和](/home/Exploration_Motherships/Xihe/XH-01) 于2052年服役，先后执行火星与木星系卫星的载人任务。XH-01 的建造与试验过程中发现了若干改进方向，促成后续设计演进并催生了采用新型推进器的**万星园级（Stellaria）**。
 在建造过程中有两艘早期船体被改装以整合**“光速”引擎**与其它升级，改型后成为万星园过渡舰（[ST-01 — 万星园](/home/Exploration_Motherships/Stellaria/ST-01) 与 [ST-02 — 克丽丝腾](/home/Exploration_Motherships/Stellaria/ST-02)），并被用于支持 [Mars One](/home/Bases/Mars_One) 与 [Europa Research Outpost](/home/Bases/Europa_Research_Outpost) 等项目。后续的羲和级舰体（如 [XH-02 — 太白](/home/Exploration_Motherships/Xihe/XH-02)）则陆续采用改进的辐射屏蔽与增强的生命维持能力。
 羲和级的主要任务包括船员轮换、后勤补给、运送大型表面载具与基建材料，及支援行星基地建设。
 ---
 ## 任务与轨道概述
 常见的转移剖面包括：
 - 标准剖面：单次主要机动约在 **200 km/s** 量级，地球—火星单程时间通常在 **20—140 天** 之间（视轨道排列与任务要求）；
 - 快速剖面：采用更高能量燃烧（单次可达约 **250 km/s**），在最佳相位下可将地球—火星单程缩短至约 **8 天**，但消耗显著更多推进剂。
 任务规划通常在航行时间与推进剂消耗之间权衡；实务上，火星约 **30 天**、木星卫星约 **70 天** 的单程时间是常见目标。
 ---
 ## 规格要点
 ### 推进性能
 - 推进系统：Endurance Mass Driver Propulsion System
 - 主发动机推力：约 **2400 kN**（标准），约 **3800 kN**（高推力）
 - 比冲（Isp）：约 **500,000 s**（标准），约 **250,000 s**（高推力）
 - 典型 `Δv`：约 **1700 km/s**（在 **300 吨** 载荷条件下）
 ### 质量与尺寸
 - 推进剂质量：约 **196.3 吨**
 - 舰体质量（不含载荷）：约 **365.3 吨**
 - 全长：约 **83.4 米**
 - 居住环直径：**25 米**
 ### 载荷与拖曳
 - 最大有效载荷：约 **300 吨**（含表面探测载具与补给）
 - 拖曳能力：前部强化端口可拖曳约 **200 吨**；侧向端口约 **100 吨/口**
 ### 船员与续航
 - 标准船员：**15 人**（温室支持下可持续多年）
 - 短期最大：约 **30 人**
 - 无温室时生命维持消耗：约 **315 天**（**15 人**）
 ---
 ## 舰队
 | 名称 | 舰号（超链） | 状态 | 备注 |
 |---|---:|---|---|
 | 羲和号 | [XH-01](/home/Exploration_Motherships/Xihe/XH-01) | 在役 | 本级首舰，早期任务覆盖火星与木卫一。 |
 | 万星园号 | [ST-01](/home/Exploration_Motherships/Stellaria/ST-01) | 在役 | 过渡性改装舰，配装 **“光速” 引擎**。 |
 | 克丽丝腾号 | [ST-02](/home/Exploration_Motherships/Stellaria/ST-02) | 在役 | 过渡性改装舰。 |
 | 太白号 | [XH-02](/home/Exploration_Motherships/Xihe/XH-02) | 在役 | 二号舰，参与 Mars One 任务。 |
 | 常羲号 | [XH-03](/home/Exploration_Motherships/Xihe/XH-03) | 在轨试验 | 三号舰，计划支持欧罗巴与金星任务。 |
 | 未命名号 | [XH-04](/home/Exploration_Motherships/Xihe/XH-04) | 建造中 | 预计 2061 年中完工。 |
 ---
 ## 命名与变体说明
 在建造和服役过程中，若干羲和舰体曾被改装以整合新技术或推进方案；改装后部分船体被重新编号，作为过渡型号服役（例如万星园过渡舰）。
 ---
 ## 图库（占位图片，引用英文本地资源）
 ![羲和剖面示意图](../en/images/Xihe_profile.png)
 （图注略，见英文版）
 ---
 ## 参见
 - [万星园级母舰](/home/Exploration_Motherships/Stellaria/ST-01)
 - [回声航天飞机](/home/Space_Shuttles/Echo_Shuttle)
 - [阿玛尔塞亚](/home/Vehicles/Amalthea)
 - [“光速”引擎](/home/Engines/Lightspeed_Engine)
 - [Mars One](/home/Bases/Mars_One)
 - [Europa Research Outpost](/home/Bases/Europa_Research_Outpost)
 ---
 ## 参考
 本文基于项目提供的羲和原始规范文本撰写；文中数值与参数来自该来源。
 (中文条目已更新并保存为 `data/vehicle_descriptions/zh/Xihe.md`。)
@@ -0,0 +1,292 @@
 ######################################################################
 ### Automated Landing Library and Example
 ######################################################################
 ###   Like all of the scripts in my folder here, this file contains
 ###   functions you might want to include into your own scripts for
 ###   actual use and a demo in the 'main' function that you can just
 ###   run to see how it works.
 ###
 ###  This file shows how to complete an automated landing.  It
 ###  does so in three phases - a deorbital burn, a suicide burn to a
 ###  safety altitude and speed, and then a speed limited descent to
 ###  final touch down.
 ######################################################################
 import krpc
 import math
 import time
 import numpy as np
 from pid import PID
 ##############################################################################
 ###   Main function - demonstrates the use of this library. Simply lands
 ###   a vessel.   Only propulsive landing - so really designed for planets
 ###   without an atmosphere.
 ##############################################################################
 def main():
    ''' Main function that demonstrates how to use the pieces of
    this landing library.
    Connects to KRPC server, performs a deorbit burn, then a
    suicide burn, then a final descent.
    '''
    conn = krpc.connect()
    sc = conn.space_center
    v = sc.active_vessel
    deorbit(v, .3)
    suicide_burn(conn, v)
    final_descent(v)
 ###############################################################################
 ###     High Level Functions
 ###
 ###     These are the ones you'd actually maybe want to call from your script.
 ###############################################################################
 def deorbit(vessel, eccentricity):
    '''executes a deorbit burn until the given eccentricity
    is achieved.   If periapsis remains above the equatorial
    radius, it continues burning.
    '''
    print("Deorbiting Vessel...")
    vessel.control.speed_mode = vessel.control.speed_mode.surface
    ap = vessel.auto_pilot
    ap.sas = True
    time.sleep(.1)
    ap.sas_mode = ap.sas_mode.retrograde
    while (vessel.orbit.eccentricity < eccentricity or
           vessel.orbit.periapsis_altitude > 0):
        vessel.control.throttle = 1.0
    vessel.control.throttle = 0.0
 def suicide_burn(conn, vessel, autowarp=True):
    '''
    Performs a 'Suicide Burn' using the calculator class.
    '''
    print("Calculating Suicide Burn...")
    telem = vessel.flight(vessel.orbit.body.reference_frame)
    vessel.control.speed_mode = vessel.control.speed_mode.surface
    rf = vessel.orbit.body.reference_frame
    ap = vessel.auto_pilot
    ap.sas = True
    time.sleep(.1)
    ap.sas_mode = ap.sas_mode.retrograde
    ##calculate initial burn
    computer = suicide_burn_calculator(conn, vessel, 5000)
    computer.update()  # run once with altitude of 5000m to get an estimated groundtrack distance
    touchdown = coords_down_bearing(telem.latitude, telem.longitude, (180 + telem.heading), computer.ground_track,
                                    vessel.orbit.body)
    # update actual safe altitude over the groundtrack
    computer.alt = check_terrain(telem.latitude, telem.longitude, touchdown[0], touchdown[1], vessel.orbit.body)
    # Initial burn - aiming for the 'safe alt' (highest point over course)
    # and a vertical velocity of 10 m/s
    burn_until_velocity(conn, vessel, telem, 10, computer, True)
    ## update computer ti aim for 10m above current altitude.
    computer.alt = vessel.orbit.body.surface_height(telem.latitude, telem.longitude) + 10
    # Second half of burn - aiming for ground alt + 10m and a vertical
    # velocity of 5 m/s
    burn_until_velocity(conn, vessel, telem, 5, computer, True)
 def burn_until_velocity(conn, vessel, telem, thresh, computer, autowarp):
    '''
    Helper Function for suicide_burn function - actually executes a burn
    at the calculated time and burns until it reaches the threshold
    vertical velocity.
    '''
    countdown = computer.update()
    print("Burn in {} seconds".format(countdown))
    if autowarp and (countdown > thresh):
        conn.space_center.warp_to(conn.space_center.ut + countdown - 10)  # warp to 10 seconds before burn
    while countdown > 0.0:  # Wait until suicide burn
        time.sleep(.1)
        countdown = computer.update()
    while telem.vertical_speed < (-1 * thresh):  # Loop until we're ready for final descent
        countdown = computer.update()
        vessel.control.throttle = .95  # 95% throttle
        if countdown < 0.0:  # use the emergencty 5% of throttle when needed
            vessel.control.throttle = 1.0
    vessel.control.throttle = 0.0
 def final_descent(v):
    ''' manages final descent.  At the moment keeps vertical velocity limited to 1/10 of the
    current altitude above terrain - so at 200m would try to descend at 20m/s and at 10 m/s locks
    descent speed to 1m/s.
    '''
    print("final descent")
    telem = v.flight(v.orbit.body.reference_frame)
    v.control.speed_mode = v.control.speed_mode.surface
    ap = v.auto_pilot
    ap.sas = True
    time.sleep(.1)
    ap.sas_mode = ap.sas_mode.retrograde
    p = PID(.25, .25, .025)
    while v.situation is not v.situation.landed:
        # ap.sas_mode = ap.sas_mode.retrograde   # SAS leaves retrograde mode if velocity gets to zero.
        safe_descent = telem.surface_altitude / -10
        # print safe_descent
        if safe_descent < -15.0:
            safe_descent = -15.0
        p.setpoint(safe_descent)
        v.control.throttle = p.update(telem.vertical_speed)
    v.control.throttle = 0
 ###############################################################################
 ##     Burn Calculator Class
 ###############################################################################
 class suicide_burn_calculator(object):
    '''
    Class that calculates time until suicide burn.
    '''
    def __init__(self, conn, v, alt):
        self.conn = conn
        self.v = v
        self.sc = conn.space_center
        self.burn_time = np.inf
        self.burn_duration = np.inf
        self.ground_track = np.inf
        self.effective_decel = np.inf
        self.radius = np.inf
        self.angle_from_horizontal = np.inf
        self.impact_time = np.inf
        self.alt = alt
        self.rf = self.sc.ReferenceFrame.create_hybrid(
            position=self.v.orbit.body.reference_frame,
            rotation=self.v.surface_reference_frame)
    def update(self):
        '''
        Returns an estimate of how many seconds until you need to burn at 95% throttle to avoid crashing.
        This gives a 5% safety margin.
        I do not even PRETEND to understand all of the math in this function.  It's essentially a porting
        of the routine from the Mechjeb orbit extensions.
        '''
        if self.v.orbit.periapsis_altitude > 0:  ## We're not on a landing trajectory yet.
            self.burn_time = np.inf
            self.burn_duration = np.inf
            self.ground_track = np.inf
            self.effective_decel = np.inf
            self.angle_from_horizontal = np.inf
            self.impact_time = np.inf
            return self.burn_time
        rf = self.v.orbit.body.reference_frame
        # calculate sin of angle from horizontal -
        v1 = self.v.velocity(self.rf)
        v2 = (0, 0, 1)
        self.angle_from_horizontal = angle_between(v1, v2)
        sine = math.sin(self.angle_from_horizontal)
        # estimate deceleration time
        g = self.v.orbit.body.surface_gravity
        T = (self.v.max_thrust / self.v.mass) * .95  # calculating with 5% safety margin!
        self.effective_decel = .5 * (-2 * g * sine + math.sqrt((2 * g * sine) * (2 * g * sine) + 4 * (T * T - g * g)))
        self.decel_time = self.v.flight(self.rf).speed / self.effective_decel
        # estimate time until burn
        radius = self.v.orbit.body.equatorial_radius + self.alt
        TA = self.v.orbit.true_anomaly_at_radius(radius)
        TA = -1 * TA  # look on the negative (descending) side of the orbit
        self.impact_time = self.v.orbit.ut_at_true_anomaly(TA)
        self.burn_time = self.impact_time - self.decel_time / 2
        self.ground_track = ((self.burn_time - self.sc.ut) * self.v.flight(self.rf).speed) + (
                .5 * self.v.flight(self.rf).speed * self.decel_time)
        return self.burn_time - self.sc.ut
 ###############################################################################
 ##     Ground Navigation Functions   -   Probably ought to move to their
 ##                                        own library file some day.
 ###############################################################################
 def coords_down_bearing(lat, lon, bearing, distance, body):
    '''
    Takes a latitude, longitude and bearing in degrees, and a
    distance in meters over a given body.  Returns a tuple
    (latitude, longitude) of the point you've calculated.
    '''
    bearing = math.radians(bearing)
    R = body.equatorial_radius
    lat = math.radians(lat)
    lon = math.radians(lon)
    lat2 = math.asin(math.sin(lat) * math.cos(distance / R) +
                     math.cos(lat) * math.sin(distance / R) * math.cos(bearing))
    lon2 = lon + math.atan2(math.sin(bearing) * math.sin(distance / R
                                                         ) * math.cos(lat), math.cos(distance / R) - math.sin(lat
                                                                                                              ) * math.sin(
        lat2))
    lat2 = math.degrees(lat2)
    lon2 = math.degrees(lon2)
    return (lat2, lon2)
 def check_terrain(lat1, lon1, lat2, lon2, body):
    '''
    Returns an estimate of the highest terrain altitude betwen
            two latitude / longitude points.
    '''
    lat = lat1
    lon = lon1
    highest_lat = lat
    highest_lon = lon
    highest_alt = body.surface_height(lat, lon)
    latstep = (lat2 - lat1) / 20
    lonstep = (lon2 - lon1) / 20
    for x in range(20):
        test_alt = body.surface_height(lat, lon)
        if test_alt > highest_alt:
            highest_lat = lat
            highest_lon = lon
            highest_alt = test_alt
        lat = lat + latstep
        lon = lon + lonstep
    return highest_alt
 ###############################################################################
 ##     Vector Math Functions        -   Probably ought to move to their
 ##                                        own library file some day.
 ###############################################################################
 def unit_vector(vector):
    """ Returns the unit vector of the vector provided.  """
    return vector / np.linalg.norm(vector)
 def angle_between(v1, v2):
    """ Returns the angle in radians between vectors 'v1' and 'v2'"""
    v1_u = unit_vector(v1)
    v2_u = unit_vector(v2)
    return np.arccos(np.clip(np.dot(v1_u, v2_u), -1.0, 1.0))
 main()
@@ -0,0 +1,281 @@
 ######################################################################
 ### Automated Landing Library and Example
 ######################################################################
 ###   Like all of the scripts in my folder here, this file contains
 ###   functions you might want to include into your own scripts for
 ###   actual use and a demo in the 'main' function that you can just
 ###   run to see how it works.
 ###
 ###  This file shows how to complete an automated landing.  It
 ###  does so in three phases - a deorbital burn, a suicide burn to a
 ###  safety altitude and speed, and then a speed limited descent to
 ###  final touch down.
 ######################################################################
 import krpc
 import math
 import time
 import numpy as np
 from pid import PID
 ##############################################################################
 ###   Main function - demonstrates the use of this library. Simply lands
 ###   a vessel.   Only propulsive landing - so really designed for planets
 ###   without an atmosphere.
 ##############################################################################
 ###############################################################################
 ###     High Level Functions
 ###
 ###     These are the ones you'd actually maybe want to call from your script.
 ###############################################################################
 def deorbit(vessel, eccentricity):
    '''executes a deorbit burn until the given eccentricity
    is achieved.   If periapsis remains above the equatorial
    radius, it continues burning.
    '''
    print("Deorbiting Vessel...")
    vessel.control.speed_mode = vessel.control.speed_mode.surface
    ap = vessel.auto_pilot
    ap.sas = True
    time.sleep(.1)
    ap.sas_mode = ap.sas_mode.retrograde
    while (vessel.orbit.eccentricity < eccentricity or
           vessel.orbit.periapsis_altitude > 0):
        vessel.control.throttle = 1.0
    vessel.control.throttle = 0.0
 def suicide_burn(conn, vessel, autowarp=True):
    '''
    Performs a 'Suicide Burn' using the calculator class.
    '''
    print("Calculating Suicide Burn...")
    telem = vessel.flight(vessel.orbit.body.reference_frame)
    vessel.control.speed_mode = vessel.control.speed_mode.surface
    rf = vessel.orbit.body.reference_frame
    ap = vessel.auto_pilot
    ap.sas = True
    time.sleep(.1)
    ap.sas_mode = ap.sas_mode.retrograde
    ##calculate initial burn
    computer = suicide_burn_calculator(conn, vessel, 5000)
    computer.update()  # run once with altitude of 5000m to get an estimated groundtrack distance
    touchdown = coords_down_bearing(telem.latitude, telem.longitude, (180 + telem.heading), computer.ground_track,
                                    vessel.orbit.body)
    # update actual safe altitude over the groundtrack
    computer.alt = check_terrain(telem.latitude, telem.longitude, touchdown[0], touchdown[1], vessel.orbit.body)
    # Initial burn - aiming for the 'safe alt' (highest point over course)
    # and a vertical velocity of 10 m/s
    burn_until_velocity(conn, vessel, telem, 10, computer, True)
    ## update computer ti aim for 10m above current altitude.
    computer.alt = vessel.orbit.body.surface_height(telem.latitude, telem.longitude) + 10
    # Second half of burn - aiming for ground alt + 10m and a vertical
    # velocity of 5 m/s
    burn_until_velocity(conn, vessel, telem, 5, computer, True)
 def burn_until_velocity(conn, vessel, telem, thresh, computer, autowarp):
    '''
    Helper Function for suicide_burn function - actually executes a burn
    at the calculated time and burns until it reaches the threshold
    vertical velocity.
    '''
    countdown = computer.update()
    print("Burn in {} seconds".format(countdown))
    if autowarp and (countdown > thresh):
        conn.space_center.warp_to(conn.space_center.ut + countdown - 10)  # warp to 10 seconds before burn
    while countdown > 0.0:  # Wait until suicide burn
        time.sleep(.1)
        countdown = computer.update()
    while telem.vertical_speed < (-1 * thresh):  # Loop until we're ready for final descent
        countdown = computer.update()
        vessel.control.throttle = .95  # 95% throttle
        if countdown < 0.0:  # use the emergencty 5% of throttle when needed
            vessel.control.throttle = 1.0
    vessel.control.throttle = 0.0
 def final_descent(v):
    ''' manages final descent.  At the moment keeps vertical velocity limited to 1/10 of the
    current altitude above terrain - so at 200m would try to descend at 20m/s and at 10 m/s locks
    descent speed to 1m/s.
    '''
    print("final descent")
    telem = v.flight(v.orbit.body.reference_frame)
    v.control.speed_mode = v.control.speed_mode.surface
    ap = v.auto_pilot
    ap.sas = True
    time.sleep(.1)
    ap.sas_mode = ap.sas_mode.retrograde
    p = PID(.25, .25, .025)
    while v.situation is not v.situation.landed:
        # ap.sas_mode = ap.sas_mode.retrograde   # SAS leaves retrograde mode if velocity gets to zero.
        safe_descent = telem.surface_altitude / -10
        # print safe_descent
        if safe_descent < -15.0:
            safe_descent = -15.0
        p.setpoint(safe_descent)
        v.control.throttle = p.update(telem.vertical_speed)
    v.control.throttle = 0
 ###############################################################################
 ##     Burn Calculator Class
 ###############################################################################
 class suicide_burn_calculator(object):
    '''
    Class that calculates time until suicide burn.
    '''
    def __init__(self, conn, v, alt):
        self.conn = conn
        self.v = v
        self.sc = conn.space_center
        self.burn_time = np.inf
        self.burn_duration = np.inf
        self.ground_track = np.inf
        self.effective_decel = np.inf
        self.radius = np.inf
        self.angle_from_horizontal = np.inf
        self.impact_time = np.inf
        self.alt = alt
        self.rf = self.sc.ReferenceFrame.create_hybrid(
            position=self.v.orbit.body.reference_frame,
            rotation=self.v.surface_reference_frame)
    def update(self):
        '''
        Returns an estimate of how many seconds until you need to burn at 95% throttle to avoid crashing.
        This gives a 5% safety margin.
        I do not even PRETEND to understand all of the math in this function.  It's essentially a porting
        of the routine from the Mechjeb orbit extensions.
        '''
        if self.v.orbit.periapsis_altitude > 0:  ## We're not on a landing trajectory yet.
            self.burn_time = np.inf
            self.burn_duration = np.inf
            self.ground_track = np.inf
            self.effective_decel = np.inf
            self.angle_from_horizontal = np.inf
            self.impact_time = np.inf
            return self.burn_time
        rf = self.v.orbit.body.reference_frame
        # calculate sin of angle from horizontal -
        v1 = self.v.velocity(self.rf)
        v2 = (0, 0, 1)
        self.angle_from_horizontal = angle_between(v1, v2)
        sine = math.sin(self.angle_from_horizontal)
        # estimate deceleration time
        g = self.v.orbit.body.surface_gravity
        T = (self.v.max_thrust / self.v.mass) * .95  # calculating with 5% safety margin!
        self.effective_decel = .5 * (-2 * g * sine + math.sqrt((2 * g * sine) * (2 * g * sine) + 4 * (T * T - g * g)))
        self.decel_time = self.v.flight(self.rf).speed / self.effective_decel
        # estimate time until burn
        radius = self.v.orbit.body.equatorial_radius + self.alt
        TA = self.v.orbit.true_anomaly_at_radius(radius)
        TA = -1 * TA  # look on the negative (descending) side of the orbit
        self.impact_time = self.v.orbit.ut_at_true_anomaly(TA)
        self.burn_time = self.impact_time - self.decel_time / 2
        self.ground_track = ((self.burn_time - self.sc.ut) * self.v.flight(self.rf).speed) + (
                .5 * self.v.flight(self.rf).speed * self.decel_time)
        return self.burn_time - self.sc.ut
 ###############################################################################
 ##     Ground Navigation Functions   -   Probably ought to move to their
 ##                                        own library file some day.
 ###############################################################################
 def coords_down_bearing(lat, lon, bearing, distance, body):
    '''
    Takes a latitude, longitude and bearing in degrees, and a
    distance in meters over a given body.  Returns a tuple
    (latitude, longitude) of the point you've calculated.
    '''
    bearing = math.radians(bearing)
    R = body.equatorial_radius
    lat = math.radians(lat)
    lon = math.radians(lon)
    lat2 = math.asin(math.sin(lat) * math.cos(distance / R) +
                     math.cos(lat) * math.sin(distance / R) * math.cos(bearing))
    lon2 = lon + math.atan2(math.sin(bearing) * math.sin(distance / R
                                                         ) * math.cos(lat), math.cos(distance / R) - math.sin(lat
                                                                                                              ) * math.sin(
        lat2))
    lat2 = math.degrees(lat2)
    lon2 = math.degrees(lon2)
    return (lat2, lon2)
 def check_terrain(lat1, lon1, lat2, lon2, body):
    '''
    Returns an estimate of the highest terrain altitude betwen
            two latitude / longitude points.
    '''
    lat = lat1
    lon = lon1
    highest_lat = lat
    highest_lon = lon
    highest_alt = body.surface_height(lat, lon)
    latstep = (lat2 - lat1) / 20
    lonstep = (lon2 - lon1) / 20
    for x in range(20):
        test_alt = body.surface_height(lat, lon)
        if test_alt > highest_alt:
            highest_lat = lat
            highest_lon = lon
            highest_alt = test_alt
        lat = lat + latstep
        lon = lon + lonstep
    return highest_alt
 ###############################################################################
 ##     Vector Math Functions        -   Probably ought to move to their
 ##                                        own library file some day.
 ###############################################################################
 def unit_vector(vector):
    """ Returns the unit vector of the vector provided.  """
    return vector / np.linalg.norm(vector)
 def angle_between(v1, v2):
    """ Returns the angle in radians between vectors 'v1' and 'v2'"""
    v1_u = unit_vector(v1)
    v2_u = unit_vector(v2)
    return np.arccos(np.clip(np.dot(v1_u, v2_u), -1.0, 1.0))
 if __name__ == "__main__":
    conn = krpc.connect()
    sc = conn.space_center
    v = sc.active_vessel
    suicide_burn(conn, v)
    final_descent(v)
@@ -0,0 +1,133 @@
 ##############################################################################
 ### PID Controller Library and Example
 ##############################################################################
 ###   Like all of the scripts in my folder here, this file contains
 ###   functions you might want to include into your own scripts for
 ###   actual use and a demo in the 'main' function that you can just
 ###   run to see how it works.
 ###
 ###   This file includes a simple and generic PID controller that we use in
 ###   many of the other examples when we want to smoothly control one value
 ###   based on our measurement of another.  The PID class docstring explains
 ###   the basics of using it in your project.   The demo code below that
 ###   shows how to use the PID controller to hold a vertical velocity with
 ###   variation of engine thrust.
 ###   From https://github.com/krpc/krpc-library/blob/master/Art_Whaleys_KRPC_Demos/pid.py
 ##############################################################################
 import time
 import krpc
 class PID(object):
    '''
    Generic PID Controller Class
    Based on the PID recipe at :
    http://code.activestate.com/recipes/577231-discrete-pid-controller/
    and the code and discussions in the blog at:
    http://brettbeauregard.com/blog/2011/04/
    improving-the-beginners-pid-introduction/
    An instance is created with the format
    your_pid=PID(P=.0001, I=0.00001, D=0.000001)
    Finding the right values for those three gain numbers is called 'tuning' and
    that's beyond the scope of this doc string!
    Use your_pid.setpoint(X) to set the target output value of the controller.
    Regularly call your_pid.update(Y), passing it the input data that the
    controller should respond to.
    output_data = your_pid.update(input_data)
    '''
    def __init__(self, P=1.0, I=0.1, D=0.01):
        self.Kp = P  # P controls reaction to the instantaneous error
        self.Ki = I  # I controls reaction to the history of error
        self.Kd = D  # D prevents overshoot by considering rate of change
        self.P = 0.0
        self.I = 0.0
        self.D = 0.0
        self.SetPoint = 0.0  # Target value for controller
        self.ClampI = 1.0  # clamps i_term to prevent 'windup.'
        self.LastTime = time.time()
        self.LastMeasure = 0.0
    def update(self, measure):
        now = time.time()
        change_in_time = now - self.LastTime
        if not change_in_time:
            change_in_time = 1.0  # avoid potential divide by zero if PID just created.
        error = self.SetPoint - measure
        self.P = error
        self.I += error
        self.I = self.clamp_i(self.I)  # clamp to prevent windup lag
        self.D = (measure - self.LastMeasure) / (change_in_time)
        self.LastMeasure = measure  # store data for next update
        self.lastTime = now
        return (self.Kp * self.P) + (self.Ki * self.I) - (self.Kd * self.D)
    def clamp_i(self, i):
        if i > self.ClampI:
            return self.ClampI
        elif i < -self.ClampI:
            return -self.ClampI
        else:
            return i
    def setpoint(self, value):
        self.SetPoint = value
        self.I = 0.0
 ##############################################################################
 ## Demo Code Below This Line!
 ##############################################################################
 Target_Velocity = 5  # The value we're trying to limit ourselves to
 ##############################################################################
 ## Main  -- only run when we execute this file directly.
 ##          ignored when we import the PID into other files!
 ##############################################################################
 def main():
    # Setup KRPC
    conn = krpc.connect()
    sc = conn.space_center
    v = sc.active_vessel
    telem = v.flight(v.orbit.body.reference_frame)
    #  Create PID controller.
    p = PID(P=.25, I=0.025, D=0.0025)
    p.ClampI = 20
    p.setpoint(Target_Velocity)
    #  starting with locked SAS and throttle at full
    v.control.sas = True
    v.control.throttle = 1.0
    while not v.thrust:  # stage if we just launched a new rocket
        v.control.activate_next_stage()
    #  Loop Forever, or until you get the point of this example and stop it.
    while True:
        the_pids_output = p.update(telem.vertical_speed)
        v.control.throttle = the_pids_output
        print('Vertical V:{:03.2f}   PID returns:{:03.2f}   Throttle:{:03.2f}'
              .format(telem.vertical_speed,
                      the_pids_output,
                      v.control.throttle))
        time.sleep(.1)
 if __name__ == '__main__':
    main()
    print('--')
@@ -2,6 +2,7 @@ import time
 import krpc
 G_EARTH = 9.80665
 def get_surface_speed():
    conn = krpc.connect(name='Vessel speed')
@@ -62,7 +63,32 @@ def vessel_available_thrust():
        print('Vessel available thrust = %.1f kN' % (thrust / 1000))
        time.sleep(1)
-def auto_land_predictive(host='localhost', port=50000, target_altitude=0.5, target_vspeed=-2.0, safety_margin=5.0, verbose=True):
+def get_body_g(local_vessel):
    try:
        body = local_vessel.orbit.body
        g = float(getattr(body, 'surface_gravity', G_EARTH))
        if g > 0:
            return g
    except Exception:
        pass
    try:
        g = float(getattr(local_vessel.flight(), 'surface_gravity', G_EARTH))
        if g > 0:
            return g
    except Exception:
        pass
    return G_EARTH
 def auto_land_predictive(
        bottom_clearance_margin=12,
        thrust_discount_wait=0.85,
        pre_ignite_seconds=2.5,
        host='localhost',
        port=50000,
        target_altitude=1.0,
        target_vspeed=-1.0,
        safety_margin=3.0,
        verbose=True):
    """预测式自动着陆（suicide burn 思路）。
    关键点：
@@ -81,14 +107,53 @@ def auto_land_predictive(host='localhost', port=50000, target_altitude=0.5, targ
    注：这里 v 取“相对地表速度”的标量（surface speed），更贴近你提到的 get_surface_speed。
        若需要更精细，可改成取 surface_velocity 向量的径向分量/或用垂直速度替代。
    """
    try:
        import math
    except Exception:
        math = None
-    if krpc is None:
+        bottom_clearance_margin = 12  # m：按载具尺寸调整（越大越早开始末端减速）
-        raise RuntimeError('krpc 未安装')
+
    参数说明：
      bottom_clearance_margin (float):
        - 单位：米(m)
        - 说明：从雷达（bedrock_altitude）读取的高度中减去该几何余量以近似载具最低点到地面的距离。
          用于避免脚本在实际着陆时因底部结构接触地面而过早判断已着陆。值越大会更早开始末端减速。
        - 典型值：10~25，根据载具底部高度调整。
      thrust_discount_wait (float):
        - 单位：无（比例系数）
        - 说明：在 WAIT 阶段估算可用推力时对 vessel.available_thrust 的折减因子。
          会用 avail_thrust * thrust_discount_wait 来保守估算用于决定何时点火（补偿推力建立/响应延迟）。
        - 取值范围：0.0~1.0；越小越保守（更早点火）。默认 0.85。
      pre_ignite_seconds (float):
        - 单位：秒(s)
        - 说明：在预计点火时刻的倒计时触发点火的提前时间。用于补偿推力建立/响应延迟。
        - 典型值：2.0~3.0，默认 2.5。
      host (str) / port (int):
        - 说明：连接 kRPC 服务的地址和 RPC 端口（用于 krpc.connect）。一般本地运行时用 'localhost' 和 50000。
      target_altitude (float):
        - 单位：米(m)
        - 说明：目标的“触地点高度基准”，脚本在计算剩余高度时会把 radar_alt - bottom_clearance_margin 与此值比较。
          通常设为想要在接触地面时的质心高度（或 0/地面高度上方的偏移）。
        - 典型值：0~5（例如 3 表示目标在底部余量之上 3m 处被视为触地）。
      target_vspeed (float):
        - 单位：m/s（竖直速度，负值表示向下）
        - 说明：期望的着陆竖直速度（向下为负）。脚本会把该值取绝对值作为目标的向下速度（vf_down）。
          在计算刹车距离和 PID/前馈控制里以该目标速度为参考。
        - 典型值：-0.5 ~ -1.5（更接近 0 的值更“柔和”但更难实现）。默认为 -1.0。
      safety_margin (float):
        - 单位：米(m)
        - 说明：在刹车距离上再加的安全余量，用于补偿模型误差（如空气阻力、推力随时间变化等）。
        - 典型值：几米（例如 3~10）。默认 5.
      verbose (bool):
        - 说明：是否打印并记录运行时信息到返回的 status['logs']，用于调试或观察倒计时/燃烧过程。
    返回值：
      返回一个 dict 格式的状态描述，包含 'result' 字段（'failed' / 'landed' / 'touchdown_pending'）和 'logs'（运行时消息列表）。
    """
    conn = krpc.connect(name='auto_land_predictive', address=host, rpc_port=port)
    sc = conn.space_center
@@ -99,30 +164,13 @@ def auto_land_predictive(host='localhost', port=50000, target_altitude=0.5, targ
    status = {'result': 'failed', 'logs': []}
    # WAIT 阶段按折减推力估算刹车距离（提前点火，补偿点火/推力建立延迟）
    thrust_discount_wait = 0.9
    # 低空/接地参数（用于“最后几米慢下来”）
    touchdown_vspeed_tol = 0.6  # m/s：认为“软着陆”的竖直速度容差
    low_altitude_pid_switch = 10.0  # m：低于该高度切换到竖直速度控制
    vspeed_p_gain = 1.2  # 比例增益：越大越积极（建议 0.6~2.0）
    low_altitude_ff_gain = 0.3  # 低空前馈增益：按“需要的减速距离/剩余距离”做额外加速度
-
+    # 由于 surface_altitude 近似是“载具质心高度”，末端会偏乐观。
-    def _get_g(local_vessel):
+    # 用 bedrock_altitude（雷达高度）并减去一个底部几何余量，近似得到“最低点离地高度”。
        try:
            body = local_vessel.orbit.body
            g = float(getattr(body, 'surface_gravity', 9.81))
            if g > 0:
                return g
        except Exception:
            pass
        try:
            g = float(getattr(local_vessel.flight(), 'surface_gravity', 9.81))
            if g > 0:
                return g
        except Exception:
            pass
        return 9.81
    # 使用 body 的 reference_frame 读取 surface speed / vertical_speed（对应 get_surface_speed 思路）
    try:
@@ -140,32 +188,32 @@ def auto_land_predictive(host='localhost', port=50000, target_altitude=0.5, targ
        ap = None
    def _read_state():
-        """从接口读取状态：alt, surface_speed(标量), vertical_speed, mass, available_thrust, g, situation_name"""
+        """从接口读取状态：alt(surface_altitude), radar_alt(bedrock_altitude), surface_speed, vertical_speed, mass, available_thrust, g, situation_name"""
        flight = vessel.flight(surface_frame) if surface_frame is not None else vessel.flight()
        alt = float(getattr(flight, 'surface_altitude', 0.0))
        radar_alt = float(getattr(flight, 'bedrock_altitude', alt))
        srf_speed = float(getattr(flight, 'speed', 0.0))
        v_speed = float(getattr(flight, 'vertical_speed', 0.0))
        mass = float(getattr(vessel, 'mass', 0.0))
        avail_thrust = float(getattr(vessel, 'available_thrust', 0.0))
-        g_local = _get_g(vessel)
+        g_local = get_body_g(vessel)
        try:
        situation_name = str(getattr(getattr(vessel, 'situation', None), 'name', ''))
-        except Exception:
+        return alt, radar_alt, srf_speed, v_speed, mass, avail_thrust, g_local, situation_name
            situation_name = ''
        return alt, srf_speed, v_speed, mass, avail_thrust, g_local, situation_name
    try:
        # 初始确保不点火
        try:
        vessel.control.throttle = 0.0
        except Exception:
            pass
-        # 倒计时/等待点火
+        # 外层循环：允许在燃烧被中止时回退到 WAIT 阶段重新计算
        phase_loop = True
        last_log_t = 0.0
        while phase_loop:
            # 倒计时/等待点火
            while True:
-            alt, srf_speed, v_speed, mass, avail_thrust, g_local, situation_name = _read_state()
+                alt, radar_alt, srf_speed, v_speed, mass, avail_thrust, g_local, situation_name = _read_state()
-            remaining_alt = max(0.0, alt - float(target_altitude))
+                # 用“雷达高度-底部余量”近似最低点离地高度
                alt_eff = max(0.0, float(radar_alt) - float(bottom_clearance_margin))
                remaining_alt = max(0.0, alt_eff - float(target_altitude))
                # v：使用 surface speed（标量）作为“需要刹掉的速度”
                v = max(0.0, float(srf_speed))
@@ -192,36 +240,33 @@ def auto_land_predictive(host='localhost', port=50000, target_altitude=0.5, targ
                if verbose and now - last_log_t > 0.2:
                    last_log_t = now
                    msg = (
-                    f'WAIT alt={alt:.1f} rem={remaining_alt:.1f} '
+                        f'WAIT alt={alt:.1f} radar={radar_alt:.1f} alt_eff={alt_eff:.1f} rem={remaining_alt:.1f} '
                        f'srf_speed={srf_speed:.2f} vs={v_speed:.2f} '
                        f'a_max_up={a_max_up:.2f} braking={braking_dist:.1f} thr_disc={thrust_discount_wait:.2f} '
-                    f'countdown={(countdown if countdown is not None else float("nan")):.2f}'
+                        f'countdown={(countdown if countdown is not None else float("nan")):.2f} pre_ignite={float(pre_ignite_seconds):.2f}'
                    )
                    status['logs'].append(msg)
                    print(msg)
                # 点火条件：进入刹车距离 or 推力未知（inf）但高度很低
-            should_ignite = (remaining_alt <= braking_dist) or (braking_dist == float('inf') and remaining_alt < 200.0)
+                # 额外：若倒计时计算可用，则在 suicide burn 前 pre_ignite_seconds 提前点火
                should_ignite = (
                    (remaining_alt <= braking_dist)
                    or (braking_dist == float('inf') and remaining_alt < 200.0)
                    or (countdown is not None and countdown <= float(pre_ignite_seconds))
                )
                if should_ignite:
                    break
                # 确保仍在滑行
-            try:
+                time.sleep(0.05)
                vessel.control.throttle = 0.0
            except Exception:
                pass
            time.sleep(0.01)
-        # 点火
+            # 进入燃烧闭环：根据 remaining_alt 反推需要的减速度 -> 油门
-        try:
+            break_burn_and_retry = False
            vessel.control.activate_next_stage()
        except Exception:
            pass
        # 燃烧闭环：根据 remaining_alt 反推需要的减速度 -> 油门
            while True:
-            alt, srf_speed, v_speed, mass, avail_thrust, g_local, situation_name = _read_state()
+                alt, radar_alt, srf_speed, v_speed, mass, avail_thrust, g_local, situation_name = _read_state()
-            remaining_alt = max(0.0, alt - float(target_altitude))
+                alt_eff = max(0.0, float(radar_alt) - float(bottom_clearance_margin))
                remaining_alt = max(0.0, alt_eff - float(target_altitude))
                # BURN 阶段以“竖直下降速度”为控制对象：下降为负，统一转成向下为正的标量 v_down
                v_down = max(0.0, -float(v_speed))
@@ -231,34 +276,37 @@ def auto_land_predictive(host='localhost', port=50000, target_altitude=0.5, targ
                # 因此要求：LANDED 且竖直速度足够小才结束
                is_landed = str(situation_name).strip().lower() == 'landed'
                if is_landed and v_down <= (vf_down + float(touchdown_vspeed_tol)):
                try:
                    vessel.control.throttle = 0.0
                except Exception:
                    pass
                    status['result'] = 'landed'
                    status['logs'].append('检测到 vessel.situation=LANDED 且竖直速度满足软着陆阈值，着陆完成')
                    if verbose:
                        print('检测到 vessel.situation=LANDED 且竖直速度满足软着陆阈值，着陆完成')
                    phase_loop = False
                    break
                # 兜底：极低高度 + 速度足够小（防止 situation 迟迟不切换导致卡死）
                if remaining_alt <= max(0.2, float(target_altitude)) and v_down <= (vf_down + float(touchdown_vspeed_tol)):
                try:
                    vessel.control.throttle = 0.0
                except Exception:
                    pass
                    status['result'] = 'touchdown_pending'
                    status['logs'].append('达到高度/速度阈值，但 vessel.situation 仍未变为 LANDED')
                    if verbose:
-                    print('达到高度/速度阈值，但 vessel.situation 仍未变为 LANDED')
+                        print('达到高度/速度阈值，但 vessel.situation 仍未变为 LANED')
                    phase_loop = False
                    break
                # 如果尚未落地但不再下降（v_down<=0），说明燃烧过强导致上升或已停止下落，停止燃烧并回退到等待
                if (not is_landed) and v_down <= 0.0:
                    vessel.control.throttle = 0.0
                    status['logs'].append('BURN aborted: 未落地但竖直速度已<=0，返回等待点火')
                    if verbose:
                        print('BURN aborted: 未落地但竖直速度已<=0，返回等待点火')
                    break_burn_and_retry = True
                    break
                # 低空策略：切换到“竖直速度跟踪”以确保最后几米把速度压到目标值
-            if alt <= float(low_altitude_pid_switch):
+                if alt_eff <= float(low_altitude_pid_switch):
                    # 低空：比例 + 前馈（用当前速度估算“需要多少距离才能刹到目标速度”）
                # a_p：把竖直速度拉向目标
                    a_p = float(vspeed_p_gain) * max(0.0, (v_down - vf_down))
                # a_ff：基于能量/距离的前馈，防止在最后几米才突然补救
                    if remaining_alt <= 1e-3:
                        a_ff = 0.0
                    else:
@@ -280,30 +328,49 @@ def auto_land_predictive(host='localhost', port=50000, target_altitude=0.5, targ
                throttle = max(0.0, min(1.0, float(throttle)))
                # 低空兜底：高度<5m 且仍很快 -> 满油门
-            if alt < 5.0 and v_down > 10.0:
+                if alt_eff < 5.0 and v_down > 10.0:
                    throttle = 1.0
                # 若已经触发 LANDED 但竖直速度仍偏大，避免油门过低导致“硬砸/反弹”
                if is_landed and v_down > (vf_down + float(touchdown_vspeed_tol)):
                    throttle = max(throttle, 0.8)
            try:
                vessel.control.throttle = throttle
-            except Exception:
+                # 异常点获取
-                pass
+                if throttle > 0 and vessel.thrust <= 1e-3 and vessel.control.throttle <= 1e-3:
                    log_msg = '此时应当点火，但实际并未移动节流阀，也未产生推力'
                    print('Reconnected: ', end='')
                    conn.close()
                    conn = krpc.connect(name='auto_land_predictive_retry', address=host, rpc_port=port)
                    sc = conn.space_center
                    vessel = sc.active_vessel
                else:
                    log_msg = ''
                if verbose:
                    msg = (
-                    f'BURN alt={alt:.1f} rem={remaining_alt:.1f} '
+                        f'BURN alt={alt:.1f} radar={radar_alt:.1f} alt_eff={alt_eff:.1f} rem={remaining_alt:.1f} '
                        f'srf_speed={srf_speed:.2f} vs={v_speed:.2f} '
                        f'v_down={v_down:.2f} vf_down={vf_down:.2f} '
                        f'a_req_up={a_req_up:.2f} throttle={throttle:.2f} '
-                    f'landed={int(is_landed)}'
+                        f'landed={int(is_landed)} '
                        f'current_thrust={vessel.thrust:.1f}kN '
                        f"{log_msg}"
                    )
                    status['logs'].append(msg)
                    print(msg)
-            time.sleep(0.01)
+                time.sleep(0.05)
            # BURN loop end
            if break_burn_and_retry:
                # 清理并回退到等待点火状态，继续外层 phase_loop
                vessel.control.throttle = 0.0
                time.sleep(0.05)
                continue
            else:
                # 着陆完成或触地待定，结束 outer loop
                break
    finally:
        try:
@@ -322,6 +389,10 @@ def auto_land_predictive(host='localhost', port=50000, target_altitude=0.5, targ
    return status
 if __name__ == "__main__":
-    xxx = auto_land_predictive()
+    xxx = auto_land_predictive(
        bottom_clearance_margin=0,
        thrust_discount_wait=1.0,
        pre_ignite_seconds=1.5,
    )
    print(xxx)
    print('done')
@@ -0,0 +1,101 @@
 import os
 import time
 from pathlib import Path
 from src.config.load_config import LLM
 PROJECT_PATH = Path(__file__).parent.parent.parent.absolute()
 DATA_PATH = os.path.join(PROJECT_PATH, 'data')
 vehicle_name = 'Enterprise Space Shuttle'
 SYSTEM_PROMPT = '''Your job is to help user writing vehicle introductions in wikipedia style. 
 You need to write an informative introduction that includes the design, features, capabilities and other aspects of the vehicle. 
 The introduction should be written in a neutral tone, without any promotional language or subjective opinions. 
 You should expand the content based on the provided information.
 The content you generated should be in markdown format.
 '''
 user_input = f"""
 Here are some basic information about {vehicle_name}:
 Enterprise Space Shuttle is a fully reusable spacecraft designed for rapid orbital and interplanetary transit. 
 It is co-developed with the Echo Space Shuttle, sharing some design commonality.
 It shares the same delta-wing, same VTVL engines, same arc-reactor, and same top-mounted docking port design.
 It supports both conventional runway takeoffs/landings and vertical rocket-launch profiles (VTVL). 
 The major difference between the two is that the Enterprise Space Shuttle is designed to carry more crew and cargo. The main fuselage of Enterprise is a mk3 design, a near cylindrical 3.75m fuselage.
 The cockpit accommodates 6 crew, while the cabin section has room for up to 16 passengers. The cabin can also be modified to support 6 crew for long-duration missions.
 It is 40m long and 25m wide, with a typical takeoff weight of 50 tons. The VTVL engines can produce a total of 1000KN of thrust, allowing the shuttle to take off vertically from the ground or from a spaceport.
 It's main engine is a nuclear aerospike engine generating 1700KN of thrust, with 4 VTVL engines helping it to take off vertically.
 40 RCS thrusters are used for attitude control.
 A single Arc-reactor provides electrical power to the shuttle.
 The cockpit is located at the front of the shuttle and has 6 seats, 2 for the pilot and 4 for passengers. Though it is capable of fully autonomous flight, it is designed to be piloted by a crew of 2.
 An extendable ladder is located beneath the cockpit hatch, which can be used for ingress and egress from the ground. A corridor hatch is installed on top of the cockpit hatch, which can be used to link to other spacecrafts, stations or bases. The corridor hatch is 1.25m in diameter, and has a pressure seal to maintain the cabin pressure when the shuttle is docked with other spacecraft or space stations. 
 The cabin section is located behind the cockpit, which have 16 seats for passengers. The cabin is pressurized and has life support systems to provide breathable air and temperature control. The 16 passenger seats can be converted to 6 crew seats for long-duration missions. The living area is also located in the cabin section, which has a small kitchen, a bathroom, and a sleeping area for the crew.
 A single 1.875m docking port is located at the top of the cabin section, which can be used to dock with other spacecraft or space stations. The docking port is structurally reinforced, so that the shuttle can dock with a large interplanetary exploration space station and be towed by that station.
 The cargo bay is located behind the cabin section, which can carry up to 25 tons of cargo. An airlock and an extendable 1.25m docking port is located inside the cargo bay, immediately behind the cabin section.
 The cargo bay has an internal dimension of 3.5m in height and 3.1m in width, with a length of 15 meters. The Arc-reactor is located at the rear of the cargo bay, which provides electrical power to the shuttle. The Arc-reactor is a compact fusion reactor.
 After the cargo bay is the aft-service module, which contains fuel, life support systems, and other systems necessary for the shuttle's operation. 
 The main wing is almost identical to the Echo Space Shuttle, employing a delta-wing design to ease the thermal load during atmospheric reentry. The control surfaces are enlarged to provide better control authority during atmospheric flight. At the tip of each of the main wings, a small vertical stabilizer is installed, which can be used to control the shuttle's yaw attitude during atmospheric flight. The tip-mounted rudder design is to provide additional yaw stability during reentry.
 """.format(vehicle_name=vehicle_name)
 message_list = [
    {'role': 'system', 'content': SYSTEM_PROMPT},
    {'role': 'user', 'content': user_input},
    {'role': 'user', 'content': """Here is some information about Echo Shuttle to help you write the introduction: 
 Echo Space Shuttle
 The Echo Space Shuttle is a fully reusable spacecraft engineered for rapid orbital and interplanetary transit. Designed for operational versatility, it supports both conventional runway takeoffs/landings and vertical rocket-launch profiles (VTVL). With a length of 31.7 meters, wingspan of 22.9 meters, and typical takeoff mass of 45 metric tons, it employs a mk2 lifting-body airframe featuring a rhomboidal cross-section (5m width × 3m height at center, tapering to 0.5m height at edges).
 Propulsion and Performance
    • Primary thrust: Two nuclear aerospike engines generating 1,400 kN combined thrust.
    • Vertical launch capability: Four VTVL engines (1,000 kN total) enable terrestrial or extraterrestrial vertical ascents.
    • Attitude control: 24 reaction control system (RCS) thrusters.
    • Power system: A compact fusion Arc-reactor supplies electrical energy.
    • Delta-v capacity: 70 km/s (unladen) or 50 km/s with 15-ton payload, supporting lunar surface round-trips. Fuel is stored in wing tanks, refillable terrestrially or in orbit.
 Crew and Habitation
 The cockpit accommodates three personnel (pilot + two passengers) with full autonomous flight capability. Behind it lies a pressurized cabin with:
    • Four additional passenger seats
    • Life support for seven crew members (60-day baseline, extendable via cargo supplements)
    • Living quarters including kitchen, bathroom, and sleeping area
    • Two access points: extendable ladder under cockpit hatch and 1.25m-diameter pressure-sealed corridor hatch for spacecraft docking
 Cargo and Modularity
 A 15-meter rear cargo bay (2.5m height × 4m width, rhomboid cross-section) holds 15 tons of payload. Configurations include:
    • Housing for cylindrical payloads (2.5m diameter + two 1m-diameter units)
    • Optional 2.5m-diameter cabin extension for additional passengers
    • Structurally reinforced 1.875m top-mounted docking port for station coupling and interplanetary towing
 Flight Systems
    • Landing gear: Reinforced for runway operations and vertical touchdowns on uneven terrain (e.g., lunar/Martian surfaces).
    • Aerodynamics: Delta-wing main airframe with tip-mounted vertical stabilizers for reentry thermal management. Canards provide pitch control and supplemental lift, while triple rear control surfaces (roll/pitch/flaps) optimize atmospheric flight.
    • Reentry constraint: Heat shield limited to low-Earth orbit reentries; high-orbit returns require engine-assisted deceleration.
 Mission Profiles
 Primarily deployed in the Earth-Moon system for:
    • Crew/cargo transport to lunar surface or low-Earth orbit stations
    • Scientific research operations
 Integration with interplanetary stations (e.g., Stellaria/Kuafu classes) for deep-space expeditions, functioning as a crew ferry and planetary descent vehicle during extended missions.
 """}
 ]
 start = time.time()
 stream = LLM.stream(message_list)
 total_content = ''
 flag = True
 for chunk in stream:
    if flag:
        print('首token时间：', time.time()-start)
        flag = False
    print(chunk.content, end='')
    total_content += chunk.content
 print('')
 print('总时间:', time.time()-start)
 vehicle_md_path = os.path.join(DATA_PATH,'vehicle_descriptions',  f'{vehicle_name}.md')
 with open(vehicle_md_path, 'w', encoding='utf-8') as f:
    f.write(total_content)
 print('')
 print('总时间:', time.time()-start)
@@ -2,12 +2,11 @@
 from langchain_ollama import ChatOllama
-LLM = ChatOllama(model='qwen2.5:14b', api_key="1145141919810", base_url='http://192.168.195.158:11434')
+LLM = ChatOllama(model='qwen2.5:14b', base_url='insert base url here')
 # LLM = ChatOpenAI(model="gpt-4o", openai_api_key='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')
-tavily_key = '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'
+tavily_key = ''
-gaode_key = '00fd082df2414f75c6efb64896819451'
+gaode_key = ''
 #
 #
@@ -0,0 +1,10 @@
 from langchain_ollama import ChatOllama
 LLM = ChatOllama(model='qwen2.5:14b', api_key="1145141919810", base_url='http://192.168.195.158:11434')
 # LLM = ChatOpenAI(model="gpt-4o", openai_api_key='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')
 tavily_key = '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'
 gaode_key = '00fd082df2414f75c6efb64896819451'
@@ -0,0 +1,25 @@
 import requests
 import bs4
 import time
 start_url = 'https://www.rouwenwu.in/book/239/14393.html'
 total_content = ''
 while True:
    resp = requests.get(start_url)
    resp.encoding = 'ansi'
    soup = bs4.BeautifulSoup(resp.content, features='lxml')
    title = soup.select_one('#content > div.page-header.text-center > h1').text
    content = soup.select_one('#htmlContent').text.replace('\xa0\xa0\xa0\xa0', '\n')
    total_content += title + '\n' + content + '\n'
    print(title, 'completed')
    time.sleep(1)
    next_href = soup.select_one('#linkNext')['href']
    if 'html' not in next_href:
        break
    start_url = 'https://www.rouwenwu.in/book/239/' + next_href
 with open('AV拍摄指南.txt', 'w', encoding='utf-8') as f:
    f.write(total_content)
Author	SHA1	Message	Date
Armor	80719b84d6	update	2026-02-23 19:24:38 +08:00
zhouyr9	ecd7ebd23c	update	2026-01-22 20:42:07 +08:00
zhouyr9	54fb811960	update	2026-01-22 20:41:54 +08:00
zhouyr9	f77d260121	update	2026-01-20 11:47:49 +08:00
Armor	3c9740744f	update	2026-01-19 15:56:14 +08:00
Armor	6560eeaa0b	update	2026-01-17 21:59:04 +08:00
zhouyr9	c81fc697d2	update	2026-01-16 16:09:51 +08:00
Armor	ec4c06ea8c	update	2026-01-15 21:57:21 +08:00
zhouyr9	085b2032af	update	2026-01-15 10:26:20 +08:00
Armor	fe2ebd6a70	update	2026-01-15 00:13:31 +08:00