MRRC 问题答复 · 解决办法

这条答复是怎么来的？

1. 你在 App 里点 🐞 遇到问题 生成诊断包（日志尾部 + 脱敏配置 + 环境快照 + 自动体检摘要）， 用户数据库、证书、密钥永不打包；
2. 上传后得到编号，维护者侧收到（只有维护者能看）；
3. 维护者的自动分诊流程会取出诊断包、生成摘要，交给 AI 按固定的判定纪律分析 （材料不足就写"需要补充信息"，绝不下没有证据的结论）；
4. 结论渲染成上面的一张卡片并发布到本页 —— 你按编号就能看到，多数问题照着"你要做的"就能解决；
5. 如果确认是软件缺陷：先给你临时规避，再修代码；能走热修的就热修 （你重启 MRRC 即生效，无需重装），否则随新版本发布，卡片会标成"已修复 · 版本号"。

隐私：诊断包只在你主动点击上传时才发送；本页只放可公开的结论，不含任何用户数据。

上报时间 2026-09-17T13:26:35 · 描述：wDSP启用后流水声太大，声音失真/降噪后，如何解决？

上报版本 6.1.16 · 包体积 143 KB

结论

WDSP NR2 降噪强度偏高产生的水音/失真，属调参问题，非缺陷

诊断

• 用户现象「流水声太大、声音失真」与 WDSP 手册记载的 NR2 谱减法『音乐噪音/水珠杂音』完全吻合，是降噪副作用而非故障
• 配置中 nr2_level = 2（对应每 bin 最大衰减 -12dB、psi=12.0、zeta=0.65），中等偏强，噪声环境下安静段易出水音
• 音频健康 99.9%、单次读取最大 28.3ms，采集链路正常，排除缓冲/性能问题
• 无服务端日志、无 Traceback，非崩溃类问题
• [RNNOISE] 节无 enabled 键（默认关闭），降噪只走 WDSP NR2 一条链，可排除双降噪叠加

你要做的

1. 打开 wdsp_settings.html（或移动端 设置→WDSP 数字处理），把 NR2 降噪级别从 2 降到 1，水音会明显减少
2. 若想彻底对比，先把 NR2 设为 0（或暂时关 WDSP）确认流水声确实来自降噪而非链路本身
3. 若降 1 级后仍失真，把 AGC 模式由 MED 改为 SLOW 或 OFF 测试是否为增益削波
4. 收窄带通至 350–2600Hz，减少带外噪声参与谱减法
5. 仍不满意时把 nr2_ae_psi 调大到 14–18、nr2_ae_zeta_thresh 调小到 0.6，进一步压制音乐噪声
6. 调完后重启 MRRC 生效并实际收听验证；把满意的一组参数记下备用

证据（原始行）

• 问题描述：wDSP启用后流水声太大，声音失真/降噪后
• [WDSP] nr2_level = 2
• [WDSP] nr2_ae_psi = 12.0 / nr2_ae_zeta_thresh = 0.65
• 🎧 音频健康: 30s 采集 1440000 样本（应有 1441062，99.9%）
• [WDSP] agc_mode = 3 / bandpass_low = 300.0 / bandpass_high = 2700.0

上报时间 2026-09-17T08:53:09 · 描述：FT-891连接不上，但是电台的音频能同步。

上报版本 6.1.13 · 包体积 10 KB

结论

FT-891连不上是rigctld未启动，需手动启动rigctld.exe（环境问题）

诊断

• 3次ERROR『rigctld daemon not running: timed out』（08:40:14/08:41:15/08:51:38），电台CAT后台没起来，FT-891因此连不上。
• 配置两套键一致且正确：rig_model=FT-891、instance_rigctl_model=1036、rig_pathname=COM8、rig_rate=38400，问题不在机型配置。
• Windows安装版不会自动拉起rigctld.exe，需用户手动启动（与此前073700-14ef同因，属重复现象）。
• 音频走声卡、与CAT控制是两条独立通道：日志尾部采集100.0%、Opus编码正常，与『音频能同步』一致。
• 无Traceback、6次启动无崩溃痕迹，属正常升级/重启，不是软件故障。
• 音频最低健康度89.4%（略低于99%），为次要性能点，非本次连接问题主因。

你要做的

