🐞 FDE 看板 — 上报 → 分类 → 排期 → 后台迭代

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

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

FT-991A 不在支持机型列表，被配成 FT-891 后真实频谱/扫宽本来就拿不到（Yaesu 系 scope_type 一律为 none，只剩 S 表合成的固定窄带图），静噪只下不读且 FT-991A 与 FT-891 的 SQ 命令未

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

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

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

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

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

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

config.py:371 (G7250_LAN_IP) / backends/xiegu/lan_iq.py (LAN IQ producer) / audio_handler.py:_reinit_pyaudio、audio_handler.py:390

决策备注：自动分类：环境/误报，答复页已回

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

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

决策备注：自动分类：环境/误报，答复页已回

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

决策备注：自动分类：环境/误报，答复页已回

音频 RX/TX 配置名锁死了旧 ALSA 编号 'USB Audio Device: - (hw:0,0)'，而电台声卡现已枚举在 hw:1,0，与 SDD V2.88/CHANGELOG v1.7.7 记录的配置名锁死同签名；自动检测已

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

决策备注：自动分类：环境/误报，答复页已回

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

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

决策备注：自动分类：环境/误报，答复页已回

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

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

决策备注：自动分类：环境/误报，答复页已回

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

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

决策备注：自动分类：环境/误报，答复页已回

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

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

决策备注：自动分类：环境/误报，答复页已回

三个症状里「不能发射」和「没频谱」是 FTX-1F 这一未验证 profile 的既定行为（TX 门禁 + 无 CAT 波形协议）；「频率不同步」在包里没有 FTX-1 的 CAT 交换证据，无法判定，需补证据。

backends/yaesu/backend.py:_tx_allowed / backends/yaesu/yaesu_profiles.py:FTX1（scope_type 由 backend.py:67 固定为 none）；频率路径候选点 backends/yaesu/cat_core.py:set_frequency（未确证，需 _diag_yaesu.py 实测）

结论仍成立但已不再是无解：TX 门禁自 1.28.17 · FP13 起可以在设置页「实验机型的发射」里打开（红字风险 + 两道确认，改完立即生效），所以「不能发射」有了明确的操作路径；「没频谱」依旧是 FTX-1 没有 CAT 波形协议的设计限制，界面只能走 S 表合成的频谱。频率不同步那条已随 6ee319a6 / 1548cd00 修好（见 0b0f）。

升级本身没坏：FTX-1 的发射被「未验证机型」门禁挡着（1.28.17 正是为无 SSH 的盒子新增了设置页开关，开关还没打开），另有三件独立的环境/设置问题（FT8 因 venv 内 numpy 导入失败停用、音频增益 +30/+3 d

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

决策备注：自动分类：环境/误报，答复页已回

升级本身成功（1.28.17/FP13 已跑起来，CAT 已连上、记忆信道召回归位）；真正卡住的是 FTX-1 的「未验证机型」发射门禁——它在 1.28.17 里已经可以从设置页打开，不必再改 env/重启；FT8 不可用是 venv 里

无产品缺陷。仅一处文案可改进：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/

决策备注：自动分类：环境/误报，答复页已回

这份包里的三件事分别是：FTX-1 属未验证机型，发射门禁按设计拒绝（不是升级引入的缺陷）；FT8 因 venv 里 numpy/scipy 文件损坏整体不可用（早于 1.28.16 就存在）；瀑布走 S 表合成是 Yaesu ASCII-

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

决策备注：自动分类：环境/误报，答复页已回

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

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

决策备注：自动分类：环境/误报，答复页已回

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

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

决策备注：自动分类：环境/误报，答复页已回

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

修复已在 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

决策备注：自动分类：环境/误报，答复页已回

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

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

决策备注：自动分类：环境/误报，答复页已回

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

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

决策备注：自动分类：环境/误报，答复页已回

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

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），非产品缺陷。

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

决策备注：自动分类：环境/误报，答复页已回

