🐞 问题答复

Windows 上接入云端报 certificate has expired（浏览器却打得开门户）

不是门户、也不是网络：这台机器的证书库里有一份与被服务链条同名同密钥、却已过期的证书，应用（Python/OpenSSL）只认本机证书库，于是把库里那张放进链里判它过期；浏览器用自己那套根与链构建，所以同一台机器、同一条链，浏览器照常能开

诊断

• 报错原文形如 certificate verify failed: certificate has expired (_ssl.c:1000)。这句话本身就说明 DNS/TCP/握手都通了 —— 是应用拿到证书之后自己拒绝的，不是门户没应答；门户侧同时刻实测证书链完整、有效期到 2026-12-29，且日志里没有来自该实例的任何请求。
• 行号 _ssl.c:1000 是 Python 版本指纹：3.11=1016（盒子）、3.12=1000（Windows 安装包）、3.13=1032（macOS 安装包）—— 据此可确认失败的是 Windows 安装版。
• 机制：Windows 会把见过的中间证书缓存进本机 CA 存储（Let's Encrypt 的中间证书会换代重签，缓存那份到期后正是这个形态）。OpenSSL 会把库里那份过期证书放进链里并判 expired，而且不会回退到服务器送来的那张有效证书（2026-10-16 在构建 VM 上用同一份 openssl 逐条复现）。
• 浏览器（Chrome/Edge）用自己那套根与链构建，不吃本机 CA 缓存，所以表现为「浏览器能上、应用不能」。
• 应用这一层属产品缺陷：net_tls.py 只在本机库为空时才启用随包 CA，也就是把「库非空」当成了「库可用」；**已修** —— 现在只信随包的根证书，不再采信本机证书库（随下一个版本到达用户）。

你要做的

• 下载证书体检工具并**整个解压**后双击运行（默认只读体检，不改任何东西）：https://www.vlsc.net/mrrc_modern/downloads/MRRC-CertDoctor.zip
• 它会用本机证书库对「门户下发的那条链」复现应用的判定，指出是哪一张证书、在哪个库里；确认后运行 MRRC-CertDoctor.cmd -Fix：把能证明是它的过期证书备份后删掉，必要时再问你是否导入当前的两张 Let's Encrypt 根证书。
• 修好后：从托盘退出 MRRC Modern，再启动它，然后 ☰ -> 接入云端 (Cloud Hub) -> 呼号 + 运维给的一次性口令 -> 申请入口/接入。
• 工具修不好时：桌面会留下 MRRC-CertDoctor-<时间>.zip，把它发给我们。注意诊断包上传与软件更新检查走的是同一条 HTTPS 路径，会一起坏 —— 属同一个原因。

相关代码：net_tls.py（不要把自己的信任判定外包给本机证书库）+ tools/windows/MRRC-CertDoctor.ps1（用户侧体检与修复）

接入云端报 CERTIFICATE_VERIFY_FAILED（诊断包也上传不了、软件更新检查失败）

macOS 打包版（v1.25.0 及更早）没有可用的 CA 信任库：应用里所有外发 HTTPS 都无法校验

诊断

• 报错形如 certificate verify failed: unable to get local issuer certificate (_ssl.c:1032)，这不是 portal 或网络的问题——同一台机器上 curl 访问 portal 是 200、证书链完整
• 根因：安装包把构建机的 OpenSSL 一起带走了，它的默认 CA 路径是构建机的 /opt/local/...（MacPorts），用户机上没有这个目录，于是信任库为空；空信任库同样导致诊断包上传失败
• Windows 与源码运行不受影响（Windows 用系统证书库）—— 前提是那套库健全；反过来，库里有过期/陈旧证书时 Windows 也会失败，见上面 2026-10-16 那一条

你要做的

• 升级到 v1.25.1 即不再发生（随包 CA + 显式信任库；构建闸门会故意把信任库打空再要求真握手）
• 还在旧版本上：在配置文件里加一行 SSL_CERT_FILE=/etc/ssl/cert.pem，然后重启 MRRC Modern
• macOS 配置文件位置：~/Library/Application Support/MRRC-Modern/mrrc_modern.env
• 重启后：接入云端、诊断包上传、软件更新检查应同时恢复