1. 以管理员身份打开PowerShell启动rigctld：rigctld.exe -m 1036 -r COM8 -s 38400 -T 127.0.0.1 -t 4532（串口/速率按设备管理器与FT-891的CAT菜单核实）。
2. 确认FT-891已开机、CAT串口线接到COM8，且电台CAT菜单速率=38400、数据位=8、停止位/校验与上面命令一致。
3. 验证rigctld已监听：运行 Test-NetConnection 127.0.0.1 -Port 4532 应成功；再重启MRRC，日志出现『✓ rigctld daemon responding!』即连接成功。
4. 确认COM8未被JTDX/WSJT-X/电台原厂等CAT软件占用，占用时rigctld会打不开串口。
5. 若音频仍有偶发卡顿（健康度89.4%），检查CPU占用、关掉WDSP高负载项或将采集设备换用低延迟WASAPI通道。

证据（原始行）

• ERROR - ⚠ rigctld daemon not running: timed out（08:40:14、08:41:15、08:51:38）
• rig_model = FT-891 / rig_pathname = COM8 / rig_rate = 38400 / instance_rigctl_model = 1036
• 音频健康: 30s 采集 1440960 样本（应有 1440944，100.0%）
• 自动体检结论：音频采集最低健康度 89.4%
• 启动次数：6 次，时间跨度 06:42:28 → 08:51:40 —— 无崩溃痕迹
• platform: Windows-10-10.0.19041-SP0

上报时间 2026-09-17T07:36:29 · 描述：FT-891还是无法连接上，音频同步正常，S表偏大过电台机显，大概差1到1.5个S。

上报版本 6.1.12 · 包体积 8 KB

结论

FT-891连不上是rigctld未启动，先手动启动rigctld.exe再复查S表

诊断

• 两次启动均报『rigctld daemon not running: timed out』（06:42:28、07:31:16），MRRC 没连上电台后台，FT-891 因此无法连接。
• 配置已指向 FT-891（rig_model=1036、rig_pathname=COM8、rig_rate=38400），但 Windows 安装版不会自动拉起 rigctld.exe，需手动启动。
• S 表读数来自 rigctld 的 l STRENGTH 命令（前端 getSignalLevel），rigctld 未连接时 S 表不可靠，偏大 1–1.5 S 应在连接成功后实测复查。
• 音频通道正常：日志尾部『30s 采集 1440960 样本（100.0%）』、Opus 编码正常，与『音频同步正常』一致，问题只在 CAT/电台控制侧。
• 体检显示启动 2 次、无 Traceback/崩溃痕迹，属正常重启而非软件故障。

你要做的

1. 以管理员身份打开 PowerShell，启动 rigctld：rigctld.exe -m 1036 -r COM8 -s 38400 -T 127.0.0.1 -t 4532（串口/速率按设备管理器与电台 CAT 菜单核实）。
2. 确认 FT-891 已开机、CAT 串口线接到 COM8，且 CAT 菜单速率=38400、数据位=8、停止位/校验与上面命令一致。
3. 确认 rigctld 已监听：运行 Test-NetConnection 127.0.0.1 -Port 4532 应成功；再重启 MRRC，日志出现『✓ rigctld daemon responding!』即连接成功。
4. 检查 COM8 未被其他 CAT 软件（如 FT8/JTDX、电台原厂软件）占用，占用时 rigctld 打不开串口。
5. 连接成功后，在同一信号下对比 MRRC 与电台机显的 S 值；若仍偏 1–1.5 S，请再次🐞上报并写明『电台显示 S几 / MRRC 显示 S几』及对应频率。

证据（原始行）

• ERROR - ⚠ rigctld daemon not running: timed out（06:42:28 与 07:31:16 各一次）
• rig_model = 1036 / rig_pathname = COM8 / rig_rate = 38400（脱敏配置）
• 音频健康: 30s 采集 1440960 样本（应有 1440925，100.0%）
• 启动次数：2 次，时间跨度 2026-09-17 06:42:28 → 07:33:17 —— 无崩溃痕迹
• platform: Windows-10-10.0.19041-SP0

上报时间 2026-09-16T22:52:04 · 描述：lll-testing

上报版本 6.1.12 · 包体积 9 KB

结论

本机无声卡且 rigctld 未启动（虚拟机常见），属环境预期而非缺陷

诊断

• env.json 中 audio.devices 为空数组，日志反复报 -9996 Invalid input device（no default output device），说明本机无可用音频设备（虚拟机常见），应用已自动降级为纯 Web 模式
• 配置里 inputdevice/outputdevice=USB Audio，但日志显示 Device 'USB Audio' not found，设备名与实测不符
• rigctld daemon not running: timed out 导致进入 simulation mode，电台命令均为模拟（未启动 rigctld 或未接电台）
• 29 次启动、无任何 Traceback/Fatal，多为升级/手动重启，无崩溃痕迹
• SSL Error SSLV3_ALERT_CERTIFICATE_UNKNOWN 为自签名证书的正常噪声，可忽略；ATR-1000 未启用为 auto 缺省行为