用户版本 v1.24.0 上「接入云端→申请」返回 500，正是本仓 v1.24.1 已修复的同一缺陷（server.py 未导入 cloud_hub → NameError 500）；该版本不含修复，升级到 v1.24.1 或更高即可。

server.py/api_cloud_apply（v1.24.0 缺 `import cloud_hub`；v1.24.1 起在 server.py:67 补上，当前仓库已含修复）

决策备注：自动分类：环境/误报，答复页已回

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

决策备注：电台侧 MOD Input 未选 USB（根因非软件）；答复页已回，文档已补 + 守卫测试

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

决策备注：电台侧 MOD Input 未选 USB（根因非软件）；答复页已回，文档已补 + 守卫测试

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

决策备注：补记：发布者已答复（本机状态文件重建时从答复页回收，分类 网络）

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

决策备注：补记：发布者已答复（本机状态文件重建时从答复页回收，分类 环境）

analysis the logs

决策备注：补记：发布者已答复（本机状态文件重建时从答复页回收，分类 环境）

录音签名与 V2.44/V2.45 修复的「写入端一次性生命周期」缺陷同签名，当前 v1.18.1 已包含修复；包内命中行全部为 2026-09-12 修复前的历史日志，9/18 当天无新录音丢弃，按回归排查（用户先做一次新录音验证），其余

决策备注：自动分类：环境/误报，答复页已回

无在发产品缺陷：录音「dropped/queue full」签名与 V2.44/V2.45（v1.15.0 发布）修复的写入端生命周期缺陷同签名，但均为 2026-09-12 旧日志、当前 v1.18.1 已含修复（server.py:34

决策备注：自动分类：环境/误报，答复页已回

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

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

两处实码缺陷都修了，随 1.28.16 · FP12 起交付（当前 v1.28.22 内含）：6ee319a6 把 Yaesu 家族的 bands 从三元数组改成对象带默认频率 —— 之前 server.py 的 band 命令按 band['name'] 取值，数组上直接 TypeError，界面乐观更新了、电台没动；1548cd00 给 FTX-1 加了「改频前先 VM000 离开存储信道」（存储信道上的 FA 只是瞬时覆盖，实机表现就是频率不生效）+ 写后读回校验 + 被电台回 ?; 时留下证据。瀑布「不正常」是 FTX-1 没有 CAT 波形协议的设计限制（只能走 S 表合成），不是缺陷；「不能发射」是未验证机型门禁，自 1.28.17 起可在设置页开关。

main@1548cd00

诊断包里没有任何 NB/NR 的 CAT 交互证据：指令发出（NB01/NR01）是否被电台回 `?;` 拒绝、轮询（NB0/NR0）读到什么原文都看不到；能定位到的实码缺陷是「写命令的返回值被丢弃、状态先乐观更新 + 抑制轮询 3 秒」，

server.py:_handle_field_set（nb/nr 分支，3197-3207：未检查 cat.set_noise_* 返回值即 radio.update + skip_next_poll）；待真机 CAT 抓包确认后需比对 backends/ft710/backend.py:settings_poll_items 的 NB0/NR0 解析 endswith('1')

随 v1.28.21 · FP17 交付（d686ce69「NR 等级是 RL0 + 两位，不是三位」、11e0489f 发布；早一步的 95615586 修了「写命令的返回值被丢弃 / 状态乐观更新」）。NR/NB 现在真的写进电台并把电台的值读回来，已在 [已隐去] 真机核对。包内缺 NB/NR 的 CAT 交互证据这一点仍成立 —— 那是诊断包的取证缺口，不是代码缺陷。

main@d686ce69

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

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

v1.28.2 已修并发布（提交 5c9fedf，产物 2026-10-21）：VALID_MODELS 改为从 backends.known_models() 派生，探测结果只填空、不覆盖用户已选机型。升级到 v1.28.2 后 ftx1 不再被判「未配置」，也不会被改写成 ft710。