相关代码：net_tls.py（信任库）+ packaging/*/build.*（随包 vendor/ca/cacert.pem）

频谱显示不对：一直是一条光滑的假曲线，看不到真实信号

macOS 打包版 v1.25.0（及 v1.18.0 起的同类构建）真频谱从未启动，界面画的是 S 表合成曲线

诊断

• 日志特征：反复 scope_pipe exited (frames=0, connected=False) 与 Spectrum broadcast active: S-meter fallback；真频谱成功时应有 scope_pipe: first frame received — spectrum active
• 硬件、驱动、库都没问题（FT4222 在 USB 总线上、两个 dylib 在包内，手工用正确目录运行立刻出帧）
• 根因：应用配置里的 FTDI 库目录是相对路径 vendor/ftdi/macos，启动器把它锚到了 Contents/MacOS/（那里什么都没有），而数据树在 Contents/Resources/ —— 于是 scope_pipe 报 FTDI libraries not found 并退出

你要做的

• 升级到 v1.25.1 即不再发生（启动器改为经 _internal 解析相对路径，并补了签名包目录结构的回归测试）
• 还在旧版本上：把配置里的 MRRC_FTDI_LIB_DIR 改成绝对路径 /Applications/MRRC-Modern.app/Contents/Resources/vendor/ftdi/macos，然后重启应用
• 重启后刷新页面：频谱应变成真实底噪 + 信号（可在日志确认 first frame received — spectrum active）

相关代码：macos/launcher.py:load_env（相对 FTDI 目录经 runtime_path 解析）

电脑没有接收到电台的声音。还有瀑布图很卡，电台的网口是传输基带IQ信号的。现在电台我接入到网络里了。电台的IP地址是192.168.110.199 电台用户名是

G7250 已连上 CAT，但网口 IQ 未启用（未设 MRRC_G7250_LAN_IP，瀑布只能走 S 表合成）；同时 RX 音频被配成了电脑自带的「主声音捕获驱动程序 / 立体声混音」，而不是电台内置 USB 声卡，因此听不到电台声音。

诊断

• 频谱是合成的，不是真频谱：stdout.log 12:59:47 明确写着 `Xiegu G7250: no CI-V scope — set MRRC_G7250_LAN_IP to use the radio's LAN IQ stream for the waterfall`，env.json 里也是 `"scope_type": "none"`。这正是「瀑布很卡/一条光滑曲线」的原因——G7250 没有 CI-V 0x27，真频谱只能来自网口 IQ（收 UDP 50001，往电台 50002 发 14 字节调谐帧）；CHANGELOG v1.28.37 · FP33/v1.28.39 与 docs/G7250_USER_GUIDE.md §3 描述完全一致，且当前版本 1.28.39 已包含该功能，所以不是缺功能，是没配。
• RX 音频选错了设备：summary.txt 里 `Configured audio device '主声音捕获驱动程序' not found`、`Configured audio device '立体声混音 (Realtek HD Audio Stereo input)' not found`，随后 `RX open failed ([Errno -9999] Unanticipated host error) — re-initializing PortAudio`（13 次）。env.json 的 rx 列表里 0/8/27 号都是电脑自带声卡的虚拟/混音输入，而电台声音在 `麦克风 (USB Audio Device)`（索引 1/9/21/23）。G7250 的音频走机头 USB 线的内置 USB 声卡（docs/G7250_USER_GUIDE.md 第 1 节：`USB 线 … ICOM CI-V（CAT）+ 内置 USB 声卡 → 收发音频`），选 Realtek 的混音/主捕获只会录到电脑本地声音，且这类设备在 -9999 之后很可能一直打不开。
• 旁证「一个字节都没进来」：server.log 2026-11-11 里 RX tap 一直是 `rms=2 peak=8/9/10`（几乎静音），说明送进解码器的那路音频里根本没有电台信号，与「设备选错 / 电台没把音频送到 USB 声卡」一致，而不是解码器的问题。
• 顺带发现一个与主诉无关但存在的事实：FT8 DSP worker 在反复崩溃（`WorkerFault: worker_exit: worker process exited with status None (generation 17, restarts 16)`，ft8-worker.log 尾部是 EOFError/BrokenPipeError），本版已带大栈线程修复（ft8/core/worker.py `_run_with_large_stack`）却仍在退，属另一条待查线索；先按本节修音频，再看它是否随音频恢复而停止。
• 版本/历史核对：CHANGELOG.md 第 320‑330 行（[镜像线 v1.28.37 · FP33]）与 v1.28.39 桌面重建条目都写明「配 MRRC_G7250_LAN_IP 后瀑布来自这条流，不配就退回 S 表合成瀑布」；用户装的是 1.28.39，不需要升级，属于配置未落地，不是回归。
• 发射仍被门禁拦住（env.json `tx_gated: true`，stdout.log 12:59:47 `Radio model g7250 is NOT hardware-verified — transmit is DISABLED`）——只影响发射，不影响「听不到声音」，但用户后面要发射时必须处理。
• 连接设置页面里没有 MRRC_G7250_LAN_IP 输入项（`static/index.html:653` 只有机型选项，config.py:371 才读这个变量），所以这一项只能写进环境变量/配置文件——这是本次卡住的直接原因，也解释了「我已经把电台接入网络了」却没生效。

你要做的

• 打开 ☰ →「连接设置」，把 **RX 音频设备** 和 **TX 音频设备** 都改选为电台那个 USB 声卡条目：`麦克风 (USB Audio Device)`（发送到电台的应是 `扬声器 (USB Audio Device)`），**不要**选 `主声音捕获驱动程序`、`主声音驱动程序`、`立体声混音 (Realtek HD Audio Stereo input)`、Realtek/NVIDIA 的任何条目；保存后服务会自动重启，日志里应出现 `RX audio started: [1] 麦克风 (USB Audio Device) …`。
• 确认电台机头 USB 线插的是机头上那个 USB 通信口（不是主机后面的口），Windows 设备管理器里应同时出现一个串口和一个 USB 音频设备；如果只有串口没有声卡，先把 USB 线换口/换线。
• 开启真频谱：在 Windows 系统环境变量里新增 `MRRC_G7250_LAN_IP=[已隐去]`（或写进 MRRC Modern 读取的配置/env 文件），完全退出 MRRC Modern 再启动。启动日志里必须看到 `G7250 LAN IQ listening on UDP 50001 (radio [已隐去]:50002), +/-24.0 kHz`。
• 放行防火墙：Windows 防火墙允许**入站 UDP 50001**（IQ 是电台主动推给电脑的，这一步不能省）；出站 UDP 50002 由电脑发给电台。端口 50003 本程序不用，别管它。
• 关掉任何正在占用这些端口的软件（典型是协谷官方接法里的 HDSDR）：日志若出现 `G7250 LAN IQ: cannot bind UDP 50001` 就是这个原因；一个 UDP 端口只能有一个主人，所以也别同时开 HDSDR 和本程序看频谱。
• 配好后自检三点：① 瀑布变成真实的宽带噪声/信号峰，而不是一条平滑曲线；② 拖动频率时瀑布中心跟着走（只有 ±24 kHz，这是正常的）；③ 如果信号出现在中心线错误的一侧，再在环境变量里加 `MRRC_G7250_SWAP_IQ=1` 并重启。
• 若之后要发射：G7250 目前是实验机型，发射默认关闭，需要在环境变量里设 `MRRC_ALLOW_UNVERIFIED_TX=1`（本版本 1.28.39 对 G7250 不放开出厂门禁），未确认前请仍以接收为主。
• 验证成功后仍无声音时再回报：网页右上音量、浏览器标签是否静音、以及新的诊断包（这次要包含 21:2x 之后那段含 `RX audio started` 的日志），才能区分「设备选对但电台没送音频」和「软件侧打不开设备」。

相关代码：config.py:371 (G7250_LAN_IP) / backends/xiegu/lan_iq.py (LAN IQ producer) / audio_handler.py:_reinit_pyaudio、audio_handler.py:390

电台蓝牙遥控器配成功后，按下PPT（语音键）电台发动作，遥控器语音，话咪均无法输入音频，按要求升级后换小米遥控器，能搜索到小米遥控器，无法配对，于是，又用原来的

语音键发射时没有声音，是因为当前这支「移动语音遥控器」没有麦克风通路（遥控器麦克风只对小米蓝牙遥控器 2 / 2 Pro 的 ATVV 做了支持）；随后的配不上/搜到旧设备，是 bluez 里残留的旧绑定和缓存回声——用设置页「重配」+ 必要时「重启蓝牙」即可自愈，不需要改代码。

诊断

• 遥控器按键本身是好的，问题只在音频源：日志 22:24:18 有 `Audio TX client connected (1 total, owner=True)`（对端已持有发射键），随后只有 `Audio loop idle: 114 skips so far, entering deep-sleep`（22:24:34）与 `614 skips`（22:28:44），并且 env.json 的 `tx_stats` 是 `written:0, queued:0, peak:0` —— 服务端全程没有收到任何一帧上行麦克风音频，所以电台按下去了却发静音。
• 遥控器（移动款 CMCC）不可能提供语音音频：CHANGELOG v1.28.48 记载「小米蓝牙遥控器 2 / 2 Pro 的语音键…走 Google ATVV（AB5E0001-…）」；`remote_mic.py` 的 `find_known_device()` 只认小米 USB product id（`v2717p32b8`）、ATVV service UUID 或名字里带「遥控」/「mi rc」的设备；更早的 v1.28.1 条目也写明「未做：遥控器麦克风（厂商私有 BLE 通道…）」。所以拿移动遥控器的语音键只能发射、不能传话——这是能力边界，不是故障。
• “话咪也没声音”与盒子无关：服务端只把音频写进电台的 USB 声卡（日志 RX 侧 `USB Audio Device: - (hw:1,0)`, 44100Hz 正常在跑），前面板手咪走的是电台自己的 mic 通路。要分清只需在电台面板上单独用手咪 PTT 试一发看 ALC/PO 有没有摆动。
• “小米遥控器能搜到却配不上 / 原来配好的也配不上”是本仓记录过的 bluez 状态问题：`net_bt.py` 的 `power_cycle()` 注释就是「clears bluez's cached link keys」，`settings.html:1975` 的文案是「已配对，但按键还没反应。点「重配」再试一次（这一步会清掉旧配对并重启蓝牙）」；另有一次实测（CHANGELOG，2026-10-19 相关记录）是「三次 remove+re-pair 都没用，一次 `systemctl restart bluetooth` 立刻修好」——守护进程里的半死 HOG 会话不在磁盘上。
• “断电的小米遥控器仍然能收到”是已知的缓存回声，不是缓存没更新：`net_bt.py:143-147` 明确「既没名字也没信号强度的条目是上一次扫描的缓存回声，不是'现在就在旁边'」并丢弃；但 `bluetoothctl devices` 里带名字的旧设备会保留（`net_bt.py:262-275`，排序放到最后）。列表里没有 RSSI 的那几行就是在库里的旧记录。
• 体检摘要里的告警不能当成本次证据：摘要引用的 `No audio input device found` 与 `could not open port ''` 全部是 2026-10-01 的旧行，而当前会话 env.json 是 `serial_connected:true`、`USB Audio Device (hw:1,0)`，日志 22:19:43 还有 `scope_pipe: first frame received — spectrum active (span=8, s_meter=115, wf1_max=164)` —— 真实频谱在工作，摘要那句「S 表合成回退」是旧行误判。
• 包内没有任何蓝牙/`remote-mic`/`localctl` 日志行（两段日志都只到 120 行，且都是 FT8 与轮询），因此“XM 遥控器配对失败的具体原因”无法从本包判定；页面会回显 `bluetoothctl` 的原话（`没有配上：<原话>`），那一段才是判据。

你要做的

• 要“拿着遥控器说话发射”，必须换小米蓝牙遥控器 2 / 2 Pro 并配对成功（只有它走 ATVV 麦克风通路）；移动/CMCC 那支只能调频和按 PTT。
• 在换之前，语音发射请用网页麦克风：按住网页 PTT，浏览器授权麦克风权限并选对输入设备（网页 🎙 Vol 可到 +25 dB）；日志里出现 `Audio TX client connected (… owner=True)` 后应能看到 `tx_stats.written` 增长。
• 先验证电台射频侧：在电台面板上单独按手咪 PTT 发一声，看 ALC/PO 有无摆动。不摆动 → 是电台的 MIC/菜单或手咪接线问题（与盒子无关）；摆动 → 问题只在音频源，按上一条处理。
• 小米遥控器配对前：同时长按「OK + 返回」5 秒进配对模式，盒子 1 米内，手机/电视上配过的先在对方设备里「忘记这台设备」；失败时页面会显示 `没有配上：<原话>`，把原话发回给支持。
• 原遥控器配不上或状态混乱：打开 `/settings` → 遥控器面板点「重配」（清旧配对 + 蓝牙上下电 + 重新配对）。连续两次仍不行，在设置页点「重启蓝牙」（`systemctl restart bluetooth`）后再配一次 —— 半死的 HOG 会话只有重启 bluez 能清掉。
• 扫描列表请按信号强度认设备：带 RSSI 的那一行才是此刻在广播的遥控器；只有名字没有 RSSI 的是 bluez 库里的旧记录（包括已经断电的那支），忽略即可。
• 想确认遥控器麦克风守护进程是否在跑：在服务器日志里搜 `remote-mic` / `ATVV caps` / `installing bleak/dbus-fast`；没有这些行说明守护进程没起来（1.28.49 的服务端兜底会在日志里自报）。

相关代码：remote_mic.py:find_known_device（麦克风只对小米 ATVV 设备成立）；net_bt.py:power_cycle（重配/清旧密钥路径）

FTDX101MP使用128.23，频谱没有，和ft891使用时的频谱显示一样。切换模式，NR,NB切换VFO,-AB频率,COMP,AMP切换，ATT切换按键

FTDX101MP「频谱没有」是本机型设计如此——Yaesu 全家族 ASCII CAT 都没有频谱数据流，界面只画 S 表合成曲线（与 FT-891 完全相同，属预期，不是缺陷）；ATU 是未验证机型的已知未验证项，证据不足以判为代码缺陷，按电台侧自检 + 可选开启未验证发射处理

诊断

• 频谱没有 = 预期行为：env.json 显示 model=ftdx101mp、scope_type=none，backend.py:69 硬编码 scope_type="none"（no documented CAT waveform），cat_core.py:652-655 注释明确「Yaesu ASCII CAT 全家族无 scope 波形，瀑布是 S 表合成器」；CHANGELOG v1.16.0（'没有真机频谱数据源…UI 继续用既有的 S 表合成频谱，不伪造瀑布数据'）与 SDD V3.07（'频谱仍是 scope_type="none"（S 表合成，同全家族）'）同签名。summary.txt 里的「频谱：出现 S 表合成回退」在这台机型上是常态而非故障
• 用户自述'和 FT-891 使用时的频谱显示一样'恰好印证：FT-891 与 FTDX101MP 同属无 scope 数据流的 Yaesu 家族（AGENTS.md：FT-891 scope_type=none，走 S 表合成器），二者频谱表现相同是设计一致
• 合成曲线只看 S 表：CHANGELOG v1.28.35/SDD V3.17 记录合成帧只在 S 表变化时改变（本机约 2.4 Hz 轮询），所以瀑布几乎不动、看起来像'没有频谱'
• ATU：FTDX101MP profile 里 has_atu=True（yaesu_profiles.py:464）所以 UI 显示 ATU 键，set_tuner 发 AC{value}（cat_core.py:992-994）；但该机型 verified=False（id_answer="" TODO(hw-verify)，env.json tx_gated=true），AC 命令形状未硬件验证，且历史（CHANGELOG/SDD）无 FTDX101MP ATU 缺陷签名，无法从包内证据确认是代码缺陷还是电台侧天调未启用/未安装
• 发射门禁：summary.txt 与 env.json 均显示未验证机型拒绝发射（TX refused），ATU/TUNE 相关动作若需要电台键控发射则受此限制（backend.py:284 _GATED_METHODS={"set_ptt","set_tune"}；本机 tune_via="tx2"，yaesu_profiles.py:467）

你要做的

• 频谱：无需任何处理。FTDX101MP 与 FT-891 一样没有 CAT 频谱数据流，界面瀑布只是随 S 表变化的合成曲线，属正常；要真频谱需换 FT-710（FT4222）或 Icom（CI-V 0x27）机型
• ATU 第一步（电台侧自检）：直接在电台面板上按 TUNER/ATU 键，确认内置天调能正常调谐——排除天调未安装、未启用或菜单里被关闭
• ATU 第二步（软件侧）：本机是未验证机型、默认拒绝发射，若需软件里用 ATU/TUNE，到 ☰ 菜单「实验机型的发射」勾选允许（或在 mrrc_modern.env 设 MRRC_ALLOW_UNVERIFIED_TX=1）并重启后再试
• 若电台面板天调正常、软件里 ATU 仍无效，重新上报诊断包，并附上点击 ATU 那一刻 server.log 里 AC 命令的回读/报错行（确认电台对 AC0/AC1 的应答）

(未填写)

音频 RX/TX 配置名锁死了旧 ALSA 编号 'USB Audio Device: - (hw:0,0)'，而电台声卡现已枚举在 hw:1,0，与 SDD V2.88/CHANGELOG v1.7.7 记录的配置名锁死同签名；自动检测已兜底恢复，但配置未更新导致告警与 -9993 反复出现。

诊断

• 音频设备配置名过期：env.json 的 configured_rx/configured_tx 都是 'USB Audio Device: - (hw:0,0)'，但设备列表只有一条 index 0 = 'USB Audio Device: - (hw:1,0)'，ALSA 编号从 0 漂到 1，配置名里带的 '(hw:0,0)' 子串不再匹配，触发 summary 里 3 条 'Configured audio device … not found'。
• 与历史同签名：SDD V2.88（2026-10-16）记录 'Configured audio device … not found' + 'RX open failed … re-initializing PortAudio'；CHANGELOG v1.7.7 明示 'index-locked FT710_AUDIO_RX/TX_DEVICE=<n> configs are inherently fragile across re-enumeration — lock by name'。当前 1.28.36 已包含 name 子串匹配+泛名自动检测+重初始化重试修复，且日志显示自动检测实际兜底恢复（RX audio started: hw:1,0）→ 与 v1.7.7/SDD V2.88 同签名，当前版本应已包含该修复，按回归/配置仍锁死 ALSA 索引排查。
• 自动检测兜底但打开失败发生过：server.log 多次 'RX audio started: [0] USB Audio Device: - (hw:1,0)' 说明音频最终在 hw:1,0 恢复；但 summary 有 3 条 'RX open failed ([Errno -9993] Illegal combination of I/O devices) — re-initializing PortAudio'，说明用旧索引/旧配置名打开失败过。
• TX 增益削顶（使用问题，非缺陷）：server-prev.log 多条 'audio levels: TX gain +9 dB is clipping the signal (17..77/960 samples…)'，盒级 TX 麦克风增益 +9 dB 过高。
• 频谱实际正常：server.log 'scope_pipe: first frame received — spectrum active (span=8, s_meter=52, wf1_max=180)' 与 'sync_recovered' 表明 FT4222 频谱工作；summary 的「S 表合成回退」在提供的日志尾部未复现，应为无频谱客户端空闲期的瞬时回退，不是本次主问题。

你要做的

• 打开盒子「连接设置」页，重新检测并重新选择音频 RX / TX 设备（让它保存当前 hw:1,0 的名称），或清空音频设备项让自动检测接管——自动检测按泛名 'USB Audio Device' 匹配，与 hw 编号无关。
• 或直接编辑 /opt/mrrc_modern/env/mrrc.env：删除或修正 MRRC_AUDIO_RX_DEVICE 与 MRRC_AUDIO_TX_DEVICE 两行（现在写死旧名 'USB Audio Device: - (hw:0,0)'），保存后重启服务生效。
• 在 ☰ 菜单「音频电平」把 TX 麦克风增益从 +9 dB 降到 0 dB 附近，消除削顶告警（削顶 TX 会 splatter）。
• 若仍偶发 -9993：检查电台 USB 线/供电是否稳定——USB 重枚举会再次改变 hw 编号，避免经过带供电的 HUB 连接电台声卡。

相关代码：audio_handler.py:_find_rx_device（配置名子串匹配与 not-found 回退逻辑）；-9993 重初始化见 audio_handler.py restart_rx / _reinit_pyaudio 路径

更新最新版后，频率框多出来一个1字，比如114.270，107.068。

频率框多出的前导「1」是 v1.28.35 携带的已修复显示缺陷（百 M 位 span 的缓存版本号没 bump），升到 v1.28.36 即消失

诊断

• 症状与历史记录同签名：用户报「频率框多出一个1，如 114.270 / 107.068」，CHANGELOG v1.28.36 标题即「FT-710 频率显示多出一个「1」：FP23 忘了 bump 缓存版本号」（CHANGELOG.md:5）
• 根因：FP23（v1.28.27）在 index.html 加 <span class="freq-digit freq-lead" id="f100m">1</span>、在 ft710.css 加 .freq-lead{display:none}，但 index.html 里 ft710.css?v=27 与 ft710_ui.js?v=40 一个都没 bump —— 浏览器拿到新 HTML 却用旧 CSS/JS，那个默认文本「1」就显示出来（CHANGELOG.md:7-11）
• 电台实际频率正确、只是显示多一位：日志 Memory recall freq=14270000（=14.270 MHz）、freq=7068000（=7.068 MHz），vfo_b_freq 变化均为 14270000↔7068000，无异常值，不影响收发
• 当前版本 1.28.35 早于修复版本 1.28.36，不含该修复（env.json version=1.28.35；日志 update: applying 1.28.35）

你要做的

• 升级到 v1.28.36：页面 ☰ → ⬆️ 软件更新 → 立即升级（或启动器窗口按 U），该版已 bump ?v=28/41 并给 #f100m 加 hidden 兜底
• 升级后若仍看到那个「1」，硬刷新浏览器一次（Ctrl+Shift+R）或完全退出重进 —— 旧 service worker 仍在接管当前页面时旧 CSS 会继续露出来（CHANGELOG v1.28.36 验证段）
• 此问题纯显示，实际频率与收发均正常，无需改动电台或配置

相关代码：static/index.html(#f100m span) / static/ft710.css(.freq-lead) / static/ft710_ui.js(formatFrequency) —— 已在 v1.28.36 修复

Ft-991A

FT-991A 在 v1.28.26 上暴露的「>100MHz 频率百 M 位不显示 / 频谱设置报错 / SQL 不同步」已由 v1.28.27 (FP23) 修复，当前版本早于该修复，升级即可解决。

诊断

• 当前安装版本 1.28.26，FT-991A 已正确接入（env.json: version=1.28.26, radio.model=ft991a, display_name=Yaesu FT-991A, serial_connected=true），本包编号 20261101-103310-caf7 被 CHANGELOG v1.28.27 (FP23) 条目点名，是其修复动机之一。
• 日志签名『Command error (scope_speed=3): 'YaesuCatController' object has no attribute 'set_scope_speed'』+『Spectrum broadcast active: S-meter fallback』与 v1.28.27 修复的缺陷同签名：server.py 对任意后端无条件调 cat.set_scope_speed/set_scope_span，而 Yaesu 控制器旧版缺这些方法 → 每次点选抛 AttributeError、扫宽弹回 100 kHz（CHANGELOG v1.28.27『频谱/静噪』段）。
• 当前版本 1.28.26 早于修复版本 v1.28.27 (FP23)，故不含修复：修复已在仓库生效（backends/yaesu/cat_core.py:646 起 set_scope_span/set_scope_speed/set_scope_mode 现为 UI-only 记账方法、不再走 CAT、不再报错）。
• 频率 >100MHz 问题同源：v1.28.27 修复了 6 处 75 MHz 天花板与 7 位频率显示缺百 M 位（CHANGELOG『频率（服务端+网页）』段）；server.log 已见 FA144500000/FA435000000 被电台接收。
• S 表合成回退（S-meter fallback）是 Yaesu 全家族机型限制：FT-991A 的 scope_type=none，无真实频谱（FT4222/CI-V 0x27 均不走），属预期非故障；升级后扫宽设置不再报错但仍是合成瀑布。
• TX 门禁已解除：env.json tx_gated=false（MRRC_ALLOW_UNVERIFIED_TX=1 已设）；summary 里『Yaesu FT-891 is not hardware-verified — transmit refused』是 2026-10-31 16:31–16:35 旧日志（当时配成 FT-891），当前 ft991a 可发射，无需处理。
• 音频当前正常：server.log『RX audio broadcast active: Opus, 1 clients, peak=2.5%』；summary 的 PortAudio -9996/No audio input device/Illegal combination 均来自 legacy.log(10-26) 与 10-28~10-31 旧时段，当前 env.json 已有 USB Audio CODEC (hw:1,0)，非当前问题。

你要做的

• 把盒子升级到 v1.28.27 (FP23)（☰ 菜单「升级」或一键升级通道）——该版本修复频率百 M 位、scope_span/scope_speed/scope_mode 报错、SQL 回读、FT-991A CAT RATE 默认 4800 四项。
• 升级后重开页面验证：切 2m/70cm 频率应完整显示 145.000.000 / 435.000.000（不再丢百 M 位），频谱/扫宽选择不再弹回 100 kHz 或报错，SQL 滑杆能回读。
• 频谱/瀑布是 S 表合成回退（Yaesu 全机型无真实频谱），属机型限制接受即可；若必须真实瀑布需换 FT-710 / IC-7300 系。
• 发射：保持 MRRC_ALLOW_UNVERIFIED_TX=1（当前 tx_gated=false），不要改动该项。
• 音频无需处理；若日后又出现『USB Audio CODEC not found』，检查电台是否开机且 USB 线已插好（声卡在电台内部，随电台 USB 枚举）。

相关代码：已修复：backends/yaesu/cat_core.py:set_scope_speed/set_scope_span/set_scope_mode + server.py scope 分发（v1.28.27）

换了FT-991A，本机为真机，频率显示在100M以上不现实百M位，选择FT-991A需要反复几次设置重启

FT-991A 已能连收（音频正常），但保存连接设置时机型被写回 ft710，且 ≥100MHz（2m/70cm）的显示与设置存在新接入机型缺陷（百MHz位不显示、设 2m 弹回 6m）。

诊断

• 机型回退 ft710（证据充分）：日志 10:26:18 以 ft991a 启动成功且能切 2m，10:26:46 「Saving connection settings: model=ft710」把机型写回 ft710，10:26:54 重启即为 ft710（env.json radio.model=ft710、scope_type=ft4222）。/api/setup 按表单 radio_model 直接落盘（server.py:4409-4448），即保存连接设置时下拉未选中 FT-991A 就会整体回退——这正是「选 FT-991A 要反复几次」的原因。历史签名「机型被改回 ft710」见 SDD V3.04(v1.28.2，启动器探针路径)，但本机是 Linux 盒子，本次是 /api/setup 保存路径，机制不同、非同一修复的回归。
• ≥100MHz 缺陷：用户在 ft991a 下切 2m，日志 FA144500000 OK（ACK 成功）但约 1 秒后 IF 轮询读回 vfo_a=50150000 Hz（6m），144.5MHz 实际未生效；前端主频是分段数码管（index.html #f100m 为百MHz位），用户报「100M 以上不显示百M位」，renderFrequency() 对该位更新有缺陷。FT-991A 是本仓首个 2m/70cm 机型（v1.28.23 / FP22 新增，见 CHANGELOG 顶条与 SDD V3.07），≥100MHz 路径此前从未被触发，历史无同签名记录。
• TX 门禁属预期（非缺陷）：summary 中「Yaesu FT-991A is not hardware-verified — transmit refused. Set MRRC_ALLOW_UNVERIFIED_TX=1」——未验证机型默认只收不发。
• 音频已正常：最新启动日志 RX audio started [1] USB Audio Device (channels=1, resampled to 48k)；10-28 的 -9998/-9993 是换机前的历史错误，现已恢复。

你要做的

• 保存连接设置前，确认「电台型号」下拉框是「Yaesu FT-991A」（不是 FT-710）再点保存；保存后自动重启，到 ☰ 菜单页脚核对机型是否已是 FT-991A。若仍反复变回 FT-710：编辑 /opt/mrrc_modern/env/mrrc.env，确保 MRRC_RADIO_MODEL=ft991a 只出现一行且无空值/重复条目覆盖，然后重启服务。
• 2m/70cm（≥100MHz）暂先不用，先只操作 HF/6m（<100MHz）；该波段的显示与频率设置缺陷待修复版本。
• 需要发射时：确认电台无误后，在 env 文件中设 MRRC_ALLOW_UNVERIFIED_TX=1 并重启（未验证机型的预期门禁）。

相关代码：static/ft710_ui.js:renderFrequency（#f100m 百MHz位未按 ≥100MHz 更新）

这个是W103D盒子陪FT-991A电台，配置是FT-891,频谱显示只能在100宽度，sql没能同步。

FT-991A 不在支持机型列表，被配成 FT-891 后真实频谱/扫宽本来就拿不到（Yaesu 系 scope_type 一律为 none，只剩 S 表合成的固定窄带图），静噪只下不读且 FT-991A 与 FT-891 的 SQ 命令未必一致；另有一处 set_scope_speed 方法缺失的代码缺陷（报错但无害，不影响收发）。

诊断

• 用户实际电台是 FT-991A，但盒子配置为 FT-891（problem.txt『W103D盒子陪FT-991A电台，配置是FT-891』；env.json radio.model=ft891）。FT-991A 不在支持机型列表里（backends/__init__.py 的 _BACKENDS 仅有 ft710/ic7300 系/ftdx10/ftdx101d/ftdx101mp/ftx1/ft891，无 ft991a），FT-891 只是『最接近的替代』。
• 『频谱只能在 100 宽度』是机型限制不是故障：Yaesu 系 capabilities 里 scope_type 固定为 "none"、scope_spans={}、scope_speeds=()（backends/yaesu/backend.py:69），没有真实频谱（FT4222/CI-V 0x27 都不走），只能走 S 表合成回退——summary.txt『频谱：出现 S 表合成回退——真实频谱未工作』与日志『Spectrum broadcast active: S-meter fallback, 1701 bytes/frame』互相印证，回退图是固定窄带，没有可调的扫宽。
• 『SQL 没能同步』：静噪只有单向下发 SQ0xxx（backends/yaesu/cat_core.py:711 set_squelch），而 settings_poll_items() 的回读项只有 af_gain/rf_gain/rf_power/filter_width/preamp/attenuator/agc，没有 squelch 回读（backend.py:151-160），所以滑杆只下不读；且 FT-991A 的 CAT 与 FT-891 不完全一致，SQ0xxx 未必被 FT-991A 接受。
• 代码缺陷（次要、无害）：日志『Command error (scope_speed=3): 'YaesuCatController' object has no attribute 'set_scope_speed'』——server.py:3357-3361 对任意后端无条件调用 cat.set_scope_speed(v)，但 set_scope_speed 只在 base.py:453 声明为抽象、由 ic7300/ft710 实现，YaesuCatController（cat_core.py）没有这个方法，故抛 AttributeError；报错不影响收发。
• 附带发现：日志反复『RX gain +24 dB is clipping the signal』『TX gain +25 dB is clipping the signal』，当前 RX/TX 增益设得过高在削波，属可自行调整项。

你要做的

• 确认机型预期：FT-991A 不在支持列表，配成 FT-891 只能拿到『最接近』的控制；任何 Yaesu 型号都拿不到真实频谱/瀑布/扫宽。若必须真实频谱，需换用受支持的 FT-710 或 IC-7300 系（CI-V 0x27 / FT4222 频谱）；只做语音收发的话，FT-891 配置可继续用，接受固定窄带 S 表图即可。
• 静噪：在 ☰ → 电台参数里拖 SQL 滑杆（0–100）观察电台是否实际动作；若电台无反应，是 FT-991A 与 FT-891 的 SQ0xxx 命令不匹配所致，属机型限制，不是设置错误。
• 削波：进 ☰ → 音频电平，把 RX 增益从 +24 dB、TX 增益从 +25 dB 下调（例如先降到 0 dB 附近），直到日志不再出现『is clipping the signal』。
• 发射（如需）：当前已开启未验证机型发射（env.json tx_gated=false、日志有正常 TX session），保持 MRRC_ALLOW_UNVERIFIED_TX=1 即可；不要动这项否则 FT-891 配置会拒绝发射。

相关代码：server.py:_execute_set_command（scope_speed/scope_span 分发未按后端 capability 门控）/ backends/yaesu/cat_core.py 缺 set_scope_speed

这个是W103D盒子陪FT-991A电台，配置是FT-891,频谱显示只能在100宽度，sql没能同步。

FT-991A 不在支持机型列表里，被配成 FT-891 后频谱只能是 S 表合成的固定窄带图（Yaesu 系 scope_type 一律为 none，无真实频谱/扫宽），静噪是单向下发无回读；另有一处 set_scope_speed 方法缺失的代码缺陷（报错但无害，不影响收发）。

诊断

• 用户实际电台是 FT-991A，但盒子配置为 FT-891（problem.txt：『W103D盒子陪FT-991A电台，配置是FT-891』；env.json：radio.model=ft891）。FT-991A 不在支持列表（支持机型仅 FT-710 / IC-7300 系 / FTDX10 / FTDX101D / FTDX101MP / FTX-1F / FT-891），FT-891 只是『最接近的替代』。
• 『频谱只能100宽度』是 FT-891 配置的预期行为，不是故障：backends/yaesu/backend.py:69-71 对全部 Yaesu 型号硬编码 scope_type="none"、scope_spans={}、scope_speeds=()，即没有 Yaesu 频谱波形（spec §2 D4『no documented CAT waveform』），频谱只能走 S 表合成回退（scope_handler.py update_from_radio_state 生成居中高斯峰），没有真实扫宽可选。
• 『SQL 没能同步』：backends/yaesu/cat_core.py:711 的 set_squelch 只是单向发 SQ0xxx，而 backends/yaesu/backend.py settings_poll_items（af_gain/rf_gain/rf_power/filter_width/preamp/attenuator/agc）里没有 squelch 回读项，因此滑杆只下不读；且 FT-991A 的 CAT 与 FT-891 不完全一致，SQ 命令未必被 FT-991A 接受。
• 代码缺陷（次要）：summary.txt 的 111 条 ERROR 首条为『Command error (scope_speed=3): YaesuCatController object has no attribute set_scope_speed』。server.py:3360 对 scope_speed 调 cat.set_scope_speed，YaesuBackend 的 _make_delegate（backend.py）用 getattr(self._cat, name) 转发到 YaesuCatController，而 cat_core.py 未实现 set_scope_speed（仅 ft710/cat_controller.py:773 与 ic7300 有），故抛 AttributeError。此报错不影响收发，属日志噪音。
• 音频不是当前问题：summary 里的 PortAudio -9996 / No audio input device / RX open failed -9993 均来自 legacy.log（2026-10-26）与 10-28 的旧时段；当前 env.json 的 audio.devices 有 USB Audio CODEC (hw:1,0)，server.log（17:02 起）显示 TX/RX 会话与录音正常（『TX audio started』『RX audio started』『Recording started』）。

你要做的

• 确认电台与配置：FT-991A 不在支持列表，配成 FT-891 只能拿到『最接近』的控制，真实频谱（瀑布/扫宽）在任何 Yaesu 型号上都拿不到——若必须真实频谱，需换用 FT-710 或 IC-7300 系（CI-V 0x27 / FT4222 频谱）这类受支持且带频谱的机型；只用语音收发的话，FT-891 配置可以继续用。
• 静噪：在 ☰ → 电台参数里拖 SQL 滑杆（0–100），观察电台 SQL 是否实际动作；若电台无反应，是 FT-991A 与 FT-891 的 SQ0xxx 命令不匹配所致，属机型限制，不是设置错误，换支持机型后可正常。
• set_scope_speed 报错可忽略（不影响 PTT/TX/RX），无需用户处理；属后端缺失方法，待修复。
• 音频无需处理：当前已正常，历史里的 -9996/无输入设备是早期状态。

相关代码：backends/yaesu/cat_core.py（缺 set_scope_speed，被 server.py:3360 调用；或 backend.py 的 _make_delegate 应把该命令降级为无操作）

安卓版1.1.35版，切换频率时会偏，要重新点击一次才恢复到保存的相应频率。

安卓 1.1.35 切频走的是两条独立 set（freq 然后 mode），FT-710 在 SSB 模式切换上把频率按边带偏移 ±1400 Hz 移动；服务端只在原子 memRecall 路径里于 MD 之后重发一次频率做补偿，所以偏移留在电台与 UI 上，再点一次（只发 freq、不再触发模式切换）才回到保存值。

诊断

• 现象与 1400 Hz 边带偏移完全对得上：切到 14.270 MHz 后电台读数 14268600（−1400，USB），切到 7.068 MHz 后 7069400（+1400，LSB）——方向随边带改变，正是 FT-710 的 SSB 载波/显示偏移，不是网络或丢包噪声。证据：`IF poll: vfo_a=14268600 Hz (+7200600 Hz)`、`IF poll: vfo_a=7069400 Hz (-7200600 Hz)`
• 仓库自己记录过这件事，但补偿只做在 memRecall 里：`server.py:_handle_ws_message` 的 memRecall 分支注释写着「SSB mode changes can shift the carrier/displayed frequency by the sideband offset (observed ±1400 Hz on FT-710). Set the stored frequency again after MD0 so the final polled frequency matches the memory slot.」，因此它发 FA → MD → **再发 FA**
• 本次会话走的是另一条路，没有这个补偿：两条 `vfo_a_freq changed` / `mode changed` 的调用栈都是 `server.py:5174/ws_radio <- server.py:2578/_handle_ws_message <- server.py:2938/_execute_set_command`（freq）与 `server.py:2957/_execute_set_command`（mode），说明安卓发的是两条独立 `set`，而不是 `memRecall`（日志里没有任何 `Memory recall: freq=… mode=…` 行）
• `_execute_set_command` 的 freq 分支只 `cat.set_frequency()` + `radio.update()`，mode 分支只 `cat.set_mode()` + `radio.update()`，没有 memRecall 里的「MD 之后重发频率」；于是一次跨频段切频 = freq（波段堆栈自动换模式）+ MD（再次位移）→ 电台落到 ±1400 Hz 外，1 s 后的 FA 轮询把它读回来并广播给客户端
• 「再点一次就好」也被日志逐字证实：偏移出现后客户端再发一条只含 freq 的 set，就落回 14270000 且不再偏移——`vfo_a_freq changed: 14268600 → 14270000 [caller: … _execute_set_command]` 紧跟 `IF poll: vfo_a=14270000 Hz (+1400 Hz)`；7.068 MHz 同型：`7069400 → 7065000` 后再 `7066400`（+1400）反复复现
• 这些 1400 Hz 读数不是陈旧读，而是电台真实频率：`skip_next_poll("if", 1.0)` 之后 1 s 的轮询读的是电台答案，而且再发一次 freq 后读数立刻正确
• 历史检索（`CHANGELOG.md` + `SDD/14-version-history.md`，关键词 `1400` / `IF poll` / `漂移` / `频偏`）**没有**同签名记录：最接近的是 `SDD/14-version-history.md` 的 `SDD V1.2 … Freq drift fix: DN; is FT-710 active-VFO step-DOWN (~20 Hz), not DNR — removed from settings poll`，那是 20 Hz 的 `DN;` 误发，与本次 1400 Hz 边带偏移不同签名，因此不能判为「已修复后的回归」，这是 memRecall 之外缺少同一补偿的缺口
• 包里其余告警与本问题无关，只能说明那天 USB 音频曾掉过一次：`Failed to start RX audio: [Errno -9998] Invalid number of channels`、`RX open failed ([Errno -9993] Illegal combination of I/O devices)`、`No audio input device found`；且 `diagnostics/summary.txt` 的「频谱出现 S 表合成回退」与日志矛盾（`scope_pipe: first frame received — spectrum active` 反复出现），这两项都不解释切频偏移
• 误入包的 FTDX101MP 门禁告警（`Yaesu FTDX101MP is not hardware-verified — transmit refused`）与 env.json 的 `radio.model=ft710` 不一致，属当天切过机型的残留，也与切频偏移无关

你要做的

• 先用读数确认这是固定 1400 Hz 边带偏移而非随机故障：切到 14.270 MHz 后看频率显示是不是 14.2686，切到 7.068 MHz 后是不是 7.0694 —— 是则本诊断成立（若偏移数值每次不同，再报一次带当前诊断包）
• 在安卓上继续用「再点一次同一频率」规避：第二下只发 freq、不再触发模式切换，一次到位；同一频段内切频（模式不变）本来就不会偏，跨频段（7 MHz↔14 MHz）必偏，这是现版本的规律
• 更省事的替代：在浏览器里打开同一台服务的网页端做记忆频道/频率切换 —— 网页的 memRecall 是原子的（freq→mode→再 freq），偏移会被服务端自己消掉；安卓可只用来看频谱、按住发射
• 如果一定要用安卓切跨频段：把模式先切到目标模式、再点频率（模式已就位时最后一次只发 freq），不要在频率切换后立刻改模式
• 升级到包含修复的服务端版本后再试（补偿应加在 `_execute_set_command` 的 mode 分支，或安卓改走 `memRecall`）；升级前不需要动 `MRRC_*` 环境变量、也不需要重放电台固件

相关代码：server.py:_execute_set_command（freq/mode 分支——缺 memRecall 那种 MD 之后重发频率的 ±1400 Hz 补偿；对照 server.py:_handle_ws_message 的 memRecall 分支 / FT710Android 记忆调用应改走 memRecall）

安卓版可以设置把PTT按键设置到音量上下键吗(参考外国软件RCFORB，在设置按键时你点击哪个要设成发射键，设置时就按相应的按键，这个按键就被设置成发射键了。)

这是一条功能请求（把安卓 App 的 PTT 映射到音量键/自定义按键，像 RCFORB 那样按键学习），不是缺陷；当前安卓 App 完全不接物理键，音量键仍归系统音量，现有可用的物理发射键是盒子侧蓝牙遥控器的语音键。

诊断

• 诉求本身是功能请求，不是故障：problem.txt 原文「安卓版可以设置把PTT按键设置到音量上下键吗(参考外国软件RCFORB，在设置按键时你点击哪个要设成发射键，设置时就按相应的按键，这个按键就被设置成发射键了。)」，诉求是按键可自定义 + 便于把 App 装进安卓系统里发射。
• 代码事实：安卓 App 主源码树里没有任何物理键/媒体键接入 —— 对 `FT710Android/app/src/main` 全树检索 `onKeyDown|onKeyUp|dispatchKeyEvent|KeyEvent|MediaButton` **零命中**；PTT 只有底栏屏幕按钮（`UI/MainScreen.kt` 底部固定 PTT/CQ/TUNE/REC，`MainActivity.kt` 无按键分发）。所以「音量键当 PTT」目前没有实现，也没有半成品逻辑。
• 历史检索无同签名记录：`CHANGELOG.md` 中「音量键」只出现在**盒子本地蓝牙遥控器**一条线上（`local_ctl` / AD-028：语音键 = 按住发射，音量 ± = AF 增益，见 CHANGELOG「键位（W103D 上实测：中国移动语音遥控器 CMCC_Voice_Remote）：语音键 = 按住发射 … 音量 ± = AF 增益」），与安卓 App 的按键映射无关；`FT710Android/CHANGELOG.md` 中 PTT 相关条目均为按钮摆放、旋转保持发射、权限导致的「没功率」等，从未有过音量键 PTT。因此这不是已修复老问题的回归，也不是配置能开关的现有能力。
• 诊断包来源是**盒子**而非手机端：env.json `version=1.28.22`、`platform=Linux-6.18.54-ophub-aarch64-with-glibc2.36`、`radio.model=ft710`、`log_dir=/opt/mrrc_modern/.local/share/MRRC-Modern/logs`；manifest 里有 `diagnostics/client.json` 但摘要未给出其内容，所以无法核对安卓 App 版本号 —— 这也限制了「某版本曾支持过」的排除范围。
• summary.txt 里的告警与本次诉求无关，属历史残留：`Failed to start RX audio: [Errno -9998] Invalid number of channels`（2026-10-28 17:50）、`No audio input device found`（2026-10-29/30）是两三天前的条目；当前 server.log 频谱真实工作（`scope_pipe: first frame received — spectrum active (span=7, s_meter=58, wf1_max=255)`），并无崩溃痕迹（summary：16 次启动、无崩溃痕迹）；`Yaesu FTDX101MP is not hardware-verified — transmit refused`（2026-10-29）与 env.json 当前 `radio.model=ft710, tx_gated=false` 不一致，同样是早前用别的机型跑过的旧日志。
• 若真要在安卓设备上用物理键发射，需要注意现状边界：安卓端 App 释放 PTT 依赖 `onStop()`（退后台无条件释放，旋转不松手），把 App 装进车载/安卓盒子系统的场景下这一点不会变；即使将来加了按键映射，也不改变「退后台即松键」的安全规则。

你要做的

• 短期：继续用屏幕底栏的红色 PTT（按住说话），横屏全屏（⛶）时它是最宽的一块，误触最少；音量键目前只会调系统音量，不会触发发射。
• 如果你要的是「不用盯屏幕也能发射」的物理键：把手机遥控器的需求交给盒子那一条现成通路 —— 给 W103D 盒子配一只蓝牙 HID 遥控器（中国移动语音遥控器 CMCC_Voice_Remote），按住「语音键」即为发射、松开即停，按键表见 `docs/W103D_REMOTE_GUIDE.md`。这条路不需要改 App，也不影响手机上同时用网页/App 收听。
• 若一定要「按哪个键就把哪个键设成发射键」（RCFORB 式按键学习）：这是需要产品决策的新功能，本次上报已按功能请求归类，请在 🐞 反馈中保留该描述即可；不要尝试用安卓系统设置或第三方按键映射工具硬改 —— 系统级音量键重映射拿不到 App 内的按住/松开语义，容易造成「松开了却还在发射」。
• 顺带（与本题无关但诊断包里能看到）：盒子上 2026-10-29 还出现过 `TX 门禁：未验证机型拒绝发射 (FTDX101MP)`，如果换回 FT-710 后仍想开未验证机型的发射，在 ☰ 菜单「实验机型的发射」里打开（需勾选确认，重启免），否则按键会一直被拒。
• 如果后续版本真加了按键映射，验收时请确认两点：松手必须立刻发 `ptt:false`；旋转屏幕不得中断发射（现规则：配置变更不松手、退后台无条件释放）。

相关代码：FT710Android/app/src/main/java/com/hamradio/ft710android/App/MainActivity.kt（无 onKeyDown/dispatchKeyEvent）+ UI/MainScreen.kt 底栏 PTT 按钮：新增按键映射应落在这里，并在 ViewModel/PttManager 上保持按住→ptt:true、松开→ptt:false、onStop 无条件释放

安卓版可以设置把PTT按键设置到音量上下键吗(参考外国软件RCFORB，在设置按键时你点击哪个要设成发射键，设置时就按相应的按键，这个按键就被设置成发射键了。)

安卓客户端当前没有任何音量键处理逻辑——PTT 只有屏幕上的触摸按钮，音量键发射属于尚未实现的功能请求（不是缺陷，也不是本包日志里的故障）

诊断

• 用户诉求是「安卓版把 PTT 映射到音量上/下键，设置时按哪个键就绑定哪个键」，这是功能请求；problem.txt 里没有描述任何异常现象。
• 安卓工程里完全没有音量键/按键事件的代码：在 FT710Android/ 全树检索 KEYCODE_VOLUME / VolumeUp / dispatchKeyEvent / onKeyDown 零命中，因此不存在「设置了不生效」的可能，而是压根没做。
• 承载入口已确认 = FT710Android/app/src/main/java/com/hamradio/ft710android/App/MainActivity.kt：只有 onCreate/onStart/onStop（onStop 里调 onPttRelease()），没有任何 onKeyDown / dispatchKeyEvent 覆写；屏幕 PTT 在 FT710Android/app/src/main/java/com/hamradio/ft710android/UI/PTTButton.kt，走 PTTManager（PTT/PTTManager.kt）。
• 历史检索无同签名：grep 「音量键|volume key|KEYCODE_VOLUME」 只命中 CHANGELOG.md:1305「遥控器音量键只能推到 39 %：百分比当成了 0–255 的寄存器」——那是盒子端蓝牙遥控器（local_ctl.py 那条线）的音量寄存器问题，与安卓音量键发射无关；CHANGELOG 中也没有任何「安卓硬件键发射」条目，故不能判回归。
• 本包日志与该诉求无关，属正常状态：server-prev.log 频谱正常（scope_pipe: first frame received — spectrum active）、TX 会话正常（frames=32 fed=32 decode_fail=0 written=26 queue_drops=0 peak=8%），server.log 只有空闲轮询与会话指标；summary.txt 里 TX 门禁两条 2026-10-29 的 FTDX101MP 拒绝发射是当时的机型门禁提示，与 env.json 的 model=ft710、tx_gated=false 不冲突。
• 音频两条 ERROR/WARNING（[Errno -9998] Invalid number of channels、No audio input device found）出现在 2026-10-28/29 的历史日志中，而 2026-10-31 的连接里 RX 已正常启动（RX audio started: [1] USB Audio Device (hw:1,0), channels=1），属环境抖动，不是本次诉求的原因。

你要做的

• 当前版本（1.28.22 安卓客户端）只能用手指按住屏幕上的 PTT 按钮发射，音量键暂时不做发射键——不要期待在设置里能找到这个开关。
• 想在手机上少动手时，可以先用第三方「音量键映射/按键重映射」类辅助 App，把音量键映射成屏幕上 PTT 按钮位置的点击/长按；注意这类工具需要无障碍权限，属于手机侧临时办法，MRRC 不保证手感与松手即停的行为。
• 如果你同时装了 W103D 盒子，最省事的免触摸发射是盒子自己的蓝牙 HID 遥控器（配对后按键直接控制，含 PTT，见 docs/W103D_USER_GUIDE.md 与 docs/W103D_REMOTE_GUIDE.md），比在手机上摸屏更接近你说的 RCFORB 体验。
• 把这条需求继续用「🐞 遇到问题」渠道提交即可（本单已经是需求形态），回复里写明「希望安卓端 PTT 支持可自定义硬件键（音量上/下键），并且像 RCFORB 一样按一下学习绑定」——需求会进入待决策队列而不是被当故障修。

相关代码：FT710Android/app/src/main/java/com/hamradio/ft710android/App/MainActivity.kt（无按键事件覆写，是新增音量键-发射映射的落点）→ PTTManager/UI/PTTButton.kt；属新功能，非缺陷修复

FTX-1升级1.28.18，APP版本1.1.34

1.28.18 已含 FP12/FP13/FP14 的 FTX-1 修复，但包内日志显示两处旧的音频缺陷同签名复发：TX 侧数据已到、一帧也没写进声卡（电台被键控却发静音），RX 采集接口静默停摆（PyAudio 仍报流开着）—— 按回归排查，不是环境或使用问题

诊断

• 报障正文只有「FTX-1升级1.28.18，APP版本1.1.34」，没有现象描述；以下按包内日志可确证的三条异常定位。
• TX 门禁不是当前阻塞：`Yaesu FTX-1F is not hardware-verified — transmit refused` 命中 26 次（最新 2026-10-28 18:06:51），FTX-1 属未验证机型，PTT 默认被服务端拒绝（`backends/yaesu/backend.py:_tx_allowed()`，`MRRC_ALLOW_UNVERIFIED_TX` 或设置页开关才放行）；而 env.json 采于 18:43:58 已报 "tx_gated": false，说明打包时发射门禁已解除 —— 之后再按键仍无声，原因在音频链路。
• 频谱出现「S 表合成回退」对 FTX-1 是预期：env.json `"scope_type": "none"`，CHANGELOG v1.16.0 明确「没有真机频谱数据源（这些机型不输出 FT4222/CI-V 波形）：UI 继续用既有的 S 表合成频谱，不伪造瀑布数据」，不是缺陷。
• TX 音频一帧也没到声卡：连续三个会话 `TX session: frames=8 fed=8 decode_fail=0 written=0 write_err=0 queue_drops=0 peak=0%`，而同秒另一行 `audiolevels: audio levels: TX gain +14 dB is clipping the signal (541/960 samples …)` —— 麦克风数据到服务端并已削波，但 `audio_handler.py:feed_tx_audio()` 里 `self._tx_peak` 就是在该函数内统计的，peak=0 % 且 queue_drops=0 说明它是在 `with self._tx_lock: if self._tx_stream is None: return` 处提前返回：`written` 只在 `write_tx_chunk()` 的 `stream.write()` 成功后累加，所以电台被键控、发出去的是静音。历史同症状见 CHANGELOG「发射时「键控了却没有声音」（SDD V2.71）」，1.28.18 应已含该修复 → 按回归排查。
• RX 采集静默停摆：18:42:01 `RX capture stalled: no PCM for 5 s (audio clients=1, FT8 tap=False, recording=False) — reopening the capture stream`，18:42:46 再报 `no PCM for 33 s`；同签名即 SDD V2.79（2026-10-11，W103D 真机首启）记录并修复的「采集接口静默停摆、PyAudio 仍报告流是开的、无异常」，1.28.18 包含该修复，看门狗也确实在重开流（`server.py:_audio_rx_loop` 停滞分支），却仍反复出现。
• 同一时间还有 `RX open failed ([Errno -9993] Illegal combination of I/O devices) — re-initializing PortAudio`（18:59:43 前一次 17:59:43、以及 2026-10-26 21:27:52）与 18:24:37 `RX audio restart failed — capture stays down`：RX 与 TX 用的是同一块 USB 声卡（`USB Audio Device: - (hw:1,0)`，in=2/out=2，ALSA），采集与播放在该设备上互抢流。
• FT8 不可用与产品逻辑无关：`FT8 composition failed — running SSB-only` 后面是 `UnicodeDecodeError: 'utf-8' codec can't decode byte 0x80 in position 0`（scipy → numpy.random._pickle → `.mtrand` 导入期），即盒子 venv 里 numpy/scipy 安装体损坏，启动即回落到 SSB。
• 62 次启动的部分来源是历史配置残留：legacy.log 里 `Radio model: ft710, serial port: [已隐去]`（macOS 端口路径出现在 Linux 盒子上）、server-prev.log 里 `ic7300 [已隐去]` 均 `No such file or directory`；当前配置已改为 ftx1 且 `serial_connected: true`，这一项已不成立。

你要做的

• 先确认发射门禁：/settings →「实验机型的发射」勾选并保存（1.28.17 起才有这张卡片，1.28.18 已修好它的脚本落点），然后在控制页按 F5 刷新一次，按钮才会解禁；此页有红字风险说明，首次发射请接假负载、功率从最小起。
• 日志显示 TX 增益 +14 dB 已在削波（541/960 样本）——把 🎙 Vol（TX 麦克风增益）降到 0 dB 附近再试，削波会让发出去的信号既难听又容易触发保护。
• 若按键后仍无声音/无功率：给电台 USB 线下电（拔线或关电台再开）让 USB 声卡重新枚举，然后重连页面再按一次 PTT；这一步同时修 RX 采集停摆与 PortAudio -9993。
• 若 RX 声音仍然断续或无声：改用一块独立的 USB 声卡，把 RX 与 TX 设备分别选在两块设备上，避免同一块 ALSA 设备（hw:1,0）上采集与播放互抢；不换硬件时每次发射后重新连一次页面也可临时规避。
• FT8 暂时不要用：本机 venv 的 numpy/scipy 已损坏（UnicodeDecodeError），服务启动即回落 SSB；等重装依赖或下次升级后再试。
• 再报一次时请在问题描述里写清现象（听不到声音 / 按 PTT 没有功率 / 频率改了回弹）并注明「按 PTT 前后 1 分钟」，这决定了是查 TX 音频链路还是查 FTX-1 的 CAT 写回。

相关代码：audio_handler.py:feed_tx_audio（`if self._tx_stream is None: return` 与 _tx_peak 同函数，written 只记于 write_tx_chunk）＋ server.py:_feed_tx_from_uplink / _audio_rx_loop 的 RX 停滞重开分支；历史同签名见 CHANGELOG「键控了却没有声音」(V2.71) 与 SDD V2.79（采集接口静默停摆）

FTX-1升级1.28.18遇到切换频段要发射一下PTT不然还是跳回原来频段，APP依然不正常

FTX-1 在**副通道（vfo_b）**上的调谐/记忆调用没落到电台的操作侧：服务端只发 `FB`、不发 `VS`/`FT`，电台自己报的频率一直停在 14.270 MHz；而客户端（APP）还把频率写成 30000/51389 Hz 这类下限值。与 v1.28.16(FP12) 修的「频率改了被拉回」同签名，1.28.18 已含该修复，按回归/未覆盖路径排查。

诊断

• **与历史同签名**：CHANGELOG `[镜像线 v1.28.16 · FP12]` 的触发报告就是 `20261028-131231-0b0f`「FTX-1 控制和瀑布都不正常」，「频率改了被拉回」被判为我们自己的命令形状问题（`VM0;` 判据 + `FA` 写后回读 + `?;` 拒收可见）。1.28.17 的记录里同一客户确认「频率那条修好了（`memory channel selected — sending VM000 before the set` → `vfo_a_freq changed: 29600000 → 29636325` → 轮询确认）」；当前 1.28.18 包含该修复 ⇒ 按回归/未覆盖路径排查。
• **但这次 FP12 的三条自证日志一条都没有**：本窗口内无 `memory channel selected — sending VM000 before the set`、无 `FA/FB write did not take effect`、无 `?;` 拒收 —— 说明不是存储信道判据那条路径，缺的是另一处（见下）。
• **所有频率写入都落在副通道**：状态变更全是 `vfo_b_freq changed …`，调用链为 `server.py:2553/_handle_ws_message`（Memory recall）与 `server.py:2950/_execute_set_command`（set），没有任何一条是客户端改 `vfo_a_freq`。
• **电台自己报的频率没动**：`18:38:20,850 IF poll: vfo_a=14270000 Hz (+0 Hz)`，同一分钟里台账的 `vfo_b_freq` 在 7.06 MHz / 21.4 MHz 之间来回跳 ⇒ 状态与电台显示分叉，就是用户说的「跳回原来频段」。
• **代码缺口**：FTX-1 是真双收，`FA`/`FB` 分别主/副频率，`VS` 选操作侧、`FT` 选发射 VFO（`docs/ftx1-technical-analysis.md` §五）；而 `backends/yaesu/cat_core.py:set_frequency()` 只发 `FA`/`FB`（第 467–480 行），从不发 `VS`/`FT`；server 的 vfo_b 分支只 `radio.update(vfo_b_freq=freq)`（2551–2553、2946–2950），也不切换 active_vfo。按 PTT 才「切过去」与此吻合——PTT 走的是发射路径（FT），不是频率写成功。
• **客户端把频率写到域下限**：日志里出现 `30000`、`38056`、`51475`、`41560`、`51389`、`142597`、`131187`（Hz）。30 kHz 在 FTX-1 的 `FA`/`FB` 合法域内（手册 30000–470000000，`ftx1-technical-analysis.md:325`），所以电台照收不误；服务端的 plausibility 下限也正好是 30000（`server.py:1258-1260`），拦不住 ⇒ APP 侧存在单位/取值错误，一次「切频段」就把频率送进荒区，随后被轮询纠回。
• **次要但真实**：① 配置的设备名对不上——`Configured audio device 'USB Audio CODEC: - (hw:1,0)' not found`，回退到 `USB Audio Device: - (hw:1,0)`；② `RX open failed ([Errno -9993] Illegal combination of I/O devices)` 与 `RX audio restart failed — capture stays down`；③ `TX gain +14 dB is clipping (541/960 samples)`；④ FT8 整块没起来：`FT8 composition failed — running SSB-only`，根因是 venv 里 numpy/scipy 受损（`UnicodeDecodeError: 'utf-8' codec can't decode byte 0x80 … numpy/random/_pickle.py`）。

你要做的

• 先在**网页端**验证归位：把当前 VFO 切换回 A（界面上的 A/B 键），再做频段切换与记忆信道调用。A 通道是 FP12 已修好的路径，若 A 正常、B 仍「跳回」，即可确认问题只在副通道。
• 工作期间**不要用 APP 切频段**，只用网页端——日志显示 APP 会下发 30000 / 51389 Hz 这类值（30 kHz），电台接受但显示上等于换了个荒区，随后轮询又把你拉回去。
• 如果一定要在 B 通道上工作：先在**电台面板**（或网页端的 VFO 切换键）把操作侧/发射 VFO 明确切到 B，再用网页调频率/记忆信道。这样绕开「服务端只写 FB、不切 VS/FT」这个缺口，不必靠按 PTT 让它生效。
• 不要再用「按一下 PTT 把频段顶过去」这个土办法——那只是走了发射路径，发射频谱/功率未必对应你以为的频段；改用第 3 步显式切换。
• 音频顺手压一压：☰ 菜单里把 TX 麦克风增益从 +14 dB 降到 0…+6 dB（日志显示 541/960 样本已削波），RX 增益从 +23 dB 降到 +10 以内；若再出现 `RX audio restart failed — capture stays down`，把电台的 USB 线拔插一次（PortAudio 已自动重建一次仍失败）。
• FT8 现在是整块不可用（venv 内 scipy/numpy 损坏，不是配置问题）：重跑一次**整包**升级/重装（热修补丁只覆盖少量文件，不重建 venv），不要只发热修。
• 再抓一个诊断包好定案：在网页端先「切到 A 做一次频段切换」，再「切到 B 做一次」，两份日志里有无 `memory channel selected — sending VM000` 与 `FA/FB write did not take effect` 就能区分是副通道 VS/FT 缺口还是客户端取值问题。

相关代码：backends/yaesu/cat_core.py:set_frequency（只发 FA/FB，从不发 VS/FT，副通道写入不改变电台操作侧）；server.py:_handle_ws_message 的 memRecall 分支（2551-2553）与 _execute_set_command 的 vfo_b_freq 分支（2946-2950）（仅 radio.update(vfo_b_freq=…)，不切 active_vfo/VS）

FTX-1升级到1.28.17的问题

1.28.17 升级本身没有失败：发射不成是盒子侧 USB 音频/CAT 同时掉线（换线/换口即可），频谱跨度报错是 FTX-1 后端缺 `set_scope_span` 的代码缺口，FT8 起不来是 venv 里 numpy/scipy 装坏了。

诊断

• TX 失败的现场是「没有输出声卡」，不是后端/模型问题：`No audio output device found for TX` 紧跟 `PTT: TX audio stream failed — unkeying radio`，`_find_tx_device()` 只有在当前 PortAudio 设备表里连一个带输出通道的设备都找不到时才返回 None（`audio_handler.py:832`）。
• 同一时刻 FTX-1 的 CAT 口也在消失：`Serial write error for 'FA': (5, 'Input/output error')` → `CAT port [已隐去] is gone (No such file…)`，18:25:06 起反复 gone / 18:26:13 restored。CAT 与 USB 声卡走同一根 USB，声卡从设备表里消失与该现象一致（USB 掉线/重枚举，多见于线材、hub 或供电不足）。
• 音频恢复路径本版只成功了一半：`RX open failed ([Errno -9993] Illegal combination of I/O devices) — re-initializing PortAudio`（17:59:43）之后 18:24:37 记录 `RX audio restart failed — capture stays down`；恢复逻辑存在（`audio_handler._reinit_pyaudio`，先关两条活流再重建），但设备不在时无法恢复。
• env.json 佐证：`audio.devices.rx/tx` 均为空、`configured_rx/tx = "USB Audio Device: - (hw:1,0)"`，`tx_stats.written=14 / queue_drops=16`；前一日 11:00 的日志里同一设备是健康枚举的（`[0] USB Audio Device: - (hw:1,0) (host=ALSA, in=2, out=2)`），说明是运行期掉设备而非升级后不认设备。
• 频谱跨度报错是真实代码缺口：`Command error (scope_span=4): 'YaesuCatController' object has no attribute 'set_scope_span'` 反复出现。`server.py:_handle_ws_message` 的 `scope_span` 分支无条件 `await cat.set_scope_span(v)`，而 `backends/yaesu/backend.py:_make_delegate` 把基类抽象方法一律转发到 `_cat`，`YaesuCatController` 里没有该方法（`backends/yaesu/` 全无 `set_scope_span`），所以每次点跨度/回放设置就抛 AttributeError。FTX-1 的 profile 是 `scope_type="none"` / `scope_spans={}`（`backends/yaesu/backend.py:67-68`），本不该收到这条命令。
• 频谱本身属预期：`Spectrum broadcast active: S-meter fallback, 1701 bytes/frame`——FTX-1 无 CAT 波形源（scope_type=none），由 S 表合成，不是缺陷。
• FT8 不可用是 venv 损坏，非升级回归：`FT8 composition failed — running SSB-only`，随后 `UnicodeDecodeError: 'utf-8' codec can't decode byte 0x80 in position 0`，栈点是 `numpy/random/_pickle.py → from .mtrand import RandomState`（scipy→numpy 二进制与 Python 3.11 不匹配/文件损坏）。历史检索（`CHANGELOG.md`、`SDD/14-version-history.md` 的 `scope_span` / 无输出声卡签名）无同签名记录，不能判为已知缺陷回归。
• TX 门禁按设计工作：`Yaesu FTX-1F is not hardware-verified — transmit refused. Set MRRC_ALLOW_UNVERIFIED_TX=1`；而 env.json 里 `tx_gated: false`，说明已开启过，本次 TX 失败与门禁无关。

你要做的

• 先处理 USB 掉线：把 FTX-1 与盒子的 USB 线换成已知良好的数据线，直连盒子（不要经无源 hub），换一个 USB 口；电台用稳压电源，避免发射时 USB 供电跌落。
• 改完重启服务，确认启动日志里同时出现 `Using radio USB audio output: [0] …`（或 `Using radio USB audio device`）与 `RX audio started: … actual=48000Hz`；只有 RX 起来而 TX 那句没出现时，先按上一条查线，别急着重装。
• 仍无 TX 声卡时显式指定设备：把 env 里的 `MRRC_AUDIO_TX_DEVICE` 设为启动日志设备列表中的索引（本次是 `0` = `USB Audio Device: - (hw:1,0)`），保存后重启。
• FT8：修复 venv 的二进制不匹配——在盒子 `/opt/mrrc_modern` 下 `venv/bin/pip install --force-reinstall numpy scipy`（或重跑一次安装/`mrrc-update` 让依赖按镜像清单重建），重启后日志应不再出现 `FT8 composition failed`；在此之前 SSB 全部功能不受影响。
• 频谱跨度报错可忽略：FTX-1 没有频谱源，界面上的「跨度/速度」只对 FT-710/IC-7300 有意义；在修好前端隐藏该控件之前，别去点它（命令行回放旧设置时会打一行 error，不影响收发）。
• 发射前确认 ☰ 菜单/设置页里的「实验机型的发射」已打开（即 `MRRC_ALLOW_UNVERIFIED_TX=1`），否则会看到 `transmit refused`。

相关代码：backends/yaesu/backend.py:_make_delegate（无条件转发到 backends/yaesu/cat_core.py:YaesuCatController，该类没有 set_scope_span）+ server.py:_handle_ws_message 的 scope_span 分支（应像 scope_type=none 一样跳过）；测试缺口：backends/yaesu 的 test_every_abstract_method_is_implemented 只查基类抽象集，查不到这种「有名字但目标不存在」的转发

FTX-1升级到1.28.17

升级本身没坏：FTX-1 的发射被「未验证机型」门禁挡着（1.28.17 正是为无 SSH 的盒子新增了设置页开关，开关还没打开），另有三件独立的环境/设置问题（FT8 因 venv 内 numpy 导入失败停用、音频增益 +30/+3 dB 削波、USB CAT 口掉线重枚举），瀑布是 S 表合成而非真实频谱属该机型限制。

诊断

• 发射被拒不是 1.28.17 回归，而是 AD-019 的未验证机型门禁：日志 25 条 `backends.yaesu.backend: Yaesu FTX-1F is not hardware-verified — transmit refused. Set MRRC_ALLOW_UNVERIFIED_TX=1 ...`，最后一次在 17:59:50,083（本次启动后），env.json 同时是 `"model":"ftx1"`, `"tx_gated": true`。FTX-1 的 profile 是 `verified=False`（backends/yaesu/backend.py::_tx_allowed 只在 config.ALLOW_UNVERIFIED_TX 为真时放行）。
• 用户按了 PTT 但其实从未键控：`TX session: frames=513 fed=513 decode_fail=0 written=0 write_err=0 queue_drops=0 peak=0%`（18:00–18:01 连续多条）—— 音频帧进了上行与增益环节（同段有 TX gain 削波警告），声卡一个字节都没写、功率表 0%，与「门禁拒绝 set_ptt」完全一致，而不是 TX 音频链路故障。
• 门禁有界面不需要 SSH：CHANGELOG 顶部 `[镜像线 v1.28.17 · FP13]` 明写「卡住他的只剩发射门禁，而自动答复给出的办法还是 vi …/mrrc.env + systemctl restart——对一个没有 SSH 的盒子主人，那等于没有这条路」，本版新增 设置页 →「实验机型的发射」（勾选 + 必须读完的 confirm、立即生效、控制界面需 F5 刷新）。这说明用户升级到 1.28.17 后还没用这个入口。
• FT8 不可用是 venv 里的 numpy/scipy 导入失败，且与电台、与本次升级无关：每个启动都 `FT8 composition failed — running SSB-only`，栈为 `ft8/engine/audio_rx.py:21 import scipy.signal` → … → `numpy/random/_pickle.py:2 from .mtrand import RandomState` → `UnicodeDecodeError: 'utf-8' codec can't decode byte 0x80 in position 0`；同一段栈在 2026-10-27 10:44（`logs/server-prev.log`，当时机型是 ic7300、端口 [已隐去]）逐字出现，说明是盒子上的 Python 依赖被装坏/装了一半，早于这次换 FTX-1。
• 历史同点可对照：CHANGELOG `[镜像线 v1.28.7 · FP3]` 记录过同一行 `ft8/engine/audio_rx.py:21 import scipy.signal` 让服务 SEGV 重启 97 次（scipy 1.17.1 aarch64 wheel 在 Cortex-A53 上崩），修法是 requirements.txt 锁 `scipy>=1.12,<1.15`；本机异常类型不同（UnicodeDecodeError 在 numpy.random._pickle），更像依赖文件损坏/未装完，而 `linux/mrrc_update.sh:66` 每次升级都会 `pip install --upgrade -q -r requirements.txt`。
• 音频增益把信号削到底：`audio levels: RX gain +30 dB is clipping the signal (163203/2889600 …)`、`TX gain +3 dB is clipping the signal (339/960 …)`，且 server-prev.log 记着 `Audio levels from file: TX mic +25.0 dB, RX +23.0 dB` / 本次 `TX mic +3.0 dB, RX +30.0 dB`——这是盒子级增益设得太高，不是设备缺陷；RX +30 dB 下 `RX audio broadcast active … peak=5.4%` 也说明靠增益补信号。
• USB 链路掉过一次：17:59:40 `Serial read error for 'SM0': [Errno 5] Input/output error` → `Serial write error for 'FB'` → `CAT port [已隐去] is gone … check the USB cable/hub or the port name`，紧接着 `RX capture stalled: no PCM for 3 s/5 s` 并 `-9993 Illegal combination of I/O devices` 重建 PortAudio；重启后 17:59:49 端口打开、17:59:55 采音恢复（`actual=44100Hz, channels=1`），属 USB 重枚举（供电/线材/HUB）一类环境事件。
• 瀑布「不正常」是该机型的既有事实而非升级引入：env.json `"scope_type": "none"`，日志 `Spectrum broadcast active: S-meter fallback, 1701 bytes/frame`；backends/yaesu/backend.py 的 capabilities 里写死 `scope_type="none" # no documented CAT waveform`，SDD/14 也记着 Yaesu ASCII-CAT 家族（FTDX10/101D/MP/FTX-1F/FT-891）没有扫频协议、只显示合成频谱。

你要做的

• 打开设置页（同一台盒子的 /settings，局域网即可）→「电台」之后的「实验机型的发射」卡片：勾选风险确认并提交（会再要一次确认），立刻生效、不用重启；然后回到控制界面按 F5 刷新一次，PTT/CQ 才会解禁。首次发射按卡片红框要求做：接假负载、从最小功率起步、人守在旁边；验证前别挂一键 CQ / FT8 自动呼叫。
• 顺手把增益降下来：☰ 菜单里把 RX 那一档从 +30 dB 调到 0 dB 左右、TX mic 从 +3 dB 调到 0 dB（或按实际底噪微调），直到日志里不再出现 `audio levels: … is clipping the signal`。+30 dB 削波会让收音频段发闷、TX 削波会造成邻频飞溅。
• USB 稳定性：把电台的 USB 线直插盒子（不经 HUB）、换一根短一点的优质线；插好后确认 `Radio model: ftx1, serial port: [已隐去]` 这条日志里的端口号没变（换 USB 口会让 ttyUSB1 变成 ttyUSB0/ttyUSB2，需要在「连接设置」里重选端口）。
• FT8 想用的话：再执行一次升级（盒子页面的升级入口即可，`mrrc-update` 会重跑 `pip install --upgrade -r requirements.txt`，把 venv 里的 scipy/numpy 重装到锁定版本），重启后看日志里 `FT8 REST/WS routes mounted` 之后不再出现 `FT8 composition failed — running SSB-only` 就恢复了；若还报同一个 `UnicodeDecodeError`，重新发一个 🐞 诊断包（我们据此按依赖装坏排查，而不是当 FT8 功能缺陷）。
• 瀑布不用折腾：FTX-1 的 CAT 没有扫频命令，界面显示的是按 S 表合成的频谱（`scope_type: none`），换版本、换浏览器都不会变成真实瀑布。要看频谱请直接用 FT-710/IC-7300 那条路，或等 FTX-1 有 CAT 扫频能力。

相关代码：backends/yaesu/backend.py::_tx_allowed（门禁判定，行为正确）；ft8/engine/audio_rx.py:21（历史同点，本次为 venv 依赖损坏，非代码缺陷）

FTX-1升级到1.28.17

升级本身成功（1.28.17/FP13 已跑起来，CAT 已连上、记忆信道召回归位）；真正卡住的是 FTX-1 的「未验证机型」发射门禁——它在 1.28.17 里已经可以从设置页打开，不必再改 env/重启；FT8 不可用是 venv 里 numpy/scipy 文件损坏（升级前就存在），另有音频电平被设到削波。

诊断

• 发射被拒是设计门禁，不是升级缺陷：`backends.yaesu.backend: Yaesu FTX-1F is not hardware-verified — transmit refused. Set MRRC_ALLOW_UNVERIFIED_TX=1 and restart…` 共 25 条，env.json 同步为 `"model":"ftx1", "tx_gated":true, "serial_connected":true`。实现在 backends/yaesu/backend.py:34 `_tx_gate_warn()`（config.ALLOW_UNVERIFIED_TX 为假且 profile.verified 为假 → 拒发），与 AD-019 / SDD V2.72「未验证机型默认只收不发」一致。
• 这正是 1.28.17（FP13）解决的场景：CHANGELOG 顶层条目写明「卡住他的只剩发射门禁，而自动答复给出的办法还是 vi /opt/mrrc_modern/env/mrrc.env 加一行…对一个没有 SSH 的盒子主人，那等于没有这条路」，于是新增设置页卡片。代码在 server.py:8597/8605（GET/POST `/api/box/unverified-tx`，POST 需 `confirm: "allow-unverified-tx"`）与 static/settings.html:938/963，**立即生效、无需重启**，改完 F5 刷新控制页即解禁。因此当前版本已含该修复，无需等新版本，也不必再去手改 env。
• 「键控了却没声音」是门禁的直接后果：`TX session: frames=86 fed=86 decode_fail=0 written=0 write_err=0 queue_drops=0 peak=0%`——上行音频正常进来、队列不丢，只是 PTT 从未按下，所以一个字节都没写进电台。历史 V2.71 的所有权缺陷签名是 `frames=0 fed=0 non_owner_drops>0`，本次不是。
• 升级没有把 FTX-1 的频率/控制打回原形：`18:00:25 Memory recall: freq=28074000 mode=USB` → `vfo_a_freq changed: 29600000 → 28074000` → `18:00:31 IF poll: vfo_a=14270000 Hz`，回读与设定一致、没有被拉回，说明 FP12 的 `VM000;`（退出存储信道）修复在本包内生效。
• FT8 整体不可用属环境（venv 里的 Python 安装文件已损坏），并且**早于这次升级**：server-prev.log（10:44:43）与 server.log（17:59:50）各有一份完全相同的 `FT8 composition failed — running SSB-only` + Traceback，末端 `UnicodeDecodeError: 'utf-8' codec can't decode byte 0x80 in position 0: invalid start byte`，抛在 `numpy/random/_pickle.py:2 from .mtrand import RandomState`。热修包只含 server.py/static/backends 文件，动不到 numpy/scipy，所以与本次升级无关，但也确实是本机需要修的。
• 频谱走 S 表合成是这台机器的限制：`Spectrum broadcast active: S-meter fallback, 1701 bytes/frame`，env.json `"scope_type":"none"`；FTX-1 没有 CAT 波形协议，SDD/14 与 CHANGELOG v1.28.16 均写明「这一条不会变」，不是故障。
• 音频电平设得过高正在削波：`RX gain +30 dB is clipping the signal (616/3840 samples…；totals 163203/2889600)`、`TX gain +3 dB is clipping the signal (339/960 samples…)`。这是 audio_levels 的告警而非设备故障，但削波的 RX 听起来像盒子自己的失真、TX 会溅射邻道。
• 环境类、不需处置的两条：`CAT port [已隐去] is gone ([Errno 2] No such file…)` 之后 17:59:49 已自行重连成功（USB 串口桥重枚举，与线缆/供电相关）；`RX capture stalled: no PCM for 3 s … reopening the capture stream` 之后紧跟 `RX audio started … actual=44100Hz` 与 `RX audio broadcast active: Opus, 1 clients, peak=5.4%`，是既有的 TX→RX 重开流自愈路径。

你要做的

• 开发射：浏览器打开盒子的设置页 `http://<盒子IP>:8888/settings`，找到「实验机型的发射」卡片 → 勾选并读完弹窗确认 → 保存（立即生效，不用重启）；随后回到控制页按 F5 刷新一次，PTT/调谐按钮才解禁。若页面打不开，说明这条热修没装上，重跑一次升级到 1.28.17 整包即可。
• 开之前先按规矩来：FTX-1 的发射命令表没有在真机上验证过，第一次接假负载、功率调到最小、人守在旁边；验证通过前不要挂一键 CQ、也不要开 FT8 自动呼叫。注意这是**全盒子**开关，换机型不会自动关。
• 压掉削波：☰ 菜单里两个 dB 滑块，把 RX 从 +30 dB 先降到 +10 dB 左右、TX 从 +3 dB 降到 0 dB，收听到语音清晰、日志里不再出现 `is clipping the signal` 为止（RX 默认 0 dB 就足够，+30 dB 是把底噪一起放大）。
• 修 FT8：有 SSH 就在盒子上跑 `cd /opt/mrrc_modern && ./venv/bin/pip install --force-reinstall "numpy" "scipy>=1.12,<1.15"` 后 `sudo systemctl restart mrrc-modern`，再重启一次确认日志里不再有 `FT8 composition failed`；没有 SSH 的话用 1.28.17 整包重刷/重装（会重建 venv）。若重装后仍报同一个 UnicodeDecodeError，多半是 eMMC/SD 有坏块，需要换盘重刷。
• 顺手稳一下串口：换一条短一点的优质 USB 线，尽量直插盒子而不是无源 HUB；升级过程中不要插拔电台 USB，避免 [已隐去] 中途消失导致升级后第一次启动 CAT 起不来。
• 频谱不用担心：FTX-1 没有 CAT 波形，界面就是 S 表合成，不会因为升级而变化。

相关代码：无产品缺陷。仅一处文案可改进：backends/yaesu/backend.py:_tx_gate_warn() 仍提示「Set MRRC_ALLOW_UNVERIFIED_TX=1 and restart」并指 _diag_yaesu.py，未指向 1.28.17 新增的 /settings「实验机型的发射」卡片（server.py:api_unverified_tx_set / static/settings.html:loadTxGate），对无 SSH 的盒子主人是误导路径

FTX-1升级了1.28.16

这份包里的三件事分别是：FTX-1 属未验证机型，发射门禁按设计拒绝（不是升级引入的缺陷）；FT8 因 venv 里 numpy/scipy 文件损坏整体不可用（早于 1.28.16 就存在）；瀑布走 S 表合成是 Yaesu ASCII-CAT 家族的固有限制。1.28.16（FP12）本次修的 FTX-1 命令形状问题在日志里没有复现迹象。

诊断

• 发射被拒是设计上的门禁，不是升级带来的回归：`2026-10-28 17:40:42,374 [WARNING] backends.yaesu.backend: Yaesu FTX-1F is not hardware-verified — transmit refused. Set MRRC_ALLOW_UNVERIFIED_TX=1 and restart…`，env.json 同步写着 `"model": "ftx1"`, `"tx_gated": true`, `"serial_connected": true`。门禁实现在 `backends/yaesu/backend.py:79` 的 `_tx_allowed()`（`config.ALLOW_UNVERIFIED_TX` 为假且 `profile.verified` 为假 → False），与 SDD V2.72 / AD-019「未验证机型默认只收不发」一致。
• 因此这次发射「键控了却没有声音」是门禁的直接后果，不是上行所有权缺陷（历史 V2.71 的签名是 `frames=0 fed=0 non_owner_drops>0`，本次是 `frames=59 fed=59 … written=0 … peak=0%`，音频进来了但没有写进电台）。
• FT8 不可用是 venv 里的 Python 文件损坏，且**早于本次升级**：`2026-10-27 10:44:43,536 [ERROR] mrrc: FT8 composition failed — running SSB-only` 与同一份 Traceback 已经出现在 server-prev.log（升级前那次启动），末尾是 `UnicodeDecodeError: 'utf-8' codec can't decode byte 0x80 in position 0: invalid start byte`，抛在 `numpy/random/_pickle.py:2 from .mtrand import RandomState` —— 即导入 numpy 时某个源文件在磁盘上已不是可解码的文本（首字节 0x80），典型的安装文件损坏/被二进制内容覆盖。1.28.16 的热修包只有 24,148 B、仅含 `backends/yaesu/` 三个文件（见 CHANGELOG 顶层条目），动不到 numpy/scipy，所以不是升级造成的。
• 瀑布「不正常」是这台机器的限制而非缺陷：`Spectrum broadcast active: S-meter fallback, 1701 bytes/frame`，SDD/14-version-history.md:155 明确写 Yaesu ASCII-CAT 家族（含 FTX-1F）没有扫频协议，只能用 S 表高斯合成频谱 —— 这一条在 CHANGELOG v1.28.16 里也写了「瀑布是电台的限制，这一条不会变」。
• RX 采集在启动/切回接收时短暂停流是既有自愈路径：`2026-10-28 17:40:12,191 [WARNING] mrrc: RX capture stalled: no PCM for 3 s … reopening the capture stream` 紧接着 `RX audio started: [0] USB Audio Device: - (hw:1,0) … actual=44100Hz`，之后 17:40:46 又自愈一次并打出 `RX audio broadcast active: Opus, 1 clients, peak=3.4%`，属 audio_handler 的 TX→RX 重开流逻辑，不需要处置。
• FP12（1.28.16）要修的现象本次没有复现：日志里频率设置走了新路径并生效（`memory channel selected — sending VM000 before the set` → `vfo_a_freq changed: 29600000 → 29636325` → 轮询确认 `IF poll: vfo_a=29636325 Hz`），也没有出现「写后回读不符」或 `?;` 拒收的 WARNING，说明升级后 FTX-1 的控制面在工作。
• 另有一处与本问题无关但值得提的旧痕迹：legacy.log 里 2026-10-26 16:38 那次是 `Radio model: ft710, serial port: [已隐去]`（macOS 路径出现在这台 Linux 盒子上）且端口不存在，说明 env 文件曾被别的机器的配置覆盖过；当前这次启动已正确读到 `ftx1` + `[已隐去]` 并 `CAT port open at 38400 baud`。

你要做的

• 要发信（自担风险，FTX-1F 未做真机验证）：编辑 `/opt/mrrc_modern/env/mrrc.env`，加一行 `MRRC_ALLOW_UNVERIFIED_TX=1`（一个键只能出现一次，改已有那行而不是追加），保存后重启服务：`sudo systemctl restart mrrc-modern`。重启日志应不再出现 `transmit refused`。
• 按 CHANGELOG 的建议，开信之前先跑一次只读自检 `python3 _diag_yaesu.py`（在 `/opt/mrrc_modern` 下、用 venv 的 python：`/opt/mrrc_modern/venv/bin/python _diag_yaesu.py`），确认 `ID;`、频率、模式读回与手册一致，再把门禁打开。
• 修复 FT8（顺手也修掉那段 Traceback）：在盒子上执行 `/opt/mrrc_modern/venv/bin/pip install --no-cache-dir --force-reinstall numpy scipy`，然后 `/opt/mrrc_modern/venv/bin/python -c "import numpy, scipy.signal; print(numpy.__version__)"` 应能无报错打印版本；再重启服务，日志里 `FT8 composition failed — running SSB-only` 应当消失。如果该命令报权限或网络错误，先 `sudo -i` 再执行，或改用整包重装（`mrrc-update` 拉 1.28.16 整包而不是热修）。
• 瀑布按 S 表合成是预期行为，不用再折腾：FTX-1 的 CAT 没有扫频命令，界面上的瀑布只是 S 表推出来的形状；真实频谱要另接 SDR（`MRRC_SDR_PASSWORD` 打开 `/sdr` 页）或用 FT-710/IC-7300 这类自带波形输出的机型。
• 「点 PTT 有反应但对方收不到」以后先看两行日志区分原因：出现 `transmit refused` 就是门禁（本条），出现 `TX audio ownership … owner=False` / `non_owner_drops>0` 才是上行所有权问题（关掉多余的标签页即可）。
• 若升级后仍有具体某项不正常（哪个控件、哪个按键、哪个页面），请在下次上报里写明现象与操作步骤 —— 本次问题描述只写了「FTX-1升级了1.28.16」，无法据此判断是否还有第二类问题。

相关代码：backends/yaesu/backend.py:YaesuBackend._tx_allowed（门禁为设计行为，非缺陷）；FT8 失败点在 ft8/engine/audio_rx.py:21 的 `import scipy.signal` 之前，即 venv 里的 numpy 安装文件损坏，无需改代码

这个是YAESU FTX-1控制和瀑布都不正常

瀑布「不正常」是 FTX-1 的设计限制（该机没有 CAT 波形协议，界面只能走 S 表合成）；发射被未验证机型门禁挡住属预期；但「频率/控制改了不生效、轮询又被拉回 29600000」与本仓已记录且仍未修的 FTX-1 CAT 不符项（附录 C 20 项，含 VM）同源，需按回归/未修缺陷排查。

诊断

• 瀑布：`backends/yaesu/backend.py` 对全 Yaesu 族硬写 `scope_type="none"`（注释「no documented CAT waveform (spec §2 D4)」），日志 `Spectrum broadcast active: S-meter fallback, 1701 bytes/frame` 正是这条路径。docs/ftx1-technical-analysis.md §13 明确写「**没有频谱**｜FT-1 没有 CAT 波形协议（scope_type="none"）｜不存在可开的东西；界面走 S 表合成，这是正确行为」，v1.16.0 CHANGELOG 亦写明「没有真机频谱数据源…UI 继续用既有的 S 表合成频谱，不伪造瀑布数据」。⇒ 属设计如此，不是回归。
• 发射：15 条 `Yaesu FTX-1F is not hardware-verified — transmit refused. Set MRRC_ALLOW_UNVERIFIED_TX=1…`，env.json `"tx_gated": true`，来源 `backends/yaesu/backend.py:34` 的 `_tx_gate_warn()`。docs/ftx1 §13 表格同样列为「设计如此」。
• 控制不生效：13:05:16–13:05:31 连续 `vfo_a_freq changed: 29600000 → 29570556/29537810/…`（caller `server.py:2931/_execute_set_command`）后，13:05:19,915 与 13:05:21,473 两次 `… → 29600000`（caller `poll_scheduler.py:524/_poll_slow`、`poll_scheduler.py:217/_poll_if`），13:06:15 `IF poll: vfo_a=29600000 Hz (+0 Hz)` ⇒ 读（IF）正常、写没有落到电台上，随后被轮询回读覆盖。
• 同源历史：docs/ftx1-technical-analysis.md §13「仍未修：附录 C 的 20 项 CAT 不符」列出 12 条格式/语义错（`MG` `PL` `AO` `RL` `KP` `RA` `PC` `AC` `PR` `ML` `PA` **`VM`**）+ 6 条机型不存在，后果原文「机型选对了，仍会有『某个开关点了没反应』这类症状」。日志 13:09:17 `Memory recall: freq=29600000 mode=FM vfo=A` 说明电台当时在存储信道上，而 FTX-1 退出存储信道依赖 `VM000;`（cat_core 注释：Hamlib `ftx1.c:881`），`VM` 正在不符清单里 ⇒ 与「写频率不回读」吻合，属未修缺陷而非环境。
• 注意：v1.28.2 修过的 FTX-1 缺陷是启动器白名单把机型写回 `ft710`（CHANGELOG「启动器：机型白名单来自注册表（FT-891 / FTX-1 都是受害者）」）。本包 env.json `radio.model="ftx1"`、`serial_connected: true`，日志 `Radio model:` 未出现 ft710 ⇒ 该缺陷未复发，可按回归排除。
• 环境（不属产品缺陷）：`Configured audio device 'USB Audio CODEC: - (hw:1,0)' not found` 而实际只有 `[0] USB Audio Device: - (hw:1,0)`；`RX capture stalled: no PCM for 5 s / 6 s … reopening the capture stream` 反复出现，实际采样率 44100（日志 `actual=44100Hz, channels=1) (resampled to 48k for Opus)`）。
• 环境：`FT8 composition failed — running SSB-only` 的 Traceback 是 venv 内 numpy/scipy 导入炸掉（`numpy/random/_pickle.py … UnicodeDecodeError: 'utf-8' codec can't decode byte 0x80 in position 0`），即 site-packages 文件损坏，与 SSB 控制/瀑布无关。

你要做的

• 瀑布：FTX-1 本身不提供 CAT 波形，界面曲线来自 S 表合成，没有可打开的开关。要真实瀑布请用 FT-710 / IC-7300 这类有线波形输出的机型；用 FTX-1 时把瀑布当「S 表趋势图」看。
• 发射：确认要发射时，在 `/opt/mrrc_modern/env/mrrc.env`（或网页 ☰ → 连接设置）加一行 `MRRC_ALLOW_UNVERIFIED_TX=1`，保存并重启服务；建议先在盒子上跑一次 `_diag_yaesu.py` 核对 `ID;`/`FA;` 回读再开。
• 控制不生效：先在电台面板上按 VFO/MEM 把电台从存储信道切到 VFO 模式（日志显示当时是 `Memory recall … mode=FM` 的存储信道），再在网页上调频率，然后等一次轮询看频率是否被拉回；如果一出存储信道网页调频率就正常，就是已知的 FTX-1 CAT 不符项在作用。
• 控制仍不回读时：不要靠网页反复拉频率滑块（每次写入都失败、还会被轮询覆盖），改用电台面板直接设频；同时用 ☰ → 🐞 重新上传一个诊断包（这次请在上传前先在网页上改动一次频率/模式，让日志里留下该次 CAT 交换），维护者需要 `ID;`/`FA;` 收发原文才能定位到具体命令。
• 音频（现在 RX 会周期性断音）：在 ☰ → 连接设置把 RX/TX 音频设备显式选成 `[0] USB Audio Device: - (hw:1,0)`（配置里残留的是 `USB Audio CODEC` 这个名字，与实际设备名不一致）；设备名固定后 `RX capture stalled … reopening` 循环应消失。
• FT8 现在不可用但不必急：venv 里 numpy/scipy 已损坏（`UnicodeDecodeError`），跑一次「一键升级 / mrrc-update」重建依赖即可恢复；不修也不影响 SSB 收发。

相关代码：backends/yaesu/cat_core.py:YaesuCatController（VM000 记忆信道退出步与附录 C 不符命令表）；能力表侧 backends/yaesu/yaesu_profiles.py（FTX-1 profile 的 att_steps / has_vd_id_meters），核对依据 docs/ftx1-technical-analysis.md §12 + 附录 C

现在是IC-7300.你深入分析下7300的适配情况

IC-7300 的 FT8 模式在本版本一定失败：FT8 的电台适配层（ft8/platform/cat.py）把 FT-710 的滤波宽度表和模式寄存器表硬编码在里面，传给 IC-7300 后端的是无效的 FIL 槽位 18（IC-7300 只接受 1–3），因此每次进入 FT8 都被拒并回滚到 SSB —— 这是产品缺陷，不是设备或使用问题。

诊断

• FT8 起不来的直接原因在日志里说得非常明确：`server.py:3616` 调 `platform_rig.set_filter_width(3000)`，`ft8/platform/cat.py:83` 抛 `RigError: CAT: set_filter_width(3000 Hz) refused`，两次（22:07:19、22:07:28）完全一致，随后 `FT8 engine stopped` 并 `rolling back to SSB`。
• 适配层的单位错了：`PlatformRig.set_filter_width(hz)` 用 `min(FILTER_WIDTHS_NARROW, key=abs(row[1]-hz))[0]` 把 3000 Hz 换算成槽位号，而 `backends/ft710/config_ft710.py` 的窄带表里 `(18, 3000)` ⇒ 它发出去的是索引 18。
• IC-7300 侧只认 1–3：`backends/ic7300/civ_controller.py:804-812` 的 `set_filter_width(index)` 第一句就是 `if index not in (1, 2, 3): return False`（FIL1–FIL3），18 直接返回 False ⇒ 适配层抛异常。同一实例上人工点滤波器按钮用的是合法槽位，所以成功（`Filter set result: ok=True index=2` / `Filter read-back: index=2`）。
• 同一适配层还有第二处 FT-710 耦合，只是这次没轮到它报错：`set_mode` 用 `FT710_MODE_NUM`（`LSB=0x01, USB=0x02, DATA-U=0x0C`）写模式号，`get_mode` 也用同一张表回读。日志里 `set_mode` 没抛异常就走到滤波那一步，说明模式号也是按 FT-710 的表发出去的，与 CI-V 机型的模式码不是同一套。
• 结论是这个版本里「FT8 工作模式」实际只支持 FT-710：整个 `ft8/platform/cat.py` 只 import 了 `backends.ft710.config_ft710`，没有任何按机型取表的分支。历史检索（CHANGELOG.md + SDD/14）没有「FT8 在 Icom 机型上滤波被拒」的同签名记录，也说明这条路径从未在 CI-V 机型上验证过（env 里 `radio.model=ic7300`、`tx_gated=false` 都已正常识别，串口与音频链路本身是通的）。
• 与本问题无关但值得顺手处理的两条现场事实：① `RX gain +24 dB is clipping the signal`（22:05:40 起十余次，累计 476706/7238400 样本削顶）—— 盒子级 RX 增益设得过高，会把底噪压成硬削波，听起来「像盒子在响」；② 上一个日志（10-23，server-prev.log）里 `CI-V scope queue full; dropped oldest segment (drops=5435300, max=44)` 持续刷屏，是另一会话的频谱队列积压，不代表当前这次 FT8 失败。
• 音频链路本身正常：`RX audio started … actual=48000Hz, channels=1 (native 48k Opus rate)`、`RX audio broadcast active: Opus, 1 clients`；`tx_stats` 全 0 只是没发过射。

你要做的

• IC-7300 上暂时不要用「FT8 工作模式」：这台机器上它每次都会被拒并回滚（日志两次一模一样的 Traceback），反复点只会刷日志不会成功。
• FT8 的替代用法：在 IC-7300 上把模式设成 USB-D/DATA-U、带宽 3 kHz（面板或本界面普通操作页），FT8 解码与发射交给直连电台的电脑 + WSJT-X（电台的 USB 声卡本来就同时被两边看到）；本盒子的 FT8 页面等修复后再用。
• 要立刻用盒子内置 FT8，就换成 FT-710 等已实测机型（FT8 适配层只覆盖 FT-710 那套表）。
• 顺手把 RX 增益降下来：☰ 菜单 → 音频电平，把 RX 从 +24 dB 调到 0 ~ +6 dB（日志里持续 `RX gain +24 dB is clipping the signal`，削顶会掩盖弱信号，对 FT8 解码尤其致命）；TX mic 也建议按实际回放从 +8 dB 往下调。
• 下次上报时把「进入 FT8 的时间和是否只点一次」写进问题描述，并保持 `logs/server.log` 同包上传，便于确认是否还有别的机型相关分支（例如模式号读写）也跟着失败。

相关代码：ft8/platform/cat.py:PlatformRig.set_filter_width（硬编码 FILTER_WIDTHS_NARROW 把 Hz 换成 FT-710 槽位，3000Hz→18）与 PlatformRig.set_mode/get_mode（硬编码 FT710_MODE_NUM）→ backends/ic7300/civ_controller.py:set_filter_width（只接受 FIL 1–3，返回 False）

中兴W103D 1.28.7无法控制IC7300

IC-7300 的 CAT 串口在配置里是空的（MRRC_SERIAL_PORT=""）——盒子根本没打开任何串口，所以「无法控制」；换机型时的既有设计会清空端口，需要重新指定。

诊断

• 配置里的串口是空字符串，服务端连不开口：server.log `Radio model: ic7300, serial port: @ 115200 baud`（注意 `serial port:` 后为空）、`ic7300.civ: Opening CI-V port at 115200 baud`、`Failed to connect to : [Errno 2] could not open port : [Errno 2] No such file or directory: ''`、`Check serial port: `（空）—— 这是唯一的连接失败原因，与电台型号/固件无关。
• 因此后台从未与电台通过话：`WS fullState push: serial_connected=False clients=1`，env.json `"serial_connected": false`、`"model": "ic7300"`；频谱只剩合成 S 表（`Spectrum broadcast active: S-meter fallback`）且 `CI-V scope stream stalled — no complete waveform for >3s` —— 0x27 波形当然收不到，因为没有 CI-V 链路。
• 端口为什么是空的：同一台盒子上一次启动用的是 macOS 留下的配置（legacy.log `Radio model: ft710, serial port: [已隐去] @ 38400 baud`，并列出 `Available serial ports: [已隐去] … [已隐去]`，当时一个 USB 串口桥都没有）。`linux/mrrc_radio.py:plan()` 的既有规则是「换机型且没给端口就把 MRRC_SERIAL_PORT 清空，免得留下上一台电台的节点」，`_cmd_use` 探测不到时会打印 `no ic7300 answered — serial port left empty; re-run with --port [已隐去]` —— 与本包形态完全一致，属既有设计而非缺陷。
• 设备侧其实已经接上：同一次启动里 `Found configured audio input: [0] USB Audio CODEC: - (hw:1,0)`、`RX audio started … actual=48000Hz, channels=1`，说明 IC-7300 的 USB（声卡+CAT 同一根线）现在是枚举着的，缺的只是把 CI-V 节点写进配置。
• 历史对照：`SDD/14-version-history.md` V2.92（2026-10-17 对 1.28.1 产物的只读检查）记录过同一个现象「`env/mrrc.env` 存在且不含 `MRRC_SERIAL_PORT`，串口探测在镜像上从未运行过」，其修法「首启探测：从『跑过一次』改成『跑到定型为止』」在 CHANGELOG 里仍位于 `## [Unreleased]`（CHANGELOG.md:435/745），即 1.28.7 的盒子线不含这条自愈；所以这台盒子不会自己把空端口补上，必须人为指定（或升到含该修复的版本）。
• 附带两个与本问题无关的独立问题（不影响控台，但要一起修）：① FT8 起不来 —— `FT8 composition failed — running SSB-only` + 在 `import scipy.signal` 途中 `UnicodeDecodeError: 'utf-8' codec can't decode byte 0x80 in position 0`（venv 里 numpy 的文件已损坏；1.28.7 修的是 aarch64 上 scipy 1.17.1 的 `SEGV`，签名不同）；② 音频电平被手工设得过高 —— `Audio levels from file: TX mic +16.0 dB, RX +30.0 dB`，随后每 30 s 一条 `RX gain +30 dB is clipping the signal`，而广播侧 `RX audio is near-silent (peak=0.0%)`。
• 顺带一条环境提醒：`2026-10-26 16:38` 那次启动有 `cloud hub: frpc exited with -15; restarting in 2s`，属隧道重启，与串口无关；`Weak password detected` 也是既有告警。

你要做的

• 1) 确认 IC-7300 的 USB 线插在**盒子**的 USB 口（不是电脑），电台已开机；IC-7300 菜单 Connectors→CI-V 里：CI-V Baud Rate 与盒子一致（盒子默认 115200）、CI-V USB Port 设为 `Unlink from [REMOTE]`、CI-V USB Baud Rate 设为与上面相同或 Auto。
• 2) 看盒子上到底出现了哪个节点：`ls -l /dev/serial/by-id/`（同时可 `ls [已隐去]* [已隐去]*`）。**优先用 by-id 的稳定路径**，因为 IC-7300 的 CP210x 重新枚举后 ttyUSB0/1 会变号（CHANGELOG v1.28.x 记录过「固定写 [已隐去] 当场失效」）。
• 3) 一条命令让盒子自己探测并重启：`sudo mrrc-radio use ic7300`（会先停服务再探测，避免端口被自己占住）。若打印 `no ic7300 answered`，就显式给端口：`sudo mrrc-radio use ic7300 --port /dev/serial/by-id/usb-Silicon_Labs_CP2102…-if00-port0`（或 `[已隐去]`）。
• 4) 核对写入结果：`mrrc-radio show | grep MRRC_SERIAL_PORT` 必须非空。（等价手工做法：编辑 `/opt/mrrc_modern/env/mrrc.env` 的 `MRRC_SERIAL_PORT=`，再 `sudo systemctl restart mrrc-modern`。）
• 5) 判断已接通：新日志出现 `ic7300.civ: … connected` 一类成功行、界面上 `serial_connected=True`、瀑布图不再显示 S 表合成波形（`S-meter fallback` 消失、出现 0x27 真实波形），频率/模式旋钮即刻生效。
• 6) 把过高的音频电平拉回来：☰ 菜单（或 `/settings` 的「音频电平」）把 TX 麦克风从 +16 dB、RX 从 +30 dB 调回 0 dB 附近，等 `RX gain +30 dB is clipping` 的告警停止；若 RX 峰值仍为 0.0%，检查电台 AF 旋钮与 USB MOD 输入选择。
• 7) 修 FT8 的损坏依赖：在盒子上重装依赖即可（`sudo /opt/mrrc_modern/venv/bin/pip install --force-reinstall -r /opt/mrrc_modern/requirements.txt`，或直接跑一次 `sudo mrrc-update` 让升级脚本重编译/重装），修好前 SSB/控台不受影响。

相关代码：linux/mrrc_radio.py:plan / _cmd_use（换机型清空端口的既有设计，带 --port 提示；非缺陷，仅需操作员指定端口）

(未填写)

盒子此刻完全看不到 FT-710 的 USB 接口 —— FT4222 频谱、CAT 串口、USB 声卡三样同时缺失，是电台 USB 链路/供电/线缆问题，不是产品缺陷。

诊断

• 频谱侧：FTDI 库加载成功（scope_pipe: libs_loaded:ft4222=libft4222.so:ftd2xx=libftd2xx.so），但紧接着 5 次 open_failed 全部 error_2（`FT_OpenEx` 的 FT_STATUS=2 = FT_DEVICE_NOT_FOUND，见 backends/ft710/scope_pipe.py:148-154），随后 spi_init_failed:all_attempts → fatal:cannot_open_device，并每 1 s 重启一次、连续约 20 轮、frames=0 —— 说明 USB 总线上没有这颗 FT4222，而不是库缺失或路径问题（CHANGELOG:1294 那条「真频谱从未启动」是 macOS 相对 vendor 路径缺陷，此处 libs_loaded 已成功，签名不符）。
• 同一台盒子 7 天前是好的：server-prev.log 有 `scope_pipe: spi_ready:attempt_1:clk_div_6` + `first frame received — spectrum active (span=7, s_meter=101, wf1_max=127)`，且 `IF poll: vfo_a=14270000 Hz`、FT8 rx_tap 在持续喂入 112800 blocks（rms≈3000）—— 镜像自带的 FTDI 库/udev 规则与整条链路当时可用，所以这是「这次设备不在」而非「规则/库坏了」。
• 另外两路同时缺失，指向同一根 USB 线：env.json `radio.serial_connected=false`、`audio.devices.rx=[]`，tx 只有 W103D-HDMI/sysdefault/hdmi/default/dmix，完全没有 FT-710 的 USB Audio CODEC 声卡 —— CAT 串口、USB 声卡、FT4222 是电台同一根 USB 电缆上的三个接口，同时消失只能是电缆/端口/电台电源。
• 更早的证据链一致：summary 里 2026-10-17 的 ERROR 组为 `Serial write error for 'FA': (5, 'Input/output error')` → `could not open [已隐去]: No such file or directory` → `Available serial ports: [已隐去]…ttyS0`（只有板载 UART），即 USB 串口桥当时就掉了；同夜的 14 条音频恢复记录（`RX audio restart failed — capture stays down`、`[Errno -9993] Illegal combination of I/O devices`）也是同一根 USB 反复重枚举的后果。
• summary 自身有一处不可信：`启动次数：53 次，时间跨度 2026-10-18 00:51:15 → 2026-10-18 00:51:15` 两端相同（support_bundle.py:214-220 取首尾时间戳），别拿这个时间跨度当时间线；53 次重启实际分布在 10-17 11:17 → 10-18 00:51 这一夜，与 USB 掉线/重试吻合。
• 附带风险：env.json 显示 `recording.active=true` 而 rx 设备为空 —— 现在这条录音只会写出时长正确、内容全静音的 MP3（写入端本身没问题，是没音频可录），建议先停。
• 本仓历史检索（CHANGELOG.md、SDD/14-version-history.md）没有与 `open_failed:error_2`/`cannot_open_device` 同签名的产品缺陷记录，唯一的 FT4222 打不开是 Windows 僵尸进程残留（CHANGELOG:2649-2654，需杀掉旧 pipe、约 10–15 s 自愈）与 macOS vendor 路径缺陷（CHANGELOG:1294-1301），两者这里都不成立（Linux 盒子、库已加载、已连错 20 轮远超 15 s）→ 判为环境/接线问题。

你要做的

• 把 FT-710 后面那根 USB 线从盒子上拔下来等 5 秒再插回；换一根已知良好的数据线（很多 Type-B 线是纯充电线），直插盒子 USB 口，不要经过无源 HUB 或延长线。
• 确认电台是真的开着（面板亮、电源有电流指示），不是待机或断电 —— 电台关掉时这三样会同时消失。
• 在盒子上执行 `lsusb`，应能看到 `0403:601c FT4222`（或 FTDI）与 Yaesu 的 USB 声卡；再 `ls [已隐去]*` 应有 ttyUSB0。看不到 → 仍是线/口/供电问题，换一个 USB 口（优先带供电的口）重试。
• 设备出现后重启服务让它重连：`sudo systemctl restart mrrc`；随后日志里应重新出现 `scope_pipe: first frame received — spectrum active`、`serial_connected=True`，网页顶部频率能读到。
• 把正在进行的录音先停掉（☰ 里停止录音），等音频输入恢复再开 —— 现在开着的录音只会写静音文件。
• 若 `lsusb` 已能看到 FT4222 但日志仍是 `open_failed:…:error_2`：在盒子上 `dmesg | tail -30` 看 ftdi_sio 是否抢占了该接口，并确认服务以 mrrc 用户在自带 udev 规则下运行（镜像自带规则，正常不会出现），然后把 `dmesg` 结果重新上报一次。

相关代码：无代码缺陷可指；相关上报点 backends/ft710/scope_pipe.py:FT_OpenEx（scope_pipe.py:148-154，error_2 即 USB 上找不到设备）

FT710更新安卓1.1.33后频率显示处不显示设置的频率，但是系统是已经切到了相应频率。就是说点击到14.270显示0000，但是频谱下的频率是到14.270

频率一直 00.000.00、微调无反应是安卓 App v1.1.33 的已知 Compose strong-skipping 缺陷（v1.1.34 已修）；服务端 CAT 频率正常，升级 App 即可

诊断

• 症状与服务端无关：同一条日志里 CAT 轮询读到的是正确频率 —— `2026-10-24 12:33:29,162 [INFO] mrrc.poll: IF poll: vfo_a=14270000 Hz (+700 Hz) (loop=51500)`，且 `problem.txt` 说「能听到通联」，说明电台真的在 14.270。
• 与 v1.1.33 的已记录事故完全同签名：`FT710Android/CHANGELOG.md` 的 `[1.1.34]` 条目写「现场反馈：连得上、有声音、有频谱、能控制电台，只有主频读数不动，一直 00.000.00；转一次屏、或者点一下别的地方，频率就出来了」，与用户「过一会频率会变显示出来」「微调没反应」逐条对应。
• 根因（不是服务端、不是解析）：Kotlin 2.0.21 起 Compose strong skipping 按实例比较不稳定参数，v1.1.33 抽出的 FreqBezel/MetersCard/ControlsCard/TuningCard 传的是同一个可变 `vm.state` 实例 → 整块被跳过 → `state.activeFrequency` 不再重读；`FT710Android/CLAUDE.md:239` 记的正是「v1.1.33 的真机事故就是它」，修法是让组件订阅 `vm.version`。
• 用户当前环境 `diagnostics/env.json` 是 `version 1.28.0`（服务端），App 为 1.1.33：仓库里修复版本是 `app/build.gradle.kts:23 versionName = "1.1.34"`，早于修复 ⇒ 属于「升版本即解决」，非回归。
• 次要问题 A（与频率无关）：`logs/server-prev.log` 里 `scope_pipe: open_failed:attempt_1..5:error_2` → `spi_init_failed:all_attempts` → `fatal:cannot_open_device` 每秒循环，`diagnostics/summary.txt` 因此判「S 表合成回退」；`CHANGELOG.md:2602` 有同签名历史（残留进程占住 FT4222 时 `FT_OpenEx` 报 FT_DEVICE_NOT_FOUND），属 FT-710 USB 频谱接口被占用/未枚举的环境面向。
• 次要问题 B：`logs/server.log` 每 ~15 s 一条 `ft8.engine.cascade: deep decode path failed; keeping the fast results` + `ft8.core.supervisor.WorkerFault: worker_exit: worker process exited with status None`，前面紧跟 `mrrc: FT8 REST/WS routes mounted`，且 `slot N: 0 message(s)`；与 `CHANGELOG.md` `[v1.28.2]` 记录的「Windows 给线程 2 MB 栈、`sync8var` 单帧约 4 MB、静默死亡」完全同签名，1.28.0 不含该修复 ⇒ 升到 ≥1.28.2（盒子线 1.28.5·FP1）即可，不是新缺陷。

你要做的

• 卸载并安装安卓 App v1.1.34（未装过 1.1.32 之前版本的话可直接覆盖升级；1.1.32 起换过签名，若提示「应用未安装」就先卸载再装，卸载会清掉已保存的服务器地址与口令，需重新登录）。装好后点 14.270 应立刻显示，不必再转屏。
• 升级后若仍只在「转一下屏/点一下」才更新，请提供 App 版本号（☰ 关于页）与该次诊断包，按其作为回归处理。
• 频谱（S 表合成曲线）另作处理：关掉所有可能占用 FT-710 USB 频谱接口的程序（Yaesu PCC、WSJT-X、另一个还开着的 MRRC 服务端），把电台 USB 线拔插一次或换一个 USB 口，等 10 s 再启动服务端；`error_2` 消失后才会出现真实瀑布。
• FT8 若在用：把服务端升级到 ≥ 1.28.2（盒子线 1.28.5·FP1）。1.28.0 在 Windows 上每次深路径解码都会让 DSP worker 静默死掉（`worker_exit … status None`），这次一并解决。

相关代码：修复已在 FT710Android/app/src/main/java/com/hamradio/ft710android/UI/MainScreen.kt（FreqBezel/MetersCard/ControlsCard/TuningCard 订阅 vm.version）；服务端 FT8 栈修复在 ft8/core/worker.py::_run_with_large_stack

发射的功率很小啊

这次发射电台被键控了，但服务端一个麦克风帧都没收到、写进声卡 0 帧、音频峰值 0%（SSB 无调制＝射频功率接近零），所以“功率很小”首先是发射音频没送进电台；同时日志里 FT8 深路径每槽杀死 DSP worker 的签名与本仓 1.28.2 声称已修的缺陷完全一致，属回归，需按缺陷排查。

诊断

• 这次发射没有任何调制，是本次上报最硬的证据：`2026-10-22 16:03:20,672 [INFO] mrrc: TX session: frames=0 fed=0 decode_fail=0 written=0 write_err=0 queue_drops=0 peak=0% non_owner_drops=0` —— 浏览器侧 0 帧到达、后端 0 帧写入声卡、峰值 0%。SSB 无调制即无射频功率，这与“功率很小”完全吻合（ptt 之后到 release 之间的整段都是静音）。
• 同签名历史判定（之一）：`frames=0 fed=0 written=0 peak=0%` 与 SDD V2.71 记录的“键控了却没有声音”同形，但那次的判据是 `non_owner_drops=190/118/102/236`（上行所有权被半开 socket 占住），本例 `non_owner_drops=0` 且断开时 `owner=True`，故不是同一缺陷；V2.71 与 V2.78 的修复都已包含在 1.28.2 中，不能据此判回归。
• 同题历史（发射功率小）：SDD V2.78（包 `20261010-205200-6e3c`，v1.25.4，SSB 7.05 MHz，问题描述逐字相同“发射功率小/没有”）的结论是“软件链路是清的 → 根因在电台侧调制输入源”，当时日志是 `frames=351 … written=228 … peak=52%`。本例恰恰相反：软件链路不清（written=0），所以不能直接套 V2.78 的电台菜单结论，必须先解决“音频没发出去”。
• FT-891 的音频路径本身就是环境约束：该 profile 无 USB 声卡（`backends/yaesu/yaesu_profiles.py` 的 ft891 段 `audio_name_hints=()`，注释 `# D3: nothing to auto-match`），CAT 走 [已隐去]@4800（`Radio model: ft891, serial port: [已隐去] @ 4800 baud`），发射音频必须由外接 USB 声卡送到电台的 DATA/ACC 口；日志里已自动落到正确的那块卡：`Using default audio output: [4] 扬声器 (USB PnP Sound Device)` + `TX audio started: [4] 扬声器 (USB PnP Sound Device) (host=MME, default=44100Hz, actual=48000Hz, channels=1)`，所以“选错设备”不是本次主因。
• 网页上的功率表不能作为判据：FT-891 profile 的 `unverified_meters=("s_meter", "power", "swr", "alc", "comp")`（`backends/yaesu/yaesu_profiles.py:436`），`power_format`/meter 曲线 provenance 均为 `TODO(hw-verify)` —— 这台机型的功率读数未校准，看到“小”可能是显示问题，必须用电台自己的表或外接功率表判断。
• FT8 深路径回归（同签名，须按缺陷处理）：`[WARNING] ft8.engine.cascade: deep decode path failed; keeping the fast results` 紧接 `ft8.core.supervisor.WorkerFault: worker_exit: worker process exited with status None (generation 19, restarts 18)`，每 15 s 一次、累计 restarts 到 18（server.log）/155（server-prev.log）。这正是 SDD V2.90 记录并在 v1.28.1/1.28.2（CHANGELOG 顶条“FT8 深路径不再每槽杀死 DSP worker”）修掉的缺陷，当前版本 1.28.2 仍复现 → 回归。快路径仍在解（`decodes=17 fast=17 escalations=0`），所以表现为“少量漏解”，不是完全不能解。
• 旁证（非本次主因）：`Configured audio device '麦克风 (USB Audio Device)' not found` 是保存的设备名与当前枚举名（`麦克风 (USB PnP Sound Device)`）不一致，属 V2.6/V2.37 记录过的 Windows 声卡改名条件，已自动回落到 mono 设备；`RX audio is near-silent (peak=0.1%)` 与之后 `RX tap level: rms=376 peak=1606` 说明 RX 侧时有时无，与“USB 声卡/接线”方向一致，但不解释 written=0。
• TX 门禁：`Radio model ft891 is NOT hardware-verified — transmit is ENABLED by env override` —— 用户已自行设 `MRRC_ALLOW_UNVERIFIED_TX=1`，这是全部 TX 行为（含未校准的功率/ALC 读数）的前提，属预期行为，不是缺陷。

你要做的

• 先在客户端确认麦克风真的在采：用手机/PC 打开页面 → 点一次发射并说 3 秒，看浏览器是否弹麦克风授权；iOS/Android/浏览器任一处拒绝授权，就会一帧音频都不发（本次 frames=0 的形态）。换一个已知能录音的设备/浏览器（Chrome 直连 https://<盒子或电脑 IP>:8888）复测。
• 复测后看日志里的 `TX session: frames=`：仍是 0 说明音频根本没进服务端（客户端问题，继续查权限/静音键/输入设备）；如果 frames>0 而 written=0，才是服务端写声卡的问题。可以在 ☰ 菜单里再打一次诊断包对比。
• 确认发射音频进了电台的调制口：FT-891 没有 USB 声卡（USB 只做 CAT），发射音频必须由那块外接 USB 声卡（日志中的 [4] 扬声器 (USB PnP Sound Device)）接到电台的 DATA/ACC 口，并在电台上把该口的调制输入/电平打开（DATA 输入电平约 50，不要为 0），否则就是“键控有、功率近零”。同一根因在本仓历史记录里出现过两次（SDD V2.78 / 包 20261010-205200-6e3c“发射功率小/没有”）。
• 在 Windows 上把该 USB 声卡的播放音量拉到 100%，并在“声音 → 通信”里选“不执行任何操作”（默认会在检测到通信时把音量降到 80%/50%，直接表现为功率小）。
• 功率用仪器判断，别用网页表：FT-891 的 power/swr/alc 读数在 profile 里标为未校准（`unverified_meters`），请以电台前面板的 PO 表或外接驻波功率表为准；若电台自己的表也小，再查电台的 RF POWER 菜单是否被调低（FT-891 出厂 100 W，SSB/CW/FM 5–100 W）。
• FT8 侧：深路径每槽让 DSP worker 退出（现象已由日志确认），当前只有快路径在解；遇到漏解多的时隙时重开 FT8 页面/重启一次应用可临时缓解，根治需要代码侧修复（已在本次结论中作为回归上报）。

相关代码：ft8/core/worker.py:_run_with_large_stack / ft8/core/supervisor.py:request（worker_exit status None 的捕获与 generation 细节）+ ft8/dsp 内仍会终止进程的两处 Fortran stop（patched/four2avar.f90、vendor/packjt.f90）；TX 音频零帧一侧先看 server.py:_handle_audio_tx 与前端 tx_capture_worklet.js 的麦克风授权失败路径，非本次直接缺陷

发射的功率很小啊

那次发射是「零调制」而不是功率设置小：服务端一帧上行语音都没收到（frames=0/written=0/peak=0%），LSB 下 SSB 无调制即无射频功率；该签名与 v1.25.4 修过的「键控了却没有声音」同签名，当前 1.28.2 应已含该修复 → 按回归排查，同时核对 FT-891 的音频入口（外接声卡→DATA/ACC）。

诊断

• 故障当次 TX 完全没有语音上行：`2026-10-22 16:03:20,672 [INFO] mrrc: TX session: frames=0 fed=0 decode_fail=0 written=0 write_err=0 queue_drops=0 peak=0% non_owner_drops=0`，前一秒刚 `TX audio started: [4] 扬声器 (USB PnP Sound Device) (host=MME, default=44100Hz, actual=48000Hz, channels=1)`，说明发射键按下了、声卡也开了，但浏览器/App 一帧都没送上来 ⇒ 电台被键控却拿不到调制信号。
• 电台在此期间是 LSB（`Initial state: freq=7048000 mode=LSB s_meter=200`）。SSB 无调制＝几乎没有射频功率，本仓文档写的就是这句话：docs/OPERATION_GUIDE.md:109「SSB 则表现为『功率很小或没有』」。所以用户看到的「功率很小」是调制为零的结果，不是功率档位/功放的问题。
• env.json 侧复核同一事实：`"tx_stats": {"written": 0, "write_err": 0, "peak": 0, "queued": 0, "queue_drops": 0}` —— 服务端一个 PCM 帧都没写进 TX 设备。
• 与历史同签名：SDD V2.71 / v1.25.4 记录的「键控了却没有声音」现场取证正是 `frames=0 fed=0 written=0 peak=0%`（website/answers/index.html:370 与 :448-451 逐字引用），修复内容是同一 30 天令牌下多条 /WSaudioTX 的上行归属（`_claim_tx_owner_for_token` / `_same_session_uplink_takeover`，见 website/answers/index.html:369 与 board hint `20261007-203517-f40d`）。env.json `version=1.28.2` 晚于 v1.25.4 ⇒ 当前版本应已包含该修复，故按回归排查。
• 包内确实存在多 socket 上行归属的痕迹，支持上面的回归判断：`16:03:16 [WARNING] mrrc: Removed 1 dead/slow audio clients`、`16:03:27,261 [INFO] mrrc: Audio TX client disconnected (2 remain, owner=True)` —— 同一登录下有多条 /WSaudioTX（页面重载留下的半开旧 socket 或两个标签页），正是 v1.25.4 描述的认领场景。
• FT-891 这一层的配置也在同一方向上：FT-891 的 USB 口只做 CAT、不带 USB 声卡，音频必须外接声卡进 DATA/ACC 口（AGENTS 后端表、docs/OPERATION_GUIDE.md:3、docs/MACOS_INSTALLER_GUIDE.md:133）。本机日志里 `Configured audio device '麦克风 (USB Audio Device)' not found` ⇒ 配置里写的设备名在这台机器上不存在，实际用的是回退的 `USB PnP Sound Device`（[1] 收 / [4] 发）。
• 发射门禁不是原因：`Radio model ft891 is NOT hardware-verified — transmit is ENABLED by env override`，env.json `radio.tx_gated=false` —— 发射是被放行的，键控确实执行了（否则不会有 TX session 行）。
• 与本症状无关的噪声（不改变结论）：logs/ft8-worker.log 的 1979 条 Traceback 全是 `EOFError` / `BrokenPipeError: [WinError 109]`（FT8 DSP 子进程随 WS/会话断开重启）；`Command error (scope_span=9): 'YaesuCatController' object has no attribute 'set_scope_span'`（FT-891 无频谱源）；`Spectrum broadcast active: S-meter fallback` 对 `scope_type=none` 的 FT-891 属预期。

你要做的

• 先确认这不是功率档位问题：FT-891 面板 RF PWR 调到满功率（SSB 5–100 W），再按住 PTT 说话，看面板 ALC 是否动 —— ALC 不动就说明调制还是没进来，继续下一步，不要去调功放/天调。
• 只留一个页面：把其它标签页、手机 App、以及旧的同名登录全部关掉，然后刷新页面重新登录，再按一次 PTT。每次发射后看日志/🐞 里的 `TX session` 行：`frames`/`written` 必须 >0、`peak` 不为 0%、`non_owner_drops`=0。
• 检查浏览器麦克风权限与输入设备：允许该站点使用麦克风，系统默认输入选 `麦克风 (USB PnP Sound Device)`（本机实际设备名），不要选 Realtek 内置麦或虚拟声卡。
• 把配置里的设备名改成实际名字：`MRRC_AUDIO_RX_DEVICE` / `MRRC_AUDIO_TX_DEVICE` 写 `USB PnP Sound Device`（当前配置里的 `麦克风 (USB Audio Device)` 在本机不存在，日志已报 not found），改完重启 MRRC Modern。
• 核对 FT-891 的音频布线：外接声卡的输出接电台 DATA/ACC 口（FT-891 的 USB 只走 CAT，没有 USB 声卡），并在电台侧把语音调制输入切到该路（与文档 §0.6.2 里 Icom 的 `MOD Input` 同理）；SSB 语音下若仍只有载波、ALC 不动，就说明声音没进调制器。
• 若按上面做完、单标签页下 `TX session` 仍是 `frames=0 … written=0 … peak=0%`：这就是回归，请重新生成一个诊断包（🐞 页面上报）并在说明里写「1.28.2 上仍复现 frames=0」，把新编号贴回来。

相关代码：server.py:_claim_tx_owner_for_token / server.py:_same_session_uplink_takeover（配套 _register_tx_socket / _forget_tx_socket；TX 上行归属，v1.25.4 修复）

FT-891设备不工作

服务端把电台型号选成了 FT-710，而实际接的是 FT-891：CAT 握手用错后端（No ID response）、频谱去开 FT-710 才有的 FT4222 器件（必失败）。改选 Yaesu FT-891（含实验性发信开关）即可。

诊断

• 型号错配是根因：diagnostics/env.json 里 radio.model="ft710"、display_name="Yaesu FT-710"、scope_type="ft4222"，而 problem.txt 写的是「FT-891设备不工作」。
• CAT 侧证据：logs/stdout.log『Radio model: ft710, serial port: [已隐去] @ 38400 baud』→『Opening serial port [已隐去] at 38400 baud』→『No ID response from radio on [已隐去]. Check connection.』——FT-710 后端等自己的 ID 应答，串口物理上连上了（serial_connected=true）但对端不是 FT-710，所以没有应答。
• 频谱侧证据：logs/server.log 反复出现 scope_pipe: libs_loaded:ft4222=FT4222.dll:ftd2xx.dll → open_failed:attempt_1..5:error_2 → spi_init_failed:all_attempts → fatal:cannot_open_device，并每 1 s 重启子进程（10028 条）。FT4222 是 FT-710 内置的频谱芯片；FT-891 没有该芯片，也没有任何频谱协议（SDD/14-version-history.md:152『The Yaesu ASCII-CAT family (FTDX10 / FTDX101D / FTDX101MP / FTX-1F / FT-891) has no scope protocol at all, so it only ever shows the synthetic spectrum』），因此这串报错是选错型号的必然结果，不是硬件坏。
• 历史对账（不构成回归）：FT-891 于 v1.25.4 / SDD V2.72（2026-10-05）注册为第 11 个机型（CHANGELOG.md:1010-1012『MRRC_RADIO_MODEL=ft891 可选，无真机验证（AD-019），发信另需 MRRC_ALLOW_UNVERIFIED_TX=1，不出频谱流』，SDD/14-version-history.md:36）。当前包为 1.28.1，已含该后端（backends/__init__.py:33 "ft891" → YaesuBackend/FT891Backend），所以『支持不存在』这条可以排除，属设置项没切。
• 可达性证据：连接设置的下拉里已有该项（static/index.html:659 option value="ft891" →『Yaesu FT-891（实验性，仅接收，需外接声卡）』），profile 默认速率 38400（backends/yaesu/yaesu_profiles.py:411 default_baud=38400），与日志里的 38400 一致，切换后不必改波特率。
• 音频先决条件：FT-891 没有 USB 声卡（yaesu_profiles.py:488-490『The FT-891 has no USB sound card (the USB port is CAT only)』、audio_name_hints=() 即自动匹配无提示），必须外接声卡/DATA 接口。env.json 里确有『麦克风 (USB Audio Device)』『扬声器 (USB Audio Device)』且 configured_rx 指向 USB Audio Device，说明外接声卡在，但 TX 统计 written=0（从未发射过）。
• 附带观察（与本次故障无因果关系，供后续跟进）：FT8 深路径 worker 反复退出『ft8.core.supervisor.WorkerFault: worker_exit: worker process exited with status None (generation 3, restarts 2)』并回落到 fast 结果（logs/server.log:『deep decode path failed; keeping the fast results』），且 summary 记录 48 次启动；启动次数与 generation 递增说明这些退出现在多发生在进程重启期间，指向的是 FT8/重启行为而非 FT-891 连接。

你要做的

• 在应用内打开「连接设置」，把『电台型号』下拉从 Yaesu FT-710 改为 **Yaesu FT-891**（等价于设置 MRRC_RADIO_MODEL=ft891），保存并让服务重启。
• 串口保持日志里已能打开的 [已隐去]、38400 8N1（FT-891 profile 默认 38400）；同时核对电台菜单里的 CAT RATE 是否为 38400、CAT 是否使能，使两边一致。
• 接受 FT-891 的两个机型限制：它没有任何频谱流，瀑布图只会是合成的 S 表曲线（切过来后 scope_pipe/FT4222 那串报错会自动消失，也可以不管它）；发信默认被门禁拒绝，需要发射就设 MRRC_ALLOW_UNVERIFIED_TX=1（该机型无真机验证、且只有 HF+6m）。
• 音频必须走外接声卡：在设置里把接收/发射设备都指到『USB Audio Device』（当前 env 已如此，确认发射侧也选中它，或指向 DATA/ACC 接口的声卡），并确认电台菜单的 DATA/USB 调制输入源与之一致。
• 暂时不要在 FT-891 上打开 FT8 工作模式做验证——先确认调频/模式/接收音频正常（FT8 会额外触发上面那条 DSP worker 退出的噪声日志，混在一起不好判断）。
• 若切到 ft891 后仍然是『串口开了但没有 ID/频率不动』，请再报一次诊断包并注明：COM 口号、电台菜单 CAT RATE/CAT RTS 值、外接声卡型号——那时才是 FT-891 profile 的现场参数需要核对。

相关代码：backends/yaesu/yaesu_profiles.py:FT891（模型已存在，无需改代码；问题是 MRRC_RADIO_MODEL 选了 ft710）

软件启动后电台选择FTX-1保存重启又变成FT-710，网页也看不到频谱

Launcher 的首启探测白名单 `VALID_MODELS` 只含 ft710/ic7300/ic7300mk2，所选 ftx1 因此每次启动都被判为「未配置」，探测到 Yaesu 应答后把型号改写成 ft710 —— 于是续跑成 FT-710 后端（去找 FT4222 频谱芯片，找不到就退成 S 表合成）

诊断

• 型号回退的根因在 launcher 的首启逻辑，不在配置写入：`macos/first_run.py` 里 `VALID_MODELS = frozenset({"ft710", "ic7300", "ic7300mk2"})`，而 `apply_first_run` 用 `model_unset = model not in VALID_MODELS` 判断；`needs_first_run()` 也要求 `model in VALID_MODELS`，所以保存成 `ftx1` 后配置永远被当作「没定下来」，每次冷启动都重跑一次探测。
• 探测必然把它改回 FT-710：`probe_radio_model()` 只区分两种协议——`return "ft710" if probe is probe_ft710 else "ic7300"`，FTX-1 与 FT-710 同属八重洲 ASCII CAT（`ID;` 会应答，见 CHANGELOG v1.16.0「传输层是移植而非新写」），所以一律判成 ft710；随后 `if model_unset: model = RADIO_MODEL_FALLBACK`（`RADIO_MODEL_FALLBACK = "ft710"`）并 `update_env_file(config_path, updates)` 把 ft710 写回 `%LOCALAPPDATA%\MRRC-Modern\mrrc_modern.env`。
• 现场日志正是这条链路的结果：`2026-10-17 22:49:24,029 [INFO] mrrc: Radio model: ft710, serial port: [已隐去] @ 38400 baud`、`Connected to FT-710 (ID=0840) on [已隐去]`，env.json 里 `"model": "ft710", "scope_type": "ft4222"` —— 型号已被改写，而不是保存失败。
• 频谱空白是型号错误的后果，不是第二个故障：FT-710 后端走 FT4222 真实频谱，而机器上没有这个设备，`scope_pipe` 每轮 5 次 `open_failed:attempt_N:error_2` → `spi_init_failed:all_attempts` → `fatal:cannot_open_device` → `scope_pipe exited (frames=0, connected=False)`，约每 5 秒重启一次（日志里 22:54:01→22:54:26 反复出现）；summary 因此判「出现 S 表合成回退 —— 真实频谱未工作」。
• 另外，Yaesu 家族在 `backends/yaesu/backend.py` 是 `scope_type="none"`（AGENTS.md 记载：由现有 S 表合成器覆盖 UI），所以就算型号正确选成 FTX-1，也不会有真实瀑布——这一点是机型能力的边界，不是坏件。
• 同一白名单还挡住 ftdx10 / ftdx101d / ftdx101mp / ft891 / ic705 / ic7610 / ic7760 等全部 7 个非(ft710/ic7300/ic7300mk2)型号；CHANGELOG v1.16.0 只新增了机型与 profile，`first_run.VALID_MODELS` 与 `probe_radio_model()` 的映射从未随之扩展（SDD/14 的 V2.46、V2.72、V2.92 都无同签名记录），所以 1.28.1 仍带此缺陷。
• `2026-10-17 21:58:15,988 [WARNING] mrrc.audio: Configured audio device 'USB Audio' not found` 属另一件事且已自愈：同一份 stdout 里 22:49:35 `Found configured audio input: [1] 麦克风 (USB Audio Device)` 并成功 `RX audio started`，与本问题无关。

你要做的

• 每次开机/关掉程序重新打开后，进 ☰ 菜单的「连接设置…」，把电台型号重新选成 FTX-1 并保存：保存会写盘并让服务以 FTX-1 重启（这次运行内生效，不必再关程序）。这是当前版本的可用绕过，重启一次就得重来一次。
• 不要在选好 FTX-1 后再「关闭程序重新打开」——那一步正是首启探测把型号改回 FT-710 的时机；要切配置请用连接设置里的保存/重启路径。
• 关于频谱：FTX-1 在本产品里只有 S 表合成，没有真实瀑布（Yaesu 家族的 `scope_type="none"`），这与 FT-710 的 FT4222 频谱不是一回事；需要真实瀑布请使用带 FT4222 的机型（FT-710 / FTDX10 / FTDX101 等）。
• FTX-1 同时属实验性机型（v1.16.0 起「仅接收」）：若切到 FTX-1 后按 PTT 无反应属预期 TX 门禁，需要时在 `mrrc_modern.env` 里设 `MRRC_ALLOW_UNVERIFIED_TX=1` 后再保存重启（发射行为未在真机验证，请谨慎）。
• 想让设置永久保留：把配置副本另存一份（`[已隐去]\AppData\Local\MRRC-Modern\mrrc_modern.env`），每次启动后若发现型号又被改成 ft710，用副本里的 `MRRC_RADIO_MODEL=ftx1` 覆盖并在连接设置里保存一次；根治需要新版 launcher，但它自动覆盖这个键，用户侧无法绕过。

相关代码：macos/first_run.py:VALID_MODELS / needs_first_run / apply_first_run / probe_radio_model（应由 backends.known_models() 派生白名单，并让 probe 返回 "ftx1" 而非 "ft710"）

软件启动后电台选择FTX-1保存重启又变成FT-710

启动器首次自检不认 FTX-1：它把 ftx1 当作“机型未设置”，每次启动都重新探测串口、把机型改写成 ft710 存回配置 —— 不是用户选错，也不是电台的问题

诊断

• 现象与包内运行时状态一致：problem.txt「软件启动后电台选择FTX-1保存重启又变成FT-710」；env.json 里 radio.model=ft710，stdout.log 22:49:24 明确写着「Radio model: ft710, serial port: [已隐去] @ 38400 baud」，随后「Connected to FT-710 (ID=0840) on [已隐去]」——服务端根本没见过 ftx1。
• UI 确实提供 FTX-1，POST /api/setup 也接受它：static/index.html:708 `<option value="ftx1">Yaesu FTX-1F（实验性，仅接收）</option>`；server.py:4073 用注册表校验 `if radio_model not in known_models()`，而 backends/__init__.py 的 _BACKENDS 里确有 "ftx1"。也就是说保存这一步是成功的（env 里写进了 MRRC_RADIO_MODEL=ftx1）。
• 改写发生在服务端之前、启动器里：macos/first_run.py 是「Runs in the launcher (macOS menu-bar app, Windows tray app) BEFORE the server starts」，第 36 行 `VALID_MODELS = frozenset({"ft710", "ic7300", "ic7300mk2"})` —— 一份写死且陈旧的机型白名单，v1.16.0 加入的 ftdx10/ftdx101d/ftdx101mp/ftx1 与 ft891、以及 ic705/ic7610/ic7760 全都不在里面。
• 因此 needs_first_run() 对 ftx1 恒为 True：其判据是 `configured = pwd and pwd != DEFAULT_WEB_PASSWORD and model in VALID_MODELS and (MRRC_PORT_CONFIRMED==1 or 端口非默认)`，model="ftx1" 不在白名单 ⇒ 配置被判定为“未完成” ⇒ 每次启动（含 保存+重启）都走 apply_first_run()。
• apply_first_run() 接着把机型覆盖掉：`model_unset = model not in VALID_MODELS` ⇒ True，于是重新探测串口，探测成功后 `env["MRRC_RADIO_MODEL"] = model; updates["MRRC_RADIO_MODEL"] = model`，再 `update_env_file(config_path, updates)` 写盘 —— 服务端重启后读到的就是 ft710。
• 探测本身也无法区分 Yaesu 家族：probe_radio_model() 结尾 `return "ft710" if probe is probe_ft710 else "ic7300"`，对任何用 ASCII `ID;` 应答的八重洲机器一律返回 "ft710"（probe_ft710 只判 `ser.read(64).startswith(b"ID")`），所以 FTX-1 被“认成” FT-710 而不是探测失败。
• 与「8 次启动 / 时间跨度 21:57:45 → 22:49:37」吻合：用户反复「选 FTX-1 → 保存 → 自动重启」，每次重启都被启动器改回 ft710，于是再次进入连接设置看到 FT-710。
• 历史检索（`grep FTX-1|ftx1|radio_model|update_env_file CHANGELOG.md`、SDD/14 相关条目）里没有同签名记录：CHANGELOG v1.16.0 只加了机型与 profile（`MRRC_RADIO_MODEL=ftdx10 | ftdx101d | ftdx101mp | ftx1`），SDD/14 V2.22 只说明启动器模板暴露了 MRRC_RADIO_MODEL（默认 ft710），没有任何一条修过“启动器白名单不含新机型” —— 属新缺陷，不是回归。同一类缺陷在 /api/setup 已经修过（server.py:4073 的注释：「a hardcoded tuple (which is how ic705/ic7610/ic7760 would have been unreachable from the connection dialog)」），启动器这一份被漏掉了。
• 副带现象均为“跑错后端”的次生结果，不必单独追：scope_pipe `open_failed:attempt_N:error_2` → `spi_init_failed:all_attempts` → `fatal:cannot_open_device` 无限重启（FT-710 才有 FT4222 SPI，FTX-1 的 profile 是 scope_type=none，走 S 表合成）；summary 中「频谱：S 表合成回退」同源。音频那条 `Configured audio device 'USB Audio' not found`（21:58:15）在 22:49 已自愈 —— 22:49:35 日志显示 `Found configured audio input: [1] 麦克风 (USB Audio Device)`，不构成本问题。
• 风险提示：在机型被写成 ft710 的情况下用 FT-710 后端操作 FTX-1，不只是标签错 —— 模式/滤波表与 CAT 字符表按机型不同（CHANGELOG v1.16.0），且 ft710 不设未验证机型发射闸（FTX-1 本应 tx_gated），会对一台未验证机型按 FT-710 假设发 PTT。

你要做的

• 先确认是“被改写”而不是“没点到”：连接设置里选 Yaesu FTX-1F → 保存并重启，然后看 `%LOCALAPPDATA%\MRRC-Modern\logs\server.log` 是否仍是 `Radio model: ft710`。若仍是 ft710，即为启动器改写（1.28.1 已确认）。
• 临时绕过启动器：关掉托盘的 MRRC Modern 启动器，直接运行安装目录里的服务端入口（安装菜单中的「MRRC Modern Server」快捷方式），并确保配置文件 `%LOCALAPPDATA%\MRRC-Modern\mrrc_modern.env` 里有一行 `MRRC_RADIO_MODEL=ftx1`（手改时把已有的那行 ft710 改掉，别写成两行）。不带启动器启动时不会再被改回 ft710。
• 同一份 env 里把串口/波特率写死成实际值（本包是 `MRRC_SERIAL_PORT=[已隐去]`、`MRRC_BAUD_RATE=38400`），这样即使某次仍走了自检，也不会因探测顺序变化换口。
• FTX-1 属未真机验证机型：只做接收不用管；确需发射时在 env 里加 `MRRC_ALLOW_UNVERIFIED_TX=1`（默认拒发），首次发射请小功率、确认频段与驻波。
• 在机型稳定为 ftx1 之前不要用当前（ft710 后端）实例发射 —— 模式/滤波表按 FT-710 下发，且不带未验证闸。接收与频谱（S 表合成）不受影响。
• 顺手把 `%LOCALAPPDATA%\MRRC-Modern\launcher.log` 一起附在下次报告里：它能直接看到启动器那次 `Detecting the radio on N serial port(s)` 的探测与写回，便于确认改写来源；升级到修复启动器机型白名单（改为读取 backends.known_models()）的版本后，就可以恢复用启动器、在连接设置里选 FTX-1F 并持久生效。

相关代码：macos/first_run.py:VALID_MODELS / needs_first_run() / apply_first_run() / probe_radio_model()（白名单应改为 backends.known_models()，探测需返回真实机型或保留用户已选机型，不得把 ftx1/ic705/ic7610/ic7760/ftdx10/ftdx101d/ftdx101mp/ft891 判为“未设置”）

软件启动后电台选择FTX-1保存重启又变成FT-710

1.28.1 的启动器首启探测仍用硬编码三机型白名单（ft710/ic7300/ic7300mk2）判定型号，FTX-1（ftx1）被视为「未设置」，于是每次启动都重新探测并回写成 ft710 —— 这是产品缺陷，不是用户操作问题。

诊断

• 启动器把「型号不在硬编码白名单」当成首启未配置：`macos/first_run.py` 的 `VALID_MODELS = frozenset({"ft710","ic7300","ic7300mk2"})`，而 `needs_first_run()` 的 `configured` 条件要求 `model in VALID_MODELS`。FTX-1 的注册键是 `ftx1`（backends/__init__ 注册表、CHANGELOG v1.16.0「MRRC_RADIO_MODEL=ftx1」），永远不满足，于是**每次启动 launcher 都会重跑自动配置**，`MRRC_PORT_CONFIRMED=1`/`MRRC_FIRST_RUN_DONE=1` 都拦不住。
• `apply_first_run()` 里同一份白名单决定了回写值：`model_unset = model not in VALID_MODELS` → 为 True 就重新探测串口；探测函数 `probe_radio_model()` 只会返回 `ft710`/`ic7300`（FTX-1 也答 Yaesu ASCII `ID;`，因此被认成 ft710），探测不到则 `model = RADIO_MODEL_FALLBACK`（`"ft710"`），最后 `updates["MRRC_RADIO_MODEL"] = model` 覆盖写回配置文件 —— 用户「保存的 FTX-1」被启动器改写掉。
• Windows 走的正是这条路：`windows/launcher.py` 第 14 行 `from macos import first_run`，`main()` 里 `env = ensure_first_run()` 调用的就是上面这套逻辑；rc==42 的配置重启虽会 `load_env(config_path())` 重读文件，但用户「关掉再开」的那一刻会重新过 `ensure_first_run()`，于是又变回 ft710。
• 包内证据一致：`env.json` 的 `radio.model=ft710`、`stdout.log`「Radio model: ft710, serial port: [已隐去] @ 38400 baud」、`Connected to FT-710 (ID=0840) on [已隐去]`，而 summary 显示 1 小时内 8 次启动 —— 与「每次启动都重新探测并回写」吻合。
• 同类缺陷在服务端已经修过、启动器这一份被漏掉：`server.py` 的 `/api/setup` 用 `known_models()` 并注明「Registry-derived: …instead of being rejected by a hardcoded tuple (which is how ic705/ic7610/ic7760 would have been unreachable from the connection dialog)」；`macos/first_run.py` 仍留着手写三元组，所以 v1.16.0 之后新增的 ftx1/ftdx10/ftdx101d/ftdx101mp/ft891/ic705/ic7610/ic7760 全部会被回退成 ft710。与 CHANGELOG:1635（V2.33「连接设置保存与首启探测…曾静默覆盖型号默认值」）同属「首启探测覆盖用户选择」这一类，只是那次修的是波特率分支、型号分支从未修。
• 包内其它报错不是本问题：`scope_pipe: open_failed:attempt_N:error_2` + `fatal:cannot_open_device` 表示这台机器上没有可打开的 FT4222 设备（FTX-1/非 FT-710 本来就没有 FT4222 波形源，v1.16.0 明确「没有真机频谱数据源，UI 用 S 表合成，不伪造瀑布」）；`asyncio … ConnectionResetError [WinError 10054]` 是浏览器/客户端断连的噪声；`ft8-worker.log` 的 `BrokenPipeError … EOFError` 是进程退出时 worker 被回收。这三类不解释型号回退。
• 需要注意的一点：日志里电台以 `ID=0840`、FT-710 的 CAT 应答；如果现场实际接的是 FT-710，那么选 FTX-1 本身也不可用（FTX-1 模式码 H/I 与滤波 SH 前缀都不同）。型号回写是缺陷，但「该选哪个型号」要以机身上的机器为准。

你要做的

• 先彻底退出 MRRC Modern（托盘/黑色命令窗口都要关，任务管理器确认没有 MRRC-Modern.exe / MRRC-Modern-Server.exe 残留），否则下一次启动仍会被探测覆盖。
• 用记事本打开 %LOCALAPPDATA%\MRRC-Modern\mrrc_modern.env，把 `MRRC_RADIO_MODEL=` 改成 `ftx1`（若真要把 FTX-1 当发射机，再补一行 `MRRC_ALLOW_UNVERIFIED_TX=1`，否则 PTT/TUNE 会被未验证机型门禁拒绝）；顺手确认 `MRRC_SERIAL_PORT=[已隐去]`。
• **不要用桌面/开始菜单里的「MRRC Modern」图标启动**（那是 launcher，会重新探测并把型号写回 ft710）。改用安装目录下的 `MRRC-Modern-Server.exe`，或开始菜单里的「MRRC Modern Server」快捷方式，再在浏览器打开 https://127.0.0.1:8888。
• 启动后到日志里核对一行：应出现 `Radio model: ftx1`（不是 ft710）；若仍是 ft710，说明 launcher 又跑了一次，按其托盘菜单完全退出后再用上面的 Server 入口启动。
• 如果只想稳定使用：把型号设回实际电台（例如 FT-710 → `ft710`），并在修复版发布前不要再在「连接设置…」里切换到 ft710/ic7300/ic7300mk2 以外的机型。
• 顺便清理环境噪声：这台机器没有可用的 FT4222 设备，FT-710 的真频谱需要 FTDI 驱动/设备（`FT4222.dll`+`ftd2xx.dll` 已加载但 `error_2` 打不开）；若确实是 FT-710 且要真频谱，请插好 USB 波形口并确认驱动，否则瀑布会一直是 S 表合成。

相关代码：macos/first_run.py:needs_first_run()/apply_first_run()（VALID_MODELS 硬编码三键 → 应由 backends.known_models() 派生，探测失败时保留用户已选的型号而不是回写 ft710）

关闭蒲公英VPN还是无法进入电台所在网络，打开bg7zhs.mrrc.vlsc.net网页显示502bad gateway电台所在网络使用了花生壳P5路由器。

本机服务与电台一切正常（启动完整、[已隐去] 已连、频谱/发射正常），502 出现在云端入口→本机隧道的链路；这与本仓记录过的『入口 502 而租户侧一切看起来正常』同签名，1.25.3 应已包含相关修复 → 按回归排查。

诊断

• 本机侧健康：stdout.log 显示 `SSL enabled`、`Connected to FT-710 (ID=0650) on [已隐去]`、scope-init 完成、`Poll scheduler started (7 tasks)`，radio.serial_connected=true —— 应用不是崩溃/未启动状态，因此 502 不是本机服务没跑起来。
• 电台在正常工作：server.log 尾部 `Session metrics: listeners 0 | operators 2 | uplink spectrum 293.0 kbps` 与 `TX session: frames=210 fed=210 written=205 write_err=0 peak=45%` —— 收/发链路在跑，租户侧看起来一切正常，正是历史条目描述的 502 画面。
• 云端隧道是本实例配置的一部分：stdout.log 有 `cloud_hub: cloud hub: clearing a stale frpc (pid 7424) holding this instance's tunnel` —— 说明本实例已接入 MRRC 云（bg7zhs.mrrc.vlsc.net 走 hub→frpc 回连），且 v1.25.2 的残留 frpc 清理在运行。
• 用户报 `打开 bg7zhs.mrrc.vlsc.net 显示 502 Bad Gateway`：与 CHANGELOG v1.24.2『隧道从界面接入时永远不启动 —— 入口一直 502，而租户侧看起来一切都对』、v1.24.7『入口 502 却没人提示重启』、v1.24.8『一台已接入的机器重启之后，入口会一直 502，直到有人点一下设置』、v1.25.0『hub 拿登记证书校验上游，入口会一直 502 而没有任何东西会去重启』完全同签名。
• 版本判据：env.json version=1.25.3（frozen, Windows），而上述 502/隧道生命周期修复在 v1.24.7 / v1.24.8 / v1.25.0，均已包含在当前版本中 ⇒ 不是『版本早于修复』，按回归排查；v1.25.4（V2.73）只补了 macOS 的 frpc 清理那一半，对 Windows 无影响。
• 环境提示（不能仅据此判环境）：problem.txt 里用户提到 蒲公英 VPN 与 花生壳 P5 —— frpc 是出站连接、本不需要同网段/VPN，这两层叠加可能干扰，但历史签名的优先级高于环境推断，故仍需按隧道链路排查。
• 次要异常（与本 502 无直接因果，供参考）：server.log 通篇为 `get_meter(RM8): unparseable response`（RM8 回读全是二进制垃圾），可能只是 RM8 度量解析噪声，也可能是串口被第二个进程占用，需在真机确认只有一个实例持 [已隐去]。

你要做的

• 打开应用「设置 → 接入云端」，查看入口地址与状态：若显示「还需重启应用以启用新证书」(cert_reload_required)，点重启按钮让新证书生效——老证书会过不了 hub 的上游校验，表现为入口一直 502。
• 完全退出 MRRC Modern（含托盘/任务栏，确认没有第二个 server/frpc 进程）后重新启动：应用启动时会把已接入的隧道自动拉起；随后到 `logs/stdout.log` 确认出现 frpc 的 `login to server success` 与 `start proxy success`（只有这两行出现，入口才会通）。
• 确认网络路径：蒲公英 VPN 已关（已做）；frpc 只需本机能出公网，不需要与电台同网段。若 花生壳 P5 开启了『内网穿透/VPN 叠加/DNS 劫持』类功能，先按普通 NAT 放行或关掉其叠加功能，避免与 frpc 的出站长连接冲突，然后重启应用。
• 确认没有重复实例：启动日志里 `Sending scope-init CAT commands...` 只应出现一次、`MRRC-Modern`/`frpc` 进程各只有一个；出现成对日志或两个 frpc 就是重复实例在抢 [已隐去] 和隧道代理名，先全部关掉再单开一个。
• 若以上仍 502：在「接入云端」重新刷新，或撤销后重新申请以重建端口路由（v1.24.3 起同呼号复用原端口，避免路由指向空端口）；并把最新版（≥1.25.4）装上后重试，同时保留 logs/stdout.log（含 frpc 输出）与 hub 侧 frps 日志供回归定位。

相关代码：cloud_hub.py:TunnelProcess（隧道启动/注册）+ server.py:_cloud_start_tunnel（启动时自拉隧道、证书判据）

偶尔重启系统和APP发射有声音大部分还是发射没有语音输出，用CQ键发射能听到CQ CQ CQ…的呼叫，IC7300/29.6FM

服务端收到 0 帧麦克风上行（frames=0/peak=0%，CQ 走服务端注入却正常），与仓库 V2.71 记录并修复过的「键控了却没有声音」同签名，而现场 1.25.5 已包含该修复，按回归排查。

诊断

• 现场版本 1.25.5（env.json.version），而 v1.25.4 的 CHANGELOG「同批到达：这一个包也是 FT-891 和『键控了却没有声音』到达用户的那个包」段明确该修复（SDD V2.71）随安装包发布，源码包内含 `_claim_tx_owner_for_token`/`_same_session_uplink_takeover`（CHANGELOG.md:389-404）⇒ 当前版本应已包含该修复。
• 失败签名与历史逐字吻合：多次 `TX session: frames=0 fed=0 decode_fail=0 written=0 write_err=0 queue_drops=0 peak=0% non_owner_drops=0`；V2.71 现场取证正是「四次发射全是 frames=0 fed=0 written=0 peak=0%，电台键控了、调制为零」（SDD/14-version-history.md 的 V2.71 行）。
• 日志同时出现多条 /WSaudioTX 与 non-owner 丢弃：`Audio TX client connected (2 total, owner=False)`、`TX audio from non-owner client ignored (drops=1) — another client owns the uplink`、其后 `Audio TX client disconnected (1 remain, owner=True)` —— 正是 V2.71 描述的多 socket 上行认领场景。
• CQ 键能听到呼叫（problem.txt）：CQ 由服务端 cq_player/TxSession 直接灌入 TX 队列，证明电台键控、TX 输出设备与电台调制输入通路均正常；因此故障只在上行（浏览器/App → 服务端）。
• 服务端音频设备另有环境噪声但不解释本症状：`TX audio started: [5] 扬声器 (USB Audio CODEC ) ... actual=48000Hz, channels=1` 成功、CQ 也走该设备；而同批 `Configured audio device '麦克风 (USB Audio CODEC)' not found`（配置名末缺一个空格）、`Found configured audio output: [27] ... (WDM-KS)` 后 `TX open failed x3 ([Errno -9999] Unanticipated host error) — re-initializing PortAudio`、`Multiple USB audio outputs: [5]/[13]/[18] — using [5]` 属 USB 重枚举/设备名与设备索引漂移，影响的是设备选择而非帧数。
• summary 的 Traceback 均为 `_ProactorBasePipeTransport._call_connection_lost`（Windows asyncio 断连噪声），与无语音无关；`scope_pipe open_failed/fatal:cannot_open_device` 早于本次发射（12:26），且 13:43:40 已有 `ic7300.scope: CI-V scope: first complete waveform — spectrum active (bins=475)`，频谱非本症状原因。

你要做的

• 只保留一个发射客户端：关闭其它浏览器标签页、另一台设备或另一个 App 的登录（日志显示同时有 2 条 /WSaudioTX 与一条 non-owner 丢弃）—— 上行同一时刻只归一条会话，多余的麦会互相压制。
• 在发射用的那个浏览器里确认麦克风权限与输入设备：站点设置→麦克风=允许，且输入不是 ToDesk Virtual Audio 等无信号虚拟声卡（被拒或选错设备时浏览器会一帧都不发，正是 frames=0）。
• 完全退出浏览器/App 再重开并重新登录一次后发射（清掉页面重载留下的半开旧 socket，避免认领落在不再送音频的旧连接上）。
• 升级到 1.25.5 之后的最新安装包（现行仓库侧为 1.27.x），重装后先只用单个客户端做一次发射验证。
• 排查环境时把音频设备写死为启动设备清单里的 MME 条目（如 MRRC_AUDIO_RX_DEVICE=1、MRRC_AUDIO_TX_DEVICE=5，或核对设备名结尾空格），避免 [27]/[28] WDM-KS 条目反复 -9999 打不开；改完重启服务再试。
• 自检判据：发射时看日志 `TX session` 行，`frames`/`written` 应 >0、`peak` 非 0%、`non_owner_drops`=0；若仍 frames=0，说明发射端浏览器/App 根本没送音频，按上面客户端侧继续排除。

相关代码：server.py:_claim_tx_owner_for_token / _same_session_uplink_takeover / _assign_tx_owner_on_connect（TX 上行认领）；static/ft710_main.js + tx_capture_worklet.js（浏览器麦采集是否出帧）

手机端发射声音太小

与 SDD V2.78（同日 2026-10-10、同为 v1.25.4 + IC-7300 的发射声音问题）同签名：软件链路清白，根因在电台侧调制输入源（Icom MOD Input / USB MOD Level），非产品缺陷。

诊断

• 软件链路是清的：TX 声卡选中正确且命中 USB 声卡 —— `TX audio started: [4] 扬声器 (USB Audio CODEC ) (host=MME, default=44100Hz, actual=48000Hz, channels=1)`；`env.json` 里 `configured_tx="扬声器 (USB Audio CODEC )"`、`radio.model="ic7300"`、`device_rates.tx=48000`。
• 服务端确实把语音写进了电台：`TX session: frames=85 fed=85 decode_fail=0 written=83 write_err=0 queue_drops=0 peak=21%` 与 `frames=121 fed=121 written=112 peak=0%`。`peak` 是服务端解码后 PCM 实测峰值（SDD V2.71 定义，`server.py:2740`），写入无差错、无丢帧。
• 电台也确实在发射且有调制：`TX meters active: RF_PWR=100W | COMP=0 ALC=101 PWR=52 SWR=15` —— `ALC` 非零说明电台当时收到了调制信号（对照 V2.78：ALC=0/PWR≈0 才是「调制没进来」）。
• 因此「声音太小」是**电平**问题而非通路问题：peak=21% 偏低（V2.78 的已知良好现场是 peak=52%），而多次 `peak=0%` / `frames=0 fed=0` 的发射是手机端当次根本没送音频（按键但未采集到声音）。
• 本仓历史同签名：SDD V2.78（2026-10-10，同日同版本 v1.25.4、同为 IC-7300）把两份上报的根因定为**电台侧调制输入源**（Icom `SET → Connectors → MOD Input`：`DATA OFF MOD` 未选 USB 时，FM 是死载波、SSB 表现为「功率很小或没有」），并明确『不是产品缺陷』；产品侧只补了文档，无代码修复可回归。当前日志与该结论一致（本包即 `20261010-220406-5793`，与 V2.78 记的 `20261010-205200-6e3c` 同批）。
• 噪音（非本问题）：233 条 Traceback / 249 条 ERROR 全是 `ConnectionResetError: [WinError 10054] 远程主机强迫关闭了一个现有的连接` —— 手机端 WebSocket 非正常断开，属客户端网络抖动；`scope_pipe: fatal:cannot_open_device` 来自早前的 FT-710 会话（14 次启动时间跨度 10-09→10-10），当前 `radio.scope_type="civ27"` 的 IC-7300 不走 FT4222；`cloud hub: cannot run frpc: [WinError 5]` 与发射音质无关。

你要做的

• 在 IC-7300 面板上核对 `SET → Connectors → MOD Input` 三项（这是本类问题的第一处）：`DATA OFF MOD = USB`（想同时留手咪就选 `MIC, USB`）、`DATA MOD = USB`、`USB MOD Level ≈ 50`（不要为 0）。
• 同组确认 `USB SEND = OFF`（MK2 同组另有 `USB Keying (CW/RTTY)` 也保持 OFF）。
• 说话时看电台 ALC 表是否摆动 —— 不动＝调制没进来，回去改 `MOD Input`（对应 `docs/OPERATION_GUIDE.md` §0.6.2 验证清单第 5 条）。
• 网页端把设备侧麦克风增益 `🎙 Vol` 滑杆往上调（0–200 → 0–2×，100 = 原值；见 CHANGELOG「Device-side mic gain」条），目标让服务端日志 `TX session ... peak=` 稳定在 40% 以上。
• 手机侧：确认浏览器已获麦克风权限、系统媒体音量非静音、不要按住麦克风孔、尽量用耳机麦克风贴近说话；若日志里某次发射是 `frames=0 fed=0`，说明那一下手机没采到音（重新授权/换浏览器重试）。
• 若上述都到位而对方仍觉小，把电台 `USB MOD Level` 从 50 逐步上调（如 70–80）再试，注意别过载（ALC 顶格反而失真）。

相关代码：无代码缺陷；用户指引见 docs/OPERATION_GUIDE.md §0.6.2（IC-7300 MOD Input）与 static/modules 的 🎙 Vol 设备侧麦克风增益

FT-7300开机就发射

日志签名 `TX session: frames=0 … written=0 … peak=0%`（键控了却没有声音）与 v1.25.4 修复的「同一 30 天令牌下多条 /WSaudioTX 上行归属错误」同签名，而当前版本正是 1.25.4（应已含该修复）→ 按回归排查。

诊断

• 日志反复出现 `TX session: frames=0 fed=0 decode_fail=0 written=0 write_err=0 queue_drops=0 peak=0% non_owner_drops=0` —— 键控确实发生，但一帧上行音频都没到服务端，正是 v1.25.4 CHANGELOG 记的「键控了却没有声音」现象。
• 包内可确认**同一会话存在多条 /WSaudioTX**：`20:34:14,608 [WARNING] mrrc: TX audio owner disconnected during TX! Forcing RX` 之后紧跟 `20:34:14,675 TX audio ownership promoted to remaining client (1 total)` 与 `20:34:14,676 Audio TX client disconnected (1 remain, owner=True)` —— 与 v1.25.4 描述的「页面重载留下的半开旧 socket / 同一登录的两个标签页」场景一致。
• 当前版本 = 1.25.4（`diagnostics/env.json` "version": "1.25.4"，`manifest.json` "version": "1.25.4"），而 CHANGELOG v1.25.4 明说该包已含修复：`_claim_tx_owner_for_token`、`_same_session_uplink_takeover` 都在里面（源码包逐字节核对）。因此这不是「版本太旧」，而是修复未生效的回归。
• 服务端 `is_transmitting` 由 CI-V 读回驱动（`radio_state.py` 中 `tx_status` → 派生 `is_transmitting`；`civ_controller.py` 的 `_try("tx_status", self.get_ptt)`），所以电台确实处于发射态；结合 frames=0，用户看到的「开机就发射」就是「电台被一条不再送音频的 socket 键控着、却无声」。
• 次要环境噪声不构成 frames=0 的判据：`[Errno -9999]`、`Configured audio device '麦克风 (USB Audio CODEC)' not found`（实际设备名多一个尾空格）影响的是服务端↔电台的声卡，而不是浏览器上行帧计数；Windows 的 `_ProactorBasePipeTransport._call_connection_lost` 是已知良性噪音。

你要做的

• 先排除多 socket 干扰：把所有打开该网页的标签页/窗口全部关闭（尤其 ToDesk 远端里和本机各开的一个），然后**只开一个**页面重新登录再试发射，同一账号不要同时开两个标签页。
• 检查浏览器麦克风权限与输入设备：该机存在 `麦克风 (ToDesk Virtual Audio)`，请把系统默认输入改为 `麦克风 (USB Audio CODEC )`，并允许浏览器使用麦克风后再按键。
• 若单一标签页下仍无声：按回归上报——打开 🐞 页面生成本次诊断包（含 `diagnostics/client.json`，本次包内该文件内容缺失），在答复里注明「1.25.4 上仍复现 frames=0」并附新的 `#编号`。
• 临时规避：发射前先松开再重新按下 PTT，并观察该次 TX 会话的 frames 是否仍为 0，以确认是否为上行归属问题；确认期间可用功率/SWR 表判断电台是否真在发信。

相关代码：server.py:_claim_tx_owner_for_token / server.py:_same_session_uplink_takeover（TX 上行归属；配套 _register_tx_socket/_forget_tx_socket）

云端申请500

「云端申请500」与 v1.24.0 引入云端接入时那个未导入 cloud_hub 的缺陷完全同签名，当前版本（1.24.0）早于修复版本，升级到 v1.24.1 及以上即可解决。

诊断

• 症状与你上报的完全一致：CHANGELOG v1.24.1 条目标题即「接入云端第一次真按就 500：那个模块谁也没导入」，正文写明「v1.24.0 把接入搬进了设置菜单，但真按『申请』只会得到一个 500」（CHANGELOG.md:707、709）。
• 根因是打包版 server.py 从未 `import cloud_hub`，导致申请端点在运行时报 NameError 并返回 500：现场堆栈 `File "server.py", line 4035, in api_cloud_apply` → `File "server.py", line 3987, in _cloud_portal` → `NameError: name 'cloud_hub' is not defined`（CHANGELOG.md:711-713；SDD/14-version-history.md 的 V2.64 同款记录）。
• 你的包版本恰是出问题的那个：env.json 报 `"version": "1.24.0"`、`"frozen": true`（打包版），而修复在 v1.24.1；也就是说 1.24.0 完全不含该修复，任何一次「申请」都必然 500。
• 当前仓库 HEAD 已含修复：server.py:67 有 `import cloud_hub`，_cloud_portal（server.py:5114）与 api_cloud_apply（server.py:5304）都正常引用 —— 证明这是已修复的旧版回归，不需要新改代码。
• 包内其余迹象（18:59 的 [已隐去] `PermissionError(13, '拒绝访问')`/`FileNotFoundError`、更早的 `Configured audio device 'USB Audio' not found`、频谱一时走 S 表回退）都属于串口被占用/设备名不符的瞬时环境问题，且日志显示 19:22 重启后串口已连上（`Connected to FT-710 (ID=0800) on [已隐去]`）、真频谱已 `first frame received`，与你上报的云端申请 500 不是同一件事。

你要做的

• 将 MRRC Modern 升级到 v1.24.1 或更高版本（v1.24.0 是首次加入云端接入、申请按钮必 500 的版本）：从 www.vlsc.net 下载最新安装包覆盖安装，或在应用内用「检查更新」。
• 升级并重启应用后，再打开「设置 / ☰ → 接入云端」填呼号提交申请，此版本起申请才可能返回正常结果。
• 若升级后申请仍报 500，请立刻用 🐞 生成新的诊断包发回，并附上点击「申请」的确切时间点。
• 本次包内另有两处环境提示可顺手排除：18:59 前后 [已隐去] 曾被其它进程占用（PermissionError/端口不存在），请确认没有第二个程序（如串口调试工具、另一个实例）占着 [已隐去]；音频设备名配置为 'USB Audio' 而实际设备名是 'USB Audio Device'，可在设置里选实际设备后重试。

相关代码：server.py:api_cloud_apply / server.py:_cloud_portal（1.24.0 缺 `import cloud_hub`；修复见 server.py:67 的 import 与 v1.24.1）

发射功率小/没有？ 你看看

同一条根因的 SSB 版本：电台在发射，但实测 `ALC=0`、`Po≈0`，而服务端同时在把音频写进电台 USB 声卡 —— SSB 没有调制就没有射频功率；先查电台 `MOD Input`（`DATA OFF MOD` / `DATA MOD` = `USB`）

诊断

• 「功率没有」在 SSB 下正是「没有调制」：`TX meters active: RF_PWR=56W | COMP=0 ALC=0 PWR=0 SWR=0` —— `RF_PWR=56W` 是功率设置值，`ALC` / `PWR` 才是实测。本段日志三次实测（18:05 / 20:17 / 20:46）全部 ALC=0，即调制器没有输入
• 同时服务端在正常送音频：本段日志里连服务端自带的 CQ 录音也完整播完（`CQ: keyed the radio` → `CQ session: written=307 write_err=0 queue_drops=0 mic_drops=0`，6.1 s 全帧），浏览器麦克风一路也有大幅值（`peak=100%`），所以不是「没送出音频」
• Icom 的调制输入源由 `SET` → `Connectors` → `MOD Input` 决定：`DATA OFF MOD` 管非 DATA 模式（SSB / AM / FM 语音），不含 `USB` 时语音发射只有载波 —— FM 表现为死载波、SSB 表现为没有功率，与同批另一份报告（对方听到发射但没声音）同源
• 另外本次语音峰值起伏很大（`peak=1%/5%` 与 `peak=100%` 交替），手机麦克风的距离/增益也要一起调整；调制打开后 ALC 应稳定有读数但不进红区
• 次要观察：`queue_drops` 多次出现（10~226），这台 Windows 机器的声卡输出节拍偏慢；若调制打开后仍有断字，见最后一条

你要做的

• 电台菜单 `SET` → `Connectors` → `MOD Input`：`DATA OFF MOD` = `USB`（语音模式用；想同时保留手咪就选 `MIC, USB`）、`DATA MOD` = `USB`（数据模式）、`USB MOD Level` ≈ 50（不要 0）。
• 同一组里 `USB SEND` 保持 `OFF`（IC-7300MK2 另见 `USB Keying (CW/RTTY)`）：它把 USB 口的 DTR/RTS 当作 PTT，设成 `USB(A) DTR/RTS` 后电脑一打开串口就等于按下 PTT。
• 改完按住 PTT 说话：网页面板上的 ALC 表必须动 —— 不动就是调制还是没进来；再用第二台接收机确认能听到语音。
• 麦克风电平：离嘴 5~10 cm 正常说话，避免长期 `peak=100%`（削波）或 1%（几乎无声）—— 本次两种极值都出现过
• 若仍有断字/断续：把 `MRRC_AUDIO_TX_DEVICE` 锁定为启动日志里 `default=48000Hz` 的 WASAPI 条目，或换 USB 口 / USB 线（本次 `queue_drops` 最高 226）

IC7300发射对方没有收到声音，测试用另外一台短波机收听也是听到发射但是没有声音

软件把语音送进了电台（52% 峰值的音频确证写进 USB 声卡），电台也真的在发射，但调制为零 —— 根因是电台侧的调制输入源没选 USB（`SET` → `Connectors` → `MOD Input`），不是音频链路故障

诊断

• PC→电台这一段是清的：`TX audio started: [5] 扬声器 (USB Audio CODEC ) (host=MME, default=44100Hz, actual=48000Hz, channels=1)`，随后 `TX session: frames=351 fed=351 decode_fail=0 written=228 write_err=0 queue_drops=110 peak=52%` —— `peak` 是服务端解码后 PCM 的实测峰值，52% 说明语音以正常电平写进了电台的 USB 声卡
• 对方听到的是「有载波、无调制」：本次电台在 FM 29.6 MHz（`Initial state: freq=29600000 mode=FM s_meter=6`），FM 的调制为零就是死载波 —— 与「听得到发射、听不到声音」完全吻合
• 唯一剩下的断点只能在电台内部：Icom 的 `SET` → `Connectors` → `MOD Input` 决定调制输入源，`DATA OFF MOD` 管非 DATA 模式（SSB / AM / FM 语音）、`DATA MOD` 管 DATA 模式、`USB MOD Level` 是 USB 输入电平；这一组不含 `USB` 时，网页里说的话不会进入调制器（电台用它自己的手咪当输入源）
• 这不是产品缺陷，但产品文档此前缺了这一节：FT-710 的等价要求（`MOD SOURCE = USB`）在操作指南与安装指南里都写着，Icom 的对应三条在全仓检索为零命中。本版已补进 `docs/OPERATION_GUIDE.md` §0.6.2 与 `docs/WINDOWS_INSTALLER_GUIDE.md`，并加了守卫测试防止再漏
• 次要观察（不改变结论）：本次 `queue_drops=110`，说明这台 Windows 机器的声卡输出节拍也偏慢；调制打开后若仍有断续，见最后一条

你要做的

• 电台菜单 `SET` → `Connectors` → `MOD Input`：`DATA OFF MOD` = `USB`（语音模式用；想同时保留手咪就选 `MIC, USB`）、`DATA MOD` = `USB`（数据模式）、`USB MOD Level` ≈ 50（不要 0）。
• 同一组里 `USB SEND` 保持 `OFF`（IC-7300MK2 另见 `USB Keying (CW/RTTY)`）：它把 USB 口的 DTR/RTS 当作 PTT，设成 `USB(A) DTR/RTS` 后电脑一打开串口就等于按下 PTT。
• 改完按住 PTT 说话：网页面板上的 ALC 表必须动 —— 不动就是调制还是没进来；再用第二台接收机确认能听到语音。
• 如果还有咔啦/断续：把 `MRRC_AUDIO_TX_DEVICE` 锁定为启动日志里 `default=48000Hz` 的那一条（WASAPI 条目），关掉不用的虚拟声卡（本机同时存在 ToDesk 虚拟声卡与立体声混音），或换一根 USB 线 / 另一个 USB 口 —— 本次 `queue_drops=110` 就是输出节拍跟不上的信号

没有开蒲公英，从外网进入https://bg7zhs.mrrc.vlsc.net/网页显示无法打开，更新md文件后显示网页出错，现在又显示无法打开网页

服务端本机是好的（8888 已监听 + SSL 已启用 + FT-710 CAT 已连上），公网打不开是入口通道问题——用户自己说"没有开蒲公英"；另外电台 USB 未枚举，导致 FT4222 频谱与 USB 声卡都不可用

诊断

• 公网入口不通 ≠ 服务未运行：stdout.log 显示本次启动完整成功——`SSL enabled: [已隐去]\AppData\Local\MRRC-Modern\certs\server.crt`、`MRRC Modern Web Control starting on port 8888`、`Connected to FT-710 (ID=0650) on [已隐去]`、10:30:03 仍在 `IF poll: vfo_a=7068000 Hz (loop=0)`，env.json 亦为 `"serial_connected": true`；用户在 problem.txt 里自述"没有开蒲公英"，所以 https://bg7zhs.mrrc.vlsc.net/ 无法打开是穿透/DNS 入口没起来，属网络环境问题
• `*.mrrc.vlsc.net` 不是本产品的配置项——本仓已有同一问题的公开答复（website/answers/index.html:46-62："`*.mrrc.vlsc.net` 不是本产品的配置项——产品只认 `MRRC_WEB_HOST`/端口 8888 和 `MRRC_SSL_CERT/KEY`"）；仓库全文检索 `mrrc.vlsc.net`/`bg7zhs` 只命中该答复页，代码里没有任何该域名的逻辑（公网收听入口是 www.vlsc.net/mrrc_modern/listen → 后端 radio.vlsc.net，与用户自建域名无关）
• 频谱回退与 Traceback/ERROR 是同一根因的下游噪声，不是崩溃：`scope_pipe: open_failed:attempt_1..5:error_2` → `spi_init_failed:all_attempts` → `fatal:cannot_open_device`（FT4222 设备枚举不到），scope_producer 按设计每 1s 自动重启管道（backends/ft710/scope_producer.py `_read_pipe` 末尾 `scope_pipe exited while active — will restart in 1s`），每次子进程退出都在 Windows Proactor 上产生 `Exception in callback _ProactorBasePipeTransport._call_connection_lost(None)`——体检摘要里 71 条 ERROR / 71 条 Traceback / 7055 条频谱命中都由此而来；日志尾部服务仍在正常轮询，没有致命异常
• 电台 USB 链路缺失（环境问题）：配置的收发声卡 `麦克风 (4- USB Audio Device)` / `扬声器 (4- USB Audio Device)` 在设备列表里不存在（`Configured audio device '麦克风 (4- USB Audio Device)' not found`，随后 `Using default audio input: [0] - Input`，即回落到 Realtek 主板声卡），FT4222 也 error_2；只有 [已隐去] 串口在——说明电台的 USB 口/线没接好，TX 时对方听到的不是电台音频
• server-prev.log 里 08:27–08:33 大量 `get_meter(RM8): unparseable response '<全 0/乱码>'` 也是同一 USB/串口链路不稳时期的产物；10:29 重启后 CAT 已恢复正常（ID=0650、频率读取成功），故不作为独立缺陷
• 历史比对：`open_failed:…:error_2` / `spi_init_failed` / `cannot_open_device` / `_ProactorBasePipeTransport._call_connection_lost` / `unparseable response` 在 CHANGELOG.md 与 SDD/14-version-history.md 中均无同签名条目（无既有回归记录），按环境/网络定性

你要做的

• 先把内网穿透客户端（蒲公英）启动并确认状态为"已连接"，再刷新 https://bg7zhs.mrrc.vlsc.net/ ；穿透没起来时该地址必然打不开，与 MRRC 无关
• 用局域网自证服务端正常：在同一网段的电脑/手机浏览器打开 `https://<这台Windows的局域网IP>:8888`（自签证书会告警，点"高级→继续访问"）。能打开即说明服务在跑，问题只在公网入口
• 核对穿透映射：外网端口要指向本机 **8888**、协议选 **HTTPS/TCP**（MRRC 是 https + WebSocket，HTTP 映射会白屏）；改完映射重启穿透客户端，并用 `nslookup bg7zhs.mrrc.vlsc.net` 确认域名解析到穿透给的地址
• 想不依赖穿透长期使用：路由器上把 8888 端口转发到这台机器，用自己的域名 + 真实证书（设置 `MRRC_SSL_CERT`/`MRRC_SSL_KEY` 指向 fullchain/key）；局域网内则直接用 `https://<本机IP>:8888`
• 接回电台 USB：现在只有 [已隐去] 串口枚举到，FT4222（频谱）与 "4- USB Audio Device"（电台声卡）都不在。检查 FT-710 的 USB 线/口与电台 MENU 的 USB 设置，在 Windows 设备管理器里应同时出现 USB Audio Device 与 FT4222/FTDI 设备；然后重启 MRRC Modern，瀑布图与真实频谱才会回来
• USB 声卡回来后，进"设备配置"把 RX/TX 音频设备重新选成实际存在的名字（当前配置项已失效并回落到 Realtek 默认设备，发射时对方听不到电台音频）；若暂时不接电台 USB，也请把配置改成现有设备名以消除启动告警
• 如果穿透起来后网页仍报错，请回报浏览器上的**完整错误文字/状态码**（例如 502 / 504 / ERR_TUNNEL_CONNECTION_FAILED / 证书告警）和穿透客户端日志——不同错误对应不同修法（映射端口错、后端超时、证书不受信）
• 顺带一提：env.json 显示 `"recording": {"active": true}`，若并非有意在录音，请在界面上停止录音，避免长时间占用磁盘

how to config the *.mrrc.vlsc.net? how can I make it work?

这台 Windows 机器上电台并未真正接上（串口不对/无 ID 响应、FT4222 找不到、没有任何音频设备），服务器只在『仅 UI』模式运行；`*.mrrc.vlsc.net` 不是本产品的配置项——产品只认 `MRRC_WEB_HOST`/端口 8888 和 `MRRC_SSL_CERT/KEY`。

诊断

• 核心不是域名配置，而是硬件没接上：日志显示串口 [已隐去] 打不开、唯一可用串口 [已隐去] 是主板通信口且无电台 ID 响应，FT4222 频谱设备、音频设备全部缺失，服务器退化为『Server will serve UI only』。
• 频谱签名 `scope_pipe: open_failed:attempt_N:error_2` → `spi_init_failed:all_attempts` → `fatal:cannot_open_device`：代码里 error 来自 FTDI `FT_OpenEx`，错误码 2 = FT_DEVICE_NOT_FOUND（scope_producer.py:70 注释明确提及），即 USB 上没有『FT4222 A』设备——电台 USB 线没接或驱动没装。
• 音频环境问题：`No audio input device found`，env.json 里 rx/tx 设备列表均为空 → 电台的 USB 声卡没枚举出来，属于环境缺失（非产品缺陷）。
• 串口环境问题：`Failed to connect to [已隐去]: ... FileNotFoundError`，可用端口仅 `[已隐去] (通信端口 ([已隐去]) ACPI\PNP0501\1)`；stdout.log 里 [已隐去] 能打开但 `No ID response from radio on [已隐去]` → 配置的 COM 口与电台实际口不一致或电台没接。
• Traceback 均为 `ConnectionResetError: [WinError 10054] 远程主机强迫关闭了一个现有的连接`，是浏览器/客户端断开 WS 的正常现象，不是崩溃。
• 域名方面：代码里产品域名固定为 `radio.vlsc.net`（config.py:196-199 SSL 注释与默认证书名），没有 `*.mrrc.vlsc.net` 相关逻辑；局域网访问走自签证书（ssl_bootstrap.py：为 LAN 用的 10 年自签证书，浏览器需信任一次）。

你要做的

• 用 USB 线把 FT-710 接到这台电脑并装好 Yaesu USB 驱动，让系统出现：电台串口（COM 口）、FTDI FT4222 设备、USB 音频设备。
• 在设备管理器确认电台实际枚举出的 COM 号，编辑 `[已隐去]\AppData\Local\MRRC-Modern\mrrc_modern.env`，把 `MRRC_SERIAL_PORT` 改为该 COM 号（当前日志显示配置 [已隐去] 不存在、[已隐去] 无响应），然后重启服务。
• 确认音频：接好线后系统出现 USB 音频设备；env 里 `MRRC_AUDIO_RX_DEVICE`/`MRRC_AUDIO_TX_DEVICE` 留空走自动检测，或填设备名。
• 域名访问：本产品不提供 `*.mrrc.vlsc.net`。局域网内直接用 `https://<本机IP>:8888`（默认绑定 `::`，可用 `MRRC_WEB_HOST` 改）；想用自己的域名需自行做 DNS 解析 + 路由器端口转发 8888 + 用 `MRRC_SSL_CERT`/`MRRC_SSL_KEY` 指向真实证书（如 Let's Encrypt fullchain）。
• 浏览器首次访问自签证书会有『不受信任』警告，接受一次即可；若走真证书则不会有警告。
• 日志里的 WinError 10054 Traceback 可忽略，不影响使用。

analysis the logs

FT-710 未通过 USB 正确连上电脑（CAT 串口、FT4222 频谱、USB 音频三路同时缺失），属环境/连接问题，非产品缺陷

诊断

• 频谱 FT4222 打不开：日志反复出现 `scope_pipe: open_failed:attempt_N:error_2`（N=1..5），随后 `spi_init_failed:all_attempts` + `fatal:cannot_open_device`，`scope_pipe exited (frames=0, connected=False)` 每 1s 无限重启。依据 scope_pipe.py 的 open_device()：用 `d2xx.FT_OpenEx(desc, FT_OPEN_BY_DESCRIPTION, ...)` 按描述 "FT4222 A" 打开设备，返回非 FT_OK 时打印 `open_failed:attempt_{N}:error_{s}`——error_2 即 D2XX 状态码 2 = FT_DEVICE_NOT_FOUND，说明 FT4222 设备根本未在 USB 上枚举到
• 音频缺失：`No audio input device found`，env.json 中 `audio.devices.rx: []`、`audio.devices.tx: []`，configured_rx/tx 均为空——电台的 USB 声卡也没出现
• CAT 无响应：`No ID response from radio on [已隐去]. Check connection.`，串口配置为 [已隐去]@38400（[已隐去] 通常是物理/旧串口而非 FT-710 的虚拟串口），serial_connected 仅表示端口能打开，不代表电台应答
• `ConnectionResetError: [WinError 10054]` 是浏览器/客户端断开连接导致的 asyncio 回调异常，非崩溃，可忽略

你要做的

• 确认 FT-710 已开机，并用数据 USB 线（非仅充电线）连接到这台 Windows 电脑
• 打开设备管理器检查三样东西是否出现且无黄色感叹号：端口(COM 和 LPT) 下的 USB Serial、通用串行总线下的 "FT4222 A"、音频输入/输出下的 USB Audio CODEC；缺失则安装 FTDI D2XX/FT4222 驱动后重插
• 在配置文件 mrrc_modern.env（[已隐去]\AppData\Local\MRRC-Modern\mrrc_modern.env）中把串口改成电台实际占用的 COM 口（当前写的是 [已隐去]），或删掉 MRRC_SERIAL_PORT 后重开让程序重新识别
• 确认没有其他程序（WSJT-X、Hamlib、另一个 MRRC 实例）占用该 COM 口或 FT4222 设备
• 改好后重启应用；WinError 10054 只是浏览器页签断开，无需处理

(未填写)

无在发产品缺陷：录音「dropped/queue full」签名与 V2.44/V2.45（v1.15.0 发布）修复的写入端生命周期缺陷同签名，但均为 2026-09-12 旧日志、当前 v1.18.1 已含修复（server.py:348 `_ensure_rec_writer()` 幂等重建 writer、server.py:432 队列满改为丢最旧块），09-19 近期日志录音/音频/串口全部健康；其余命中为 USB 串口重枚举（环境）与开发机跑测试套件写同一日志造成的 Traceback 误报

诊断

• 录音命中全部是 2026-09-12 22:30 的旧日志（summary.txt『== 录音写入：233 条 ==』首条 2026-09-12 22:30:23,503 『Recording dropped 350 block(s) so far』、22:30:24,151 『Recording queue full on stop — finishing directly』），与 SDD/14-version-history.md V2.44/V2.45 记录的 22:26 现场签名（dropped 950 块 + queue full on stop + 时长正确全静音）同源，该缺陷在 v1.15.0 已修复，当前 1.18.1 远高于修复版本 → 按已修复的历史残留处理，非回归：2026-09-19 的 server.log 尾部无任何录音告警，env.json 显示 recording.active=true 正常
• 『串口掉线 5335 条』为 [Errno 6] Device not configured 的 USB 桥重枚举（summary.txt『串口恢复：出现 ENXIO…』），日志原文已指明电缆/供电/无源 HUB 嫌疑，且均发生在 2026-09-12；09-19 近期日志 serial_connected=True、IF poll 每约 5 分钟一次干净返回（『2026-09-19 08:55:14,656 IF poll: vfo_a=7060000 Hz (+0 Hz)』），属环境问题非缺陷
• 『Traceback 47 条 + 启动 25 次 ⚠️崩溃』是误报：server-prev.log 尾部大量行是单元测试输出（/dev/fake 端口、tmp 路径、『test_cq_player.py:162』『test_memory_recall.py:66』等），即本机在仓库目录跑测试套件时与服务器共用 logs/server*.log，测试的 Traceback 被计入体检；09-19 真实服务器会话（08:13–08:55）无异常，TX 会话 frames/written 正常、queue_drops=0
• 音频『Configured audio device not found』与『RX open failed -9999』均为 09-12/09-18 旧记录，对应设备重枚举后缓存索引失效（AGENTS.md 已记载该已知行为并带重初始化恢复）；09-19 日志显示『RX audio started: [4] USB Audio Device』反复成功
• 『Weak password detected!』（2026-09-19 08:55:07,770）为使用建议；『未验证机型拒绝发射』TX 门禁 141 条属预期安全行为（env.json tx_gated=false，实际在用 FT-710 未被门禁）

你要做的

• 若近期再次遇到录音无声：直接重新录一段并用播放器确认，当前版本已按会话重建写入器；如新录音仍全静音再上报并注明时间点
• 串口若再掉线：把 FT-710 USB 线直插主机（不用无源 HUB），换一根短一点的优质 USB 线，并确认电台供电稳定；掉线后服务器会自动重连，无需重启
• 设备重插后若提示『Configured audio device not found』：在设置里重新选择当前的 USB Audio 设备名保存即可（系统重枚举会改变设备序号，程序已按名称解析）
• 建议把测试/开发运行的服务端日志与日常使用的 MRRC_LOG_DIR 分开（例如日常启动器已指向用户数据目录），避免测试 Traceback 污染体检摘要
• 把 Web 登录密码改为至少 12 位、含大小写/数字/符号，消除 Weak password 告警
• 如需 IC-705/IC-7760 等未验证机型发射，先按日志提示用 _diag_civ.py 核验电台，再设 MRRC_ALLOW_UNVERIFIED_TX=1 并重启；对 FT-710 无影响，可忽略该告警

相关代码：server.py:348 _ensure_rec_writer（V2.44/V2.45 修复已存在，当代码无需改动）

(未填写)

录音签名与 V2.44/V2.45 修复的「写入端一次性生命周期」缺陷同签名，当前 v1.18.1 已包含修复；包内命中行全部为 2026-09-12 修复前的历史日志，9/18 当天无新录音丢弃，按回归排查（用户先做一次新录音验证），其余告警（串口 ENXIO、音频 -9999、TX 门禁、弱密码）均为已知环境/预期行为

诊断

• 录音签名逐行吻合本仓历史：`Recording dropped 350 block(s) so far` + `Recording queue full on stop — finishing directly` 与 V2.44/V2.45（v1.15.0 发布，2026-09-12）记录并修复的『MP3 writer 只在进程启动时创建一次，首次 REC/STOP 后每会话无人消费、时长正确内容全静音』缺陷完全同签名；当前代码已含修复（server.py:348 `_ensure_rec_writer()` 在每次 add_audio/stop/REC 幂等重建 writer，队列满改为丢最旧块）→ 按回归排查：包内该签名的样本行时间戳均为 2026-09-12 22:30/22:37（修复发布前的旧日志残留），而 2026-09-18 当天的 log 尾部零条录音丢弃，故需用户在 1.18.1 上录一段新 QSO 验证；若新录音仍全静音即为回归
• 串口掉线 6893 条：`[Errno 6] Device not configured` + `No such file or directory: [已隐去]` 为 USB 串口桥物理层消失后重枚举（V2.43 已优化恢复成本：重连不再做 17 s 的全量状态同步），属线缆/HUB/供电环境问题，非产品缺陷
• 音频恢复 192 条：`RX open failed ([Errno -9999] Unanticipated host error)` 是 macOS Core Audio 在 USB 重枚举后缓存设备索引失效的已知现象，产品已内置 PortAudio 重初始化 + 按设备名重解析重试（audio_handler.py）；`Configured audio device 'USB Audio Device' not found` 与之同源，env.json 显示当前两设备均已枚举到，属瞬时环境问题
• TX 门禁 141 条（IC-705/IC-7760/FTDX10 not hardware-verified — transmit refused）为预期安全行为，且本机 radio.model=ft710、tx_gated=false，不影响使用；`Weak password detected!` 为密码强度提醒
• Traceback 47 条在包内未附任何堆栈内容（仅重复标题行），且 server-prev.log 显示本机同时跑过单元测试（tests/test_cq_player.py 等），无法归因到运行故障；如需排查需附原始堆栈段落

你要做的

• 录音回归验证：在 v1.18.1 上开启一次录音（REC）→ 收发几十秒 → 停止，回放生成的 MP3 确认有声音；本仓 recordings 目录文件名含频率与时间（如 `<freq>kHz_<日期>_<时间>.mp3`），若新录音正常则说明包内命中只是 9/12 的旧日志，无需处理；若仍全静音，再上报并注明新录音的文件名与时间
• 串口稳定性：电台 USB 线直连电脑、不经无源 HUB；换一根短一点的优质 USB 线；确认电台供电稳定（重枚举多由供电/接触引起）；掉线后程序会自动重连并经轮询层级恢复状态，无需手动重启
• 音频无声/启动时 RX 打不开：电台断电重开或换 USB 口后，在设置里重新选择 RX/TX 设备（macOS 重枚举会改变设备序号，程序会按名称重解析，但设备被系统改名/占用时需手动重选）并重启服务
• 如确需在未验证机型上发射才设置 MRRC_ALLOW_UNVERIFIED_TX=1（先用 _diag_civ.py 验证电台），本例 FT-710 已验证、无需设置
• 按提醒把 Web 登录密码改为 ≥12 位、含大小写/数字/符号的强密码

相关代码：server.py:_ensure_rec_writer（修复已在当代码；如复现回归再查 recorder.py:_recording_writer_loop 与 server.py 的 _rec_queue 消费端）