你要做的

1. 若要音频：给本机接入真实声卡/USB Audio CODEC（虚拟机需在宿主设置里直通声卡），然后重启 MRRC
2. 若要控制电台：启动 rigctld，并接好 FT-991（COM1），确认端口与速率（38400）
3. 在 Device Config 里把 [AUDIO] inputdevice/outputdevice 改成实际设备名，或留空以使用系统默认设备
4. 自签名证书告警可忽略：浏览器提示不安全时点“继续/信任”即可访问 https://127.0.0.1:8877/mobile
5. 若本次只是测试上传（描述为 lll-testing）：无音频+模拟电台+纯 Web 即当前预期，无需处理

证据（原始行）

• env.json: "audio":{"devices":[],...}
• ❌ 音频初始化失败: [Errno -9996] Invalid input device (no default output device)
• Device 'USB Audio' not found, using default input device
• ERROR - ⚠ rigctld daemon not running: timed out
• Running in simulation mode - radio commands will be simulated

上报时间 2026-09-16T08:13:02 · 描述：aaa

上报版本 6.0.10 · 包体积 5 KB

结论

本机无声卡且 rigctld 未启动，属环境问题，非软件故障

诊断

• 本机没有任何音频设备（env.json 里 audio.devices 为空数组），Windows 报 -9996（找不到可用设备）
• 配置里指定了 inputdevice/outputdevice = USB Audio，但该设备不存在（Device 'USB Audio' not found）
• rigctld 未运行（timed out），MRRC 退入 simulation mode，电台命令为模拟
• 无任何 Traceback/Fatal，1 次启动时间跨度仅 2 秒，无崩溃痕迹，多为升级/手动重启
• SSL 证书告警、ATR-1000 未启用、TX 音频分析器禁用均属正常噪声/预期，不是问题

你要做的

1. 先明确需求：只试用界面时，纯 Web 模式 + simulation mode 属预期，可直接浏览器打开使用
2. 若要用真电台：把 FT-991 用 USB/COM1 线接好并装驱动，然后启动 rigctld（或通过设备配置自动启动）
3. 若要用真音频：插入 USB 声卡/音频设备，并在 Windows 声音设置里确认系统能识别到该设备
4. 若在虚拟机里：需在虚拟机设置中直通/添加音频设备和串口，否则只能纯 Web 模式
5. 在 Device Config 里把 inputdevice/outputdevice 改成实际存在的设备名，或留空使用系统默认设备
6. 如后续仍异常，请补充：是否接电台、是否接声卡、期望实现什么功能（现在描述只有“aaa”）

证据（原始行）

• "audio": { "devices": [] }
• ❌ 音频初始化失败: [Errno -9996] Invalid input device (no default output device)
• Device 'USB Audio' not found, using default input device
• 2026-09-16 08:12:32,291 - MRRC - ERROR - ⚠ rigctld daemon not running: timed out
• Running in simulation mode - radio commands will be simulated

影响版本：6.1.12（安装包与热修都带过这个错误）· 修复版本：6.1.13

症状

打开「🐞 遇到问题」后，点【生成诊断包】【上传给维护者】【只保存到本地】都没有任何反应 （页面看起来正常，但按钮不工作）。

原因

6.1.12 在页面上拼接"答复页链接"时多写了一个引号，导致页面里唯一的脚本语法出错， 整个页面的脚本失效——所以所有按钮都点不动。这是我们的失误，与你的环境无关。

你要做的

1. 关掉 MRRC（那个黑色启动器窗口）再重新打开 —— 启动时会自动拉取热修 6.1.13， 页面即恢复正常（日志里会出现 🧩 补丁覆盖层已启用）；
2. 或者直接安装 MRRC-Setup.exe （6.1.13 或更新）覆盖安装一次；
3. 恢复正常后，如果问题依旧，再用「🐞 遇到问题」生成并上传诊断包即可。

我们怎么防止再犯

已加入自动检查：每次改动都会对 www/ 与站点所有页面的内联脚本 逐段做语法校验（node --check），这类"整页按钮失效"的错误不会再进仓库。

上报时间 2026-09-16T18:49:55 · 描述：目前还可以，你看下日志有咩有异常和潜在风险

上报版本 ? · 包体积 ?