决策备注：fixed in v1.28.2 (5c9fedf)

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

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

v1.28.2 已修并发布（提交 5c9fedf，产物 2026-10-21）：VALID_MODELS 改为从 backends.known_models() 派生，探测结果只填空、不覆盖用户已选机型。升级到 v1.28.2 后 ftx1 不再被判「未配置」，也不会被改写成 ft710。

决策备注：fixed in v1.28.2 (5c9fedf)

Launcher 的首启探测白名单 `VALID_MODELS` 只含 ft710/ic7300/ic7300mk2，所选 ftx1 因此每次启动都被判为「未配置」，探测到 Yaesu 应答后把型号改写成 ft710 —— 于是续跑成 FT

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

v1.28.2 已修并发布（提交 5c9fedf，产物 2026-10-21）：VALID_MODELS 改为从 backends.known_models() 派生，探测结果只填空、不覆盖用户已选机型。升级到 v1.28.2 后 ftx1 不再被判「未配置」，也不会被改写成 ft710。

决策备注：fixed in v1.28.2 (5c9fedf)

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

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「键控了却没有声音」(V

git apply --check 失败：error: corrupt patch at line 14

FTX-1 在**副通道（vfo_b）**上的调谐/记忆调用没落到电台的操作侧：服务端只发 `FB`、不发 `VS`/`FT`，电台自己报的频率一直停在 14.270 MHz；而客户端（APP）还把频率写成 30000/51389 Hz 这

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_

git apply --check 失败：error: corrupt patch at line 20

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

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/

git apply --check 失败：error: corrupt patch at line 40

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

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 音频零帧一

git apply --check 失败：error: patch fragment without header at line 72: @@ -2983,3 +3087,9 @@

诊断包显示服务端本身健康、包内没有任何 cloud_hub/portal/frpc 日志行，无法判断「申请/链接 portal」卡在哪一步，需要按下「申请」那一刻的日志才能定性——现有证据下判 need_more_info。

server.py: _cloud_portal / api_cloud_apply / api_cloud_refresh 与 cloud_hub.py（TunnelProcess.connect）是历史修复点；本次包内无 portal 日志，未定位到具体代码缺陷，仅作复核方向

本包未见可确认的产品缺陷：串口掉线与 PortAudio -9999 都自动恢复、真实 FT4222 频谱已出帧；自动体检的「S 表合成回退」是启动瞬态导致的误报，但 37 条 Traceback 的正文不在这份摘要里、问题描述为空，无法定

未定位到用户侧产品代码缺陷；次要点 support_bundle.py:summarize_log 的 S-meter fallback 判定过宽（本包误报，真帧已收到）

诊断包未填写问题描述，且自动体检报告的两条结论均被包内证据推翻/解释：真频谱实际已工作、音频告警是 10-11/10-12 的历史且已在 10-13 自动恢复——需用户补充具体现象。

server.py:1809-1816（首帧前的 S 表回退日志带 if _first，仅过渡态一次；与 v1.25.1 的 scope_pipe 启动缺陷签名相反，非缺陷）

摘要里的『S 表合成回退』是频谱客户端接入后首个广播 tick 的正常瞬态（包内日志证明真 FT4222 频谱随后就出帧并持续工作），不是缺陷；真正无法判定的是 17 条 Traceback —— 摘要只打印了 traceback 头部，包

现象指向控制链路/子进程在与电台通信期间异常中断（半开或服务异常退出），但包内日志不含 PTT 卡键那一小段，无法定因；先按安全闸门与 USB 链路两条可执行路径处理，并补齐事故日志。

server.py:_ptt_key_ws 与 _tx_liveness_watchdog（PTT 键控/存活闸门，默认关闭，待事故日志确认是否回归）；config.py:MRRC_REMOTE_SESSION_TX_HEARTBEAT_S / MRRC_PTT_MAX_TX_SECONDS

诊断包确认了 FT8 DSP worker 每个时隙都崩溃、FT8 全程 0 解码，但用户报告的「服务器进程消失 + 电台卡在发射」那一刻的日志并未进包（无 PTT/unkey 行、无主进程致命 traceback），因此卡键根因证据不足，

候选待确认：ft8/core/worker.py:handle_decode（原生 binding.decode 崩溃使 worker 每时隙死亡）与 ft8/core/supervisor.py:_roundtrip_locked（报出 worker_exit）；主进程消失路径未定位

包内没有证据显示服务端把 RX 音频做小了（同一会话里 tap 抓到 peak 9065/32767 属正常电平），音量上限卡在「电台 AF 增益 + App 播放增益 min(10, vol/255×boost)」；另外发现 1.27.0

ft8/core/worker.py:handle_decode（shared_memory_unavailable 唯一来源）/ ft8/engine/dsp_decode.py:SupervisorDecoder._ensure_segment；音频设备解析见 audio_handler.py 设备名→索引路径

包内日志自证：自动体检的两条结论（S 表合成回退、按崩溃排查）都不成立 —— 真 FT4222 频谱在 19:23:30 已出首帧并连续跑了 84041 帧、音频停滞 9052 s 后当场自愈、Traceback 指向与电台无关的 Nano

support_bundle.py:summarize_log（S-meter fallback 判定应要求在整段日志中从未出现 `scope_pipe: first frame received` 才下结论；启动次数/时间跨度应取 min/max 时间戳并区分 `log.exception` 产生的 traceback）

服务端与电台状态完全正确（vfo_a_freq 已切到 14270000、IF 轮询一致、RX 音频正常），「显示 0000」只可能出在安卓端读数渲染/状态未刷新；包内没有客户端状态证据，另外该实例是 v1.28.0，含已在 v1.28.1

未定位到代码缺陷；若确认回归，落点在 FT710Android/app/src/main/java/com/hamradio/ft710android/Data/RadioState.kt:activeFrequency（只用 vfo_a/vfo_b + activeVfo，未用服务端派生 active_freq）与 UI/MainScreen.kt:FreqText/fmtMhz

IC-7300 的 FT8 模式在本版本一定失败：FT8 的电台适配层（ft8/platform/cat.py）把 FT-710 的滤波宽度表和模式寄存器表硬编码在里面，传给 IC-7300 后端的是无效的 FIL 槽位 18（IC-730

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_

决策备注：模型判定不涉及代码：重复上报 + 客户端版本落后，不是待改代码。(1) 代码已在 HEAD 修好：ft8/platform/cat.py 的 PlatformRig 新增 backend= 入参，_mode_map()/ _narrow_table() 从 backend.mode_name_to_num（兼容 property 与 method 两种形态）和 backend.filter_tab

那次发射是「零调制」而不是功率设置小：服务端一帧上行语音都没收到（frames=0/written=0/peak=0%），LSB 下 SSB 无调制即无射频功率；该签名与 v1.25.4 修过的「键控了却没有声音」同签名，当前 1.28.2

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

决策备注：模型判定不涉及代码：不应在此改代码，理由三条：① 归因不支持——线索指向的 _claim_tx_owner_for_token / _same_session_uplink_takeover 在当前 HEAD 完好，且其失败签名是 non_owner_drops 增长，与 frames=0 互斥，改它们只会重新引入 v1.25.4 之前的「同会话 socket 互相压音」缺陷；② 需要改的那一层是

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

server.py:_claim_tx_owner_for_token / server.py:_same_session_uplink_takeover（TX 上行归属；配套 _register_tx_socket/_forget_tx_socket）

决策备注：模型判定不涉及代码：1) 版本判据：CHANGELOG `[v1.25.4]`（CHANGELOG.md:869 起，915-921 行明确列出 `_claim_tx_owner_for_token` / `_same_session_uplink_takeover` 两条链并逐字节比对了源码包）才是该修复到达用户的版本，1.25.0–1.25.3 出这个签名是预期行为，不是回归；HEAD 的 s