脑机接口、EEG 可视化、注意力监测，这几年被开源项目和短视频带火了不少，但大部分教程都停在“模块能出波形”这一步。真正拿一块脑电模块，想做成从传感器到屏幕、再到网页的完整无线链路时，很多人会卡在三个地方：数据协议怎么解析、无线模块怎么配置、多端显示怎么同步。我最近用手头闲置的入门级脑电模组、一颗 BW16 WiFi 模块、一块 ESP32-CYD 彩屏开发板，把这条链路完整跑通了。简单说就是：脑电模块把原始数据从串口吐给 BW16，BW16 通过 WiFi 以 UDP 方式广播到局域网，ESP32-CYD 同时扮演两个角色——在 2.8 寸彩屏上画实时波形，并作为 WebSocket 服务端把同一份数据推给浏览器。整条链路不需要电脑参与，手机、平板、PC 打开网页就能同步看波形。这篇文章就把当时的选型思路、协议解析、无线配置、屏幕驱动、WebSocket 转发、联调排错全部沉淀下来。适合想动手验证脑机接口原型的嵌入式玩家、生物医学工程学生，以及任何对 EEG 波形可视化好奇的开发者。
1. 链路设计：为什么是“脑电模组 + BW16 + ESP32-CYD”三段式
1.1 这条链路到底解决什么问题
一个常见的误解是：EEG 原型验证无非就是把模块用杜邦线接到电脑上，打开串口助手看十六进制数据。但如果是想做一个“可戴在头上、能现场演示、还能让围观的人用自己手机看波形”的原型，单纯的串口方案就完全不够用了。我这次做的链路，本质上是把一台脑电图机拆成三个独立部件：头戴端负责采集和无线发送，显示端负责本地实时波形，网页端负责多设备同时查看。
用生活化的比喻来说，这就像把医院里那台大设备拆开——头上戴一个轻量采集器，房间里放一台显示器，所有家属的手机都能打开同一个网页看波形。这里的 BW16 就是那个“头戴端”的通信中枢，它体积小、功耗低，可以直接挂在脑电模块旁边，通过 WiFi 把数据送到局域网。ESP32-CYD 则是“房间里的显示器”，它自带屏幕和触摸，省去了自己去焊一块 LCD 面板的功夫。网页端则是“所有参会者的手机”，不用装任何 App，浏览器打开设备 IP 就能实时查看。
这条链路最有价值的点在于：它把“采集、传输、显示、多端分发”四个环节彻底解耦。任何一个环节出了问题，都能独立定位。比如波形不对，可以直接把 BW16 断开，用串口线把脑电模块接回 PC 验证；网页端打不开，也不影响屏幕端继续显示。这种可拆分结构，是做原型验证时最舒服的调试方式。
1.2 每个节点怎么选，为什么这么选
先看链路里三个硬件节点：脑电模组、BW16、ESP32-CYD。每个节点都有替代方案，我把我当时的对比选择和理由整理在下面。
| 节点 | 可选项 | 最终选择 | 理由 |
|---|---|---|---|
| 脑电采集 | 芯片自研模拟前端、模块成品 | 入门级 TGAM 协议兼容模组 | 协议公开、社区资料多、自带注意力和冥想数值，省去自己写滤波和特征提取 |
| 无线传输 | ESP8266、BLE 模块、BW16 | BW16 | 双模 WiFi+BLE、体积小、低功耗，天线净空好处理；核心逻辑其实也可以迁移到 ESP8266 |
| 显示端 | 裸 ESP32 + 外接屏、ESP32-CYD | ESP32-CYD | 自带 2.8 寸彩屏、触摸、TF 卡槽，一块板子搞定，省去排线焊接 |
| 多端展示 | 蓝牙直连手机 App、网页 | WebSocket 网页 | 浏览器免安装，支持手机/平板/电脑同时打开，适合教学和演示 |
这里解释两个关键决策。第一，为什么中间一定要加一个 BW16，而不是把脑电模块直接接到 ESP32-CYD 上？因为 ESP32-CYD 是一块带屏幕的大板子，放在桌面上没问题，但想做成戴在头上的可穿戴原型就不现实了。BW16 那一端可以做到很小，和脑电模块一起放在头戴支架上，ESP32-CYD 留在桌面当显示终端，这就符合真实可穿戴系统的形态。第二，为什么网页端用 WiFi 而不是 BLE？BLE 的实时性和多连接能力都不够理想，Web Bluetooth 还需要 HTTPS 和用户手势，演示现场反复授权很扫兴。WiFi + WebSocket 是最直接、最稳、跨设备兼容性最好的组合。
顺便说一句，如果手里没有 BW16，用 ESP8266 也一样能跑通这套链路，只是 ESP8266 的串口缓冲区小一些，高数据量下要更注意攒包策略。这也说明这套架构里的核心经验不在某块特定板子上，而在“串口字节流怎么变成 UDP 包，再变成网页数据”这一整条搬运路径上。
2. 脑电数据怎么变成无线包：串口协议与 BW16 配置
2.1 入门级脑电模组的输出协议，先搞懂再接线
脑电模组和普通传感器最大的区别在于，它吐出来的不是“一个数值”，而是连续不断的原始波形采样流。我用的这块 TGAM 协议兼容模组，默认串口波特率是 57600，8 个数据位、1 个停止位、无校验。模块以大约 512Hz 的采样率输出原始脑电波形，同时还周期性地输出注意力和冥想两个特征值。
数据帧结构需要重点说清楚，因为解析代码和数据校验全部依赖它。每一包数据的开头是固定的两个字节 0xAA 0xAA，第三个字节是载荷长度，载荷内部的第一个字节通常是数据类型标识。常见的类型有：0x80 代表原始脑电波形采样，0x04 代表注意力/冥想特征值，0x02 代表信号质量。原始波形采样是每 3 个字节组成一个 24 位有符号整数，需要自己判断符号位后转换成 int32，才能得到真正的波形幅度。
校验规则也很经典：从开头第一个 0xAA 开始，把包头、长度、载荷所有字节求和，取低 8 位后再求反码，结果应该等于校验字节。换句话说，接收端把一包数据全部字节累加（包括校验字节），低 8 位如果能和 0xFF 对得上，就说明这一包有效。实际调试时我踩过一个坑：只做帧头同步、不做校验和验算，结果偶发的串口错误位会直接变成波形上的尖峰毛刺，看起来像真实脑电，其实是脏数据。
所以我的建议是：别急着接 BW16，先用 USB 转 TTL 把脑电模组接到电脑上，用串口调试助手看原始十六进制流。确认能看到连续的 AA AA 开头的数据包，再继续往下走。这一步能过滤掉大量后续排查工作——很多所谓的“无线传输丢包”问题，根源其实在脑电模组的供电不稳或 TX 引脚接触不良。
2.2 BW16 的无线配置实测
BW16 是瑞昱 RTL8720DN 方案的 WiFi + BLE 双模模块，常见型号带一个串口。我这边用的是 AT 固件，配置思路是先把模块的串口波特率从默认值改到和脑电模组一致的 57600，然后连接 WiFi，最后开启“串口到 UDP 的透传桥接”。配置完成后，脑电模组的 TX 接 BW16 的 RX，两边的 GND 必须共地，这样脑电模块吐出的每一个字节都会被 BW16 原样封装成 UDP 包，发到局域网里指定的 IP 和端口。
AT 指令的具体写法，不同固件版本会有差异，这里给一个我当时用的大致流程：
# 先用 USB 转 TTL 以默认波特率连接 BW16，确认能收到回显 AT # 修改当前串口波特率为 57600 AT+UART_CUR=57600 # 连接 WiFi，替换成你自己的 SSID 和密码 AT+WJAP=MyWiFi,password # 开启到指定 IP 和端口的透传桥接，这里假设 ESP32-CYD 的 IP 是 192.168.1.100 # 注意：具体指令名和参数个数以你手里固件的 AT 指令手册为准 AT+UART_BRIDGE=on,192.168.1.100,8888配置完把 USB 转 TTL 拔掉，让脑电模组直接接管 BW16 的串口。这一套流程看起来简单，但实际有几个非常隐蔽的坑。第一，BW16 的 AT 指令对回车换行要求严格，有些固件还要在发 AT 之前先发一个空行，否则模块不响应。第二，如果 AT 固件版本里没有透传桥接指令，就需要刷一个 Ameba Arduino 自定义固件，核心逻辑很简单，就是串口读一个字节、UDP 写一个字节，或者攒够一段长度再批量发送。
我实际测试下来，攒包长度对稳定性的影响非常大。脑电模组是连续 512Hz 数据流，如果 BW16 每收到一个字节就立刻发一个 UDP 包，WiFi 协议栈的开销会把实际吞吐拖垮，丢包率明显上升。把缓冲区攒到 16 到 32 个字节再统一发送，丢包率会有肉眼可见的改善。原因也很直接，UDP 包本身有 42 字节的 IP 头开销，小包太多等于把带宽浪费在头部而不是数据上。
3. 接收端实现：ESP32-CYD 的屏幕波形与网页双输出
3.1 先确认 CYD 的引脚，别急着接线
ESP32-CYD 这个板子，说的是 ESP32-2432S028R，带一块 2.8 寸的 ILI9341 屏幕和 XPT2046 触摸屏。虽然它在淘宝上卖得很火，但有一个让人头疼的问题：不同批次、不同店铺出的板子，丝印标注可能略有差异。我建议先不看网上的引脚图，直接对着自己手上的板子背面丝印确认一遍，尤其是屏幕和触摸的 CS 引脚。
我这边用的引脚对应关系是：屏幕 CS 接 GPIO5，DC 接 GPIO2，RST 接 GPIO4，BL 接 GPIO21，MOSI 接 GPIO23，SCLK 接 GPIO18；触摸 CS 接 GPIO32，IRQ 接 GPIO36。这个组合在 Arduino_GFX 和 TFT_eSPI 两套库里都能正常工作。库的选择上我更推荐 Arduino_GFX，它对这类成品板卡的适配更好，只需在初始化时传入引脚号，不用改配置文件。
有一个特别容易忽略的坑：BL 引脚不拉高，屏幕就是黑屏。很多第一次玩 CYD 的人以为是屏坏了，其实是背光没开。此外，触摸的 CS 和屏幕的 CS 不能接反，接反的症状是屏幕显示正常但触摸完全没反应，或者反过来。这些细节在实物上对照丝印一遍就能避免。
3.2 从 UDP 包到波形：接收解析和画图
ESP32-CYD 上电后，先连接 WiFi，然后启动一个 UDP 监听，端口和 BW16 透传时指定的端口保持一致。收到 UDP 包后，逐字节做帧同步：找到 0xAA 0xAA 开头的帧，读取长度字节，再根据数据类型解析内容。解析过程中最重要的纪律是：校验和不对的帧直接丢弃，绝不能用半残数据画波形。
原始波形数据解析的逻辑需要注意补码转换。每个采样点占 3 个字节，需要先拼出一个 24 位整数，再判断最高位符号位，如果是负数要填充高位扩展成 int32，否则波形会跳变。这一步代码不复杂，但容易在符号扩展上出 bug，我调试时见过波形整体错位，就是这个原因。
屏幕刷新策略是另一个决定体验的关键点。脑电采样率 512Hz，如果不加处理直接每采到一个点就重绘，ESP32-CYD 的 CPU 会被绘图完全占满。我最终采用的方案是：每收到 8 个原始波形采样点，也就是大约 15.6ms 一次，画一条连接上一批最后一个点和本批最后一个点的线段；画面中间留一条垂直参考线，超过参考线的部分整列擦除。实际操作里，200ms 刷新一次滚动窗口就足够肉眼观看了，CPU 占用率比逐点刷新低很多，还能腾出资源跑 WebSocket 服务。
波形画完之后，顶部还要留出信息栏。我在左上角显示 Attention 数值，右上角显示 Meditation 数值，左下角用红色显示信号质量差时提示“POOR SIGNAL”。这个信息栏看起来简单，但对演示非常关键——围观的人不用看懂波形，只看注意力数值变化就能理解系统在工作。
3.3 网页端 WebSocket 怎么做
屏幕端只是第一路输出，网页端是这套链路的第二路输出，也是我觉得最有意思的部分。ESP32-CYD 上跑一个 WebSocketsServer，监听 81 端口，浏览器通过 ws://设备IP:81 连接。数据转发不能太频繁，否则浏览器解析 JSON 的负担会很大。
我这里采用的策略是：屏幕端每解析完一批数据，就把最新的 8 个原始波采样点、注意力值、冥想值和信号质量打包成一个 JSON 对象，通过 WebSocket 广播给所有连接的浏览器。JSON 结构类似这样：
{ "eeg": [1, 56, 122, 103, -12, -80, 90, 44], "attention": 56, "meditation": 72, "signal": 0 }网页前端拿到数据后，用 canvas 绘制滚动波形，用普通 HTML 元素更新数值。绘制频率不一定要和 WebSocket 消息频率完全一致，可以用 requestAnimationFrame 控制绘图节奏，把收到的数据先存到环形缓冲区里，每次动画帧只绘制最新的若干点。这样就算 WebSocket 消息偶尔延迟，画面也不会跳帧。
我实测下来，浏览器端做到 20ms 到 50ms 的数据更新间隔，人眼看已经是“实时”的感觉了。更快的刷新率在演示场景下没有实际意义，反而会增加网页端的 CPU 占用。需要提醒的是，网页端必须在同一个局域网内，ESP32-CYD 的 IP 可以通过串口日志打印，也可以把 IP 直接放到网页标题里方便别人输。
4. 整链路联调与延迟观察
4.1 端到端联调的四个步骤
全链路第一次联调，我强烈建议分四步走，每一步只改一个变量。第一步，有线验证：脑电模组用 USB 转 TTL 接电脑串口助手，确认原始帧完整。第二步，无线单链路：把 BW16 配置好，ESP32-CYD 不画屏，只用串口打印收到的 UDP 字节数，确认无线搬运没丢包。第三步，屏幕验证：断开网页端，只做屏幕波形显示。第四步，加上 WebSocket，全链路跑通。
这个顺序的核心逻辑是尽早压缩问题域。如果一上来就是无线 + 屏幕 + 网页一起跑，出了问题你根本不知道是串口协议错了、WiFi 丢了、屏幕刷慢了还是 WebSocket 写崩了。我第一次做类似项目时吃了这个亏，折腾了一个晚上才发现只是 BW16 的波特率没改过来，无线部分压根没参与。从那以后我形成习惯：无线链路单独用一个极简的“回环测试”验证——BW16 串口接一个 USB 转 TTL 发字符串，看 ESP32-CYD 能不能收到并打印，收到之后再接脑电模组。
联调过程中还要注意 ESP32-CYD 的供电。屏幕亮起来之后电流不小，如果用一个品质一般的 USB 充电头供电，WiFi 开机会导致瞬时压降，可能导致 ESP32 重启。我用的是带 2A 输出的充电头，实测稳定。
4.2 延迟实测到底怎样
延迟这个问题，很多教程都含糊带过。我实际测下来，数据从脑电模组的 TX 引脚到浏览器页面渲染出来，中间大概分成三段。
第一段是 BW16 从串口攒包到 UDP 发出，这一段的延迟取决于攒包长度。我设置 32 字节攒包时，最坏情况要等约 62ms，因为 512Hz 采样率下每个字节大约 2ms。如果对实时性要求高，可以改小攒包长度到 8 字节，延迟能压到 20ms 以内，但丢包率会上升。第二段是 UDP 在局域网内的传播，一般就是 1ms 到 5ms。第三段是 ESP32-CYD 解析、WebSocket 转发、浏览器渲染，这部分我实测在 50ms 到 100ms 之间，主要耗时在浏览器 canvas 绘制。
整体下来，从人眼感知角度，屏幕端波形基本是“零延迟”，网页端会有小半秒的视觉滞后，但用来观察波形趋势和注意力数值完全够用。这里有一个重要的判断标准：如果要做脑电控制的实时交互，比如用注意力控制小车方向，那这个延迟就得进一步压缩，需要把采样点合并成每 4 个一批发送，网页端也改成增量绘制。但如果只是做演示、教学、数据记录，150ms 以内的延迟完全可以接受。
我还建议在 UDP 数据包里加一个简单的包序号字段。接收端统计相邻包序号之间的差值，就能算出丢包率。这个功能看起来不起眼，但在调优 BW16 的攒包长度和 WiFi 信道时，有它和没它完全是两个效率水平。
5. 常见问题与排查技巧实录
5.1 五个高频问题及处理
把这次操作中遇到的典型问题列个速查表，按症状、可能原因、解决办法整理如下，方便以后直接查。
| 症状 | 可能原因 | 解决办法 |
|---|---|---|
| 网页端波形全是乱码毛刺 | 波特率不匹配、解析时校验失败未丢弃 | 重新确认 57600 波特率；解析逻辑里强制校验和 |
| 屏幕黑屏但有数据 | BL 背光引脚没拉高 | GPIO21 输出高电平 |
| 屏幕有波形但网页无数据 | WebSocket 服务未启动、浏览器缓存旧页面 | 刷新页面、关闭后重开；检查 81 端口是否监听 |
| 过一会儿数据就停 | BW16 串口缓冲区溢出、无线丢包严重 | 调大攒包长度；检查天线遮挡；靠近路由器 |
| 注意力数值恒为 0 | 信号质量差、模块没贴紧头皮 | 确认电极与额头接触，观察 POOR SIGNAL 值 |
第一个问题在调试中出现频率最高。脑电模组和 BW16 之间如果不共地，串口信号完全没有参考电平，波形就是一片乱码。另外，USB 转 TTL 模块的 TX 电平和脑电模组的 RX 电平也可能不匹配，有些便宜模块用的是 3.3V TTL，如果脑电模组是 5V，就得加电平转换或者确认模块自身是否兼容。
网页端连不上还有一个隐蔽原因：ESP32-CYD 连接 WiFi 后拿到的 IP 是动态分配的，如果你把 IP 硬编码在网页代码里，路由器重新分配后就会失效。我在串口开机日志里打印了实际 IP，网页端连接时直接看日志，省去很多无效排查。
5.2 排查经验与避坑
最后分享几个比较杂但很实用的经验。
第一，用逻辑分析仪或者双 USB 转 TTL 搭一个“串口分流观测点”。把脑电模组的 TX 同时接到 BW16 的 RX 和一个 USB 转 TTL 的 RX，一边让 BW16 正常发送，一边在电脑上实时观测原始数据。这样能直接分辨是“无线之前数据就错了”还是“无线之后才错的”。我遇到过一次非常迷惑的情况：屏幕上波形偶尔有跳变，网页端却始终正常，最后发现是 ESP32-CYD 的屏幕 SPI 总线和 WiFi 共存时偶发冲突，和无线传输完全没有关系——如果少了分流观测，这种排查会绕很远。
第二，电源策略要特别讲究。脑电信号本身是微伏级别的，对电源噪声极其敏感。如果脑电模组和 ESP32-CYD 共用一个 USB 电源，屏幕背光的 PWM 噪声会通过电源线串进脑电信号，表现出来就是波形里多了一层规律性的毛刺。我的做法是：脑电模组和 BW16 这一端用锂电池单独供电，ESP32-CYD 用 USB 供电，两边只通过无线联系，不共地。这也是头戴式可穿戴最接近真实形态的供电方式。
第三，2.4G WiFi 信道干扰的问题。实验室里各种蓝牙设备、无线鼠标、甚至微波炉都在用 2.4G Hz 频段，路由器默认自动选信道可能正好撞上一个特别挤的信道。我测试时手动把路由器信道固定在 1 或 11，丢包率明显下降。这个操作不用改代码，但往往比调程序更有效。
第四，给工程留后路。BW16 的串口除了接脑电模组，我还留了一个 TX/RX 互换的线序接法在排针上没焊死。这样调试时可以用 USB 转 TTL 随时接管 BW16 重新配置，不用反复拆线。头皮电极的佩戴也是个细节，脑电模组的接地参考点如果悬空，信号质量会一直报差，得把参考电极贴在耳垂或额头侧面。
如果让我重来一次，我会先用串口线把脑电模组接电脑，确认原始帧完整，再谈无线；而且一定会在第一个版本里就把丢包率统计做进去。后续我打算把 BW16 端改成纽扣电池供电的小板子，做成真正能戴在头上的原型；网页端再加一个 FFT 频谱图，把 alpha 波、beta 波分量画出来。这套链路里最值钱的经验不是哪一块板子，而是“串口到 UDP 再到 WebSocket”这一整套数据搬运动作，理解清楚之后，换任何传感器都能马上迁移。