结论

本次未采集到服务端日志，无法排查异常；体检快照各项正常。

诊断

• 自动体检摘要与「服务端日志末尾40行」均为空，用户要求看日志异常，但包内无日志可查。
• 环境快照正常：rigctld IC-M710 状态 Stable（127.0.0.1:4531），与配置 instance_rigctl_port=4531 一致。
• 音频设备齐全（5个，含 USB Audio CODEC 输入/输出、BlackHole 2ch），无 -9996 无效设备报错。
• version 为空、frozen=false、cwd 指向仓库源码目录，属源码方式运行（非安装版），无升级/安装版日志属正常。
• ATR-1000 已启用（auto，设备 192.168.1.63），SERVER 端口 8891 为自定义端口，均非异常。

你要做的

1. 确认本次上报是从实际运行 MRRC 的那台机器发起，并保证 MRRC 正在运行、已产生日志。
2. 重新生成诊断包，或直接把 MRRC 运行日志（stdout/stderr 或 logs/ 目录关键片段）发上来。
3. 在描述里补充具体担心点（如音频卡顿、TX 无声、断连、CPU 高、面板不更新等），便于针对性排查。
4. 日常自检：启动日志应有「IOLoop watchdog armed」标记；TX 时应有「TX audio init」标记。
5. 确认访问地址端口与配置 8891 一致（MRRC 默认端口为 8877）。

证据（原始行）

• 自动体检摘要（工具生成，可信）：（无服务端日志）
• # 服务端日志末尾 40 行：（无）
• "rigctld": {"id": 30003, "name": "IC-M710", "status": "Stable", "host": "127.0.0.1", "port": 4531}
• "version": "", "frozen": false, "cwd": "/Users/cheenle/HAM/mrrc"
• "atr1000": {"enabled": true, "reason": "auto（已配置设备 192.168.1.63）"}

上报时间 2026-09-16 22:22（UTC） · 描述：always stopped abnormally（应用似乎总是异常停止）

环境：Windows 11 · MRRC 6.1.11 安装版 · 2 核 · 无任何音频设备 · 未运行 rigctld

诊断（全部来自你的诊断包）

• 崩溃痕迹（Traceback / Fatal / Exception）：0 条；
• 日志里共 25 次启动，全部正常完成（每次都以 HTTP server started + 看门狗武装结束）；
• 唯一的报错只有两类，都是这台机器的环境：❌ 音频初始化失败 [Errno -9996]（本机没有音频设备）与 ⚠ rigctld daemon not running（没接电台）；
• 日志里有 11 次「收到升级请求：6.1.9（当前 6.1.8）」和 1 次「收到升级请求：6.1.11（当前 6.1.9）」；
• 包内 env.json 显示 version: 6.1.11、audio.devices: []。

结论

不是异常停止，也没有崩溃。看到的"停止"来自两件事：

1. 一键升级的正常行为：点【立即升级】后应用会主动退出 → 静默安装 → 自动重启 （约 10–40 秒）。窗口消失是过程的一部分；
2. 维护者当时正在这台机器上排查升级问题，反复重启过若干次（日志里那 25 次启动的大多数来自这里）。

另外：这台机器没有任何声卡、也没接电台，所以会以「纯 Web 模式」运行（无音频采集、电台命令为模拟）—— 这是预期行为，不是故障。

你要做的

1. 升级时看到窗口消失：等 10–40 秒，新版会自己回来；期间不要手动重复点；
2. 想知道到底重启了几次、是不是崩溃：看诊断包 diagnostics/summary.txt 的 「启动次数 / 日志时间跨度」与有没有 Traceback；
3. 要定位真实的使用问题（音频/发射/仪表），请从接电台那台机器上报一次—— 那台机器的诊断包会带音频设备表和音频健康行，才看得出原因；
4. 本机已验证升级成功：env.json 的版本已是 6.1.11。

Report 20260917-062314-35dc — "always stopped abnormally". Diagnosis from the bundle: zero crash markers; 25 startups, all completed normally; the only errors are environmental (no audio device at all → -9996, and no rigctld running). The "stops" were the expected behaviour of the one-click upgrade (the app exits, installs silently and restarts itself in 10–40 s) plus maintainer test restarts.

What to do: wait 10–40 s after starting an upgrade (don't click again); check diagnostics/summary.txt (startup count / time span / any Traceback) to tell "restarts" from "crashes"; report from the machine that actually has the radio connected when you need a real audio/TX diagnosis. This machine is now on 6.1.11.