接收器使用VISHAY-BPW34,硬件使用OSCA02X
硬件连接：
A通道 钩针钩正极，GND接接收管的地（接受面上有个点的为正）

大概这个样子

软件配置

开启channel A，关闭channel B
Channel A - 使能AC
时间设置为25us
电压调整为50mv
1X 1倍，钩针打到1X

触发配置
上升沿触发
单次触发，60mv触发

实际抓取效果
56kHZ

38kHZ

遇到这种“重启就恢复原样”的情况确实非常折磨人。这通常说明你的路由器在重启后，系统仍然试图加载一个损坏或不兼容的第三方主题，或者是你的系统配置无法永久保存（比如存储空间满了，导致每次重启都回滚）。

为了彻底解决这个问题，我们可以按照以下几个步骤进行排查和修复：

第一步：找出并卸载那个“惹祸”的主题
既然你必须切换回 bootstrap 才能打开网页，说明默认加载的那个主题是有问题的。我们需要把它彻底删掉。

先不要执行你的修复命令，在刚重启后（打不开网页的状态下），通过 SSH 登录，运行以下命令查看当前系统正试图加载什么主题：

Bash
uci get luci.main.mediaurlbase
记下输出的结果（比如 /luci-static/argon）。

查看当前安装了哪些主题：

Bash
opkg list-installed | grep luci-theme
卸载那个损坏的主题（假设坏掉的主题是 argon，请替换为你实际查到的名字）：

Bash
opkg remove luci-theme-argon
第二步：检查路由器存储空间（Overlay）是否已满
如果你的 uci commit luci 命令在执行时没有报错，但重启后依然无效，极有可能是路由器的可写分区（Overlay）已经满了（100%）。当空间满时，OpenWrt 无法保存新的配置，重启后就会丢失修改。

运行以下命令查看磁盘空间：

Bash
df -h
重点查看挂载点为 /overlay 或 / 的这一行，看 Use%（已用百分比） 是否达到了 100%。

如果是 100%：你需要清理空间，或者重置路由器。通常是因为安装了太多插件，或者系统日志占满了空间。可以尝试删除一些不用的插件来释放空间。

第三步：检查是否有开机自启脚本在“捣鬼”
有时候，某些一键安装包或固件自带的脚本会在开机时强制设置某个特定主题。如果该主题不存在或损坏，就会导致你现在的状况。

检查开机脚本 rc.local：

Bash
cat /etc/rc.local
看看里面有没有类似 uci set luci.main.mediaurlbase=... 的命令。如果有，用 vi /etc/rc.local 编辑文件，把那行删掉或注释掉（在行首加 #）。

检查自定义设置（如果你用的是某些定制版的固件，如 Lean 的 LEDE）：
去 /etc/uci-defaults/ 目录下看看有没有可疑的初始化脚本。

第四步：在 Web 界面中“彻底”保存并清理缓存
如果你通过命令行修复后进入了网页，建议在网页端再彻底保存一次，这有时能触发系统更新其他的关联配置文件。

执行你那三行命令，恢复网页访问。

清理系统中的 LuCI 缓存：

Bash
rm -rf /tmp/luci-modulecache/
rm -f /tmp/luci-indexcache
登录 OpenWrt 网页后台，进入 系统 (System) -> 系统属性 (System) -> 语言和界面 (Language and Style)。

确保主题下拉菜单中选择的是 Bootstrap。

点击页面底部的 保存并应用 (Save & Apply)。

整体架构（含RabbitMQ）
┌─────────────┐ ┌──────────────┐ ┌─────────────┐
│ 用户微信 │ │ 微信服务器 │ │ 你的后端 │
│ (小程序) │◄────►│ (公众号/ │◄────►│ (业务逻辑/ │
│ │ │ 小程序API) │ │ RabbitMQ │
└─────────────┘ └──────────────┘ └──────┬──────┘

                                                │
                                                │ 推送消息
                                                ▼

┌─────────────────────────────────────────────────────────┐
│ RabbitMQ 集群 │
│ ┌────────────┐ ┌────────────┐ ┌────────────┐ │
│ │ 登录消息队列│ │战绩上报队列│ │推送通知队列│ │
│ └────────────┘ └────────────┘ └────────────┘ │
└─────────────────────────────────────────────────────────┘

     ▲                    ▲                    ▲
     │ 消费登录指令        │ 消费战绩数据        │ 消费推送任务
┌────┴─────┐         ┌────┴─────┐         ┌────┴─────┐
│本地游戏   │         │本地游戏   │         │你的后端   │
│服务器A    │         │服务器B    │         │推送服务   │
└──────────┘         └──────────┘         └──────────┘
                                                │
                                                ▼
                                        ┌─────────────┐
                                        │  公众号     │
                                        │ 模板消息推送 │
                                        └─────────────┘
                                                │
                                                ▼
                                        ┌─────────────┐
                                        │  用户微信   │
                                        │ (聊天列表)  │
                                        └─────────────┘

策略 A：建立并定期更新《项目全局上下文 (Context.md)》
每当我们确定了一个核心模块（例如：数据解析逻辑或 UI 架构），你可以要求我总结一段“当前进度摘要”。

操作： 每次开启新话题或感觉逻辑变复杂时，你把这段摘要贴出来。

内容包括： 核心类名、数据协议格式、已解决的坑、下一步目标。

策略 B：模块化“投喂” (Modular Feeding)
不要一次性把 50 个 Java 文件全丢进来。

做法： 按照 数据协议 -> 数据流转 (Repository) -> UI 状态控制 (ViewModel) -> UI 渲染 (Compose/View) 的顺序。

优势： 我在每一阶段都会生成对应的 Kotlin 规范，后续对话中，我只需基于这些已确认的规范进行扩展。

策略 C：使用“核心逻辑锚点” (Logic Anchors)
在对话中，给你的特殊逻辑起一个唯一且具有辨识度的名字。

比如：ScoreboardProtocolV1 或 BoxDisplayManager。

当我表现出遗忘迹象时，你只需说：“请基于我们之前定义的 ScoreboardProtocolV1 来重写这个方法”，我会立即从上下文缓存中检索到相关定义。

1. 将LuCI主题设置回默认的bootstrap

uci set luci.main.mediaurlbase='/luci-static/bootstrap'

2. 保存配置

uci commit luci

3. 重启Web服务使更改生效

/etc/init.d/uhttpd restart