企业官网建设流程全解析

前几天我把桌上的脑电采集设备从 USB 线缆里解放了出来，搭了一条完整的无线 EEG 链路：脑电模块负责采集头皮信号，BW16 模块把串口数据转成 WiFi 数据流，另一端的 ESP32-CYD 一边在自带屏幕上实时画波形，一边作为一个小型 Web 服务器，把同一路波形推送到浏览器里。全程没有电脑参与，手机和笔记本连上热点就能看。

这条链路解决的是 EEG 实验里非常实际的问题：传统方案里脑电模块必须用线接着电脑，被测试者活动范围被限制在工位旁边，线缆本身还会成为工频干扰的天线，稍微一动波形就飘。这套原型把采集端和显示端彻底分离，无线传输距离在室内轻松覆盖十几米，屏幕端和网页端的波形基本同步，延迟在几十毫秒级别。文章会从硬件分工、两端代码、无线协议设计到实测排坑，完整复现整条链路。

适合正在做脑机接口入门、可穿戴设备原型验证，或者单纯想把某路传感器数据从串口里"搬"到 WiFi 上的人参考。不需要高深的背景，有一点 Arduino 基础就能跟下来。

1. 为什么非要把脑电模块搬上无线：从一根线说起

1.1 有线采集的麻烦，只有真做过才懂

脑电信号本身是微伏级别的生物电信号，幅度通常在 10~100 微伏，特别容易被环境电磁场污染。传统方案里，电极线、放大器的 USB 线、电脑的地线，构成了一根巨大的"天线"，50Hz 工频干扰和运动伪迹全都被耦合进来。你可以在软件里做 50Hz 陷波，但运动过程中线缆晃动产生的基线漂移和接触噪声，是后处理很难完全去掉的。

这时候最简单的物理办法就是：把线变短，让前端和数据接收端中间只隔空气。无线 EEG 采集的意义不只是"少一根线"，而是从源头上砍掉一大截干扰路径。被测试者戴上电极帽之后可以在房间里自由活动，甚至可以走到另一个房间，只要 WiFi 信号能穿透，波形就不会断。演示场景也更自然，给朋友展示脑电波形的时候，不用让人家坐那一动不动盯着屏幕。

1.2 这条链路到底解决了什么问题

整套系统的数据流是单向的：电极信号进入脑电模块，模块内部的模拟前端完成放大和 ADC 采样之后，通过 UART 串口以特定的数据帧格式输出。BW16 读取串口数据，通过 WiFi TCP Socket 发送出去。ESP32-CYD 作为 WiFi 接入点，接收数据帧，解析后在 TFT 屏幕上绘制滚动波形；同时在内部跑一个 WebSocket 服务，把原始采样值广播给所有浏览器客户端。

• 采集端是独立供电的，和接收端没有任何电气连接，彻底隔离。
• 显示端有两块"屏幕"——硬件屏和网页，两者显示同一路数据。
• 网页端可以同时被多台设备访问，适合课堂演示或者多人观看。
• 接收端没有用电脑，一个 ESP32 开发板全部搞定。

1.3 这条链路适合哪些场景

如果你只是想在桌面上看个波形，这条路确实绕远了。它的价值在于移动采集、多人观看、以及原型验证。我搭这条链路时的核心诉求是：在后续做 EEG 源定位和最小范数估计这类算法研究之前，先把数据采集的"最后一米"跑通，保证原始数据能实时、稳定地从电极帽到达算法端。对做 BCI 方向的学生、做可穿戴硬件验证的工程师，以及纯粹想玩玩脑电的极客来说，这条链路都是很好的基础架构。

2. 硬件选型：BW16 当搬运工，ESP32-CYD 当接收展示终端

2.1 两个芯片的分工逻辑

这套系统里两个核心硬件各司其职，没有重叠和冗余。

BW16 是瑞昱 RTL8721DM 方案的模组，双核 Cortex-M4 加 Cortex-M33，主频 125MHz，支持 2.4GHz WiFi 802.11 b/g/n 和 BLE 5.0。它的核心优势是：UART、I2C、SPI 等外设资源充足，Ameba Arduino 支持度好，用起来和普通 Arduino 几乎没区别，而且作为数据转发节点功耗不算高。它的任务非常纯粹：从串口扒数据，通过 WiFi 发出去，不干别的。

ESP32-CYD 的全名是 ESP32-2432S028R，核心是 ESP32-WROOM-32，双核 240MHz，板载 2.8 寸 320x240 TFT 触摸屏，SPI 接口，驱动 ILI9341。它需要同时干三件事：做 WiFi 接入点接收 BW16 的数据、驱动 TFT 屏幕画滚动波形、跑 WebSocket 服务器给浏览器推数据。ESP32 的双核架构在这里很合适，一个核跑 WiFi 协议栈和 Web 服务，另一个核处理屏幕绘制，任务分工清楚。

2.2 为什么不是 ESP32 直接采集，也不是蓝牙串口模块

有一种更精简的做法：在 ESP32-CYD 上直接接脑电模块的串口线，省掉 BW16。听起来更简单，但有几个实际痛点。CYD 的屏幕已经占了大量 GPIO，剩余的引脚位置布线很不方便；更重要的是，脑电模块的模拟前端和 ESP32 开发板的电源、地线离得太近，开关电源的纹波会直接串进微弱信号里。用 BW16 把采集端和显示端在物理上分开，其实是把信号完整性的问题用结构设计解决了，比在 PCB 上花心思做隔离省事得多。

蓝牙串口模块（比如 HC-05）也能做无线透传，但带宽和连接数都是硬伤。普通蓝牙串口模块的默认波特率下传输 512Hz 采样率、16bit 精度的单通道数据勉强够用，但只能一对一连接，网页端想同时让多台设备看波形就做不到。WiFi 方案天然支持多客户端，WebSocket 广播几乎是零成本实现的。

2.3 完整器材清单

你手里的脑电模块如果串口协议不同，只需要改 BW16 端的数据解析函数，其他部分完全不用动。

3. BW16 采集端实战：串口数据如何变成 WiFi 数据流

3.1 接线与电平问题

先处理物理连接。脑电模块输出的是 3.3V TTL 电平，BW16 的 UART 引脚也是 3.3V 电平，直接连接没有问题。接线方式：BW16 的 RX 接脑电模块的 TX，BW16 的 TX 接脑电模块的 RX（如果不使用模块的配置通道也可以只接一根 TX）。电源上，我用了锂电池接 LDO 降到 3.3V 给两个模块共电，实测纹波在可接受范围。如果手头电路接触不良，优先检查公共地有没有接好，串口通信的"地"比"信号"更重要。

一个容易忽略的细节是：脑电模块的 UART 波特率必须和 BW16 端配置一致。很多脑电模块默认是 115200 或者 57600，你要在数据手册里确认。我的模块是 57600，BW16 的 Serial1 初始化就用的这个值。如果你用的是 NeuroSky TGAM 这类模块，注意它输出的是标准脑电原始数据包格式，帧头是 0xAA 0x04，解析逻辑要按对应协议来写。

3.2 数据帧设计：不要直接透传，要加一层自己的协议

一开始我想偷懒，把串口收到的字节原封不动通过 WiFi 发出去，结果在接收端解析数据痛不欲生。WiFi 传输是流式的，TCP 会把你的数据切包、粘包，接收端根本分不清哪里是帧头。正确做法是：在 BW16 端设置一个固定长度的采样窗口，攒够一小批数据，加上自定义帧头、序列号、负载长度和校验，组装成一帧再发送。

我设计的帧格式如下：

这样一帧总长 26 字节（2+1+2+20+1），在 512Hz 采样率下每 20ms 产生一帧。接收端只要按帧头同步、按长度切帧、用校验和过滤损坏数据，就能干净地还原出原始采样序列。序列号则是排查丢包的关键依据，后面会细讲。

3.3 WiFi 传输：TCP 比 UDP 更省心

在局域网内传 EEG 数据，我用 TCP 而不是 UDP。原因很实际：脑电采样率只有 512Hz，每 20ms 一帧 26 字节的数据量，TCP 的吞吐完全够用，还能获得可靠传输和乱序重排。UDP 虽然实时性上限更高，但丢包后你要自己处理重传和排序，对只是做原型验证的项目来说纯属增加工作量。实测局域网内 TCP 的延迟非常低，完全满足实时波形显示需求。

// BW16 (Ameba Arduino) - EEG 数据转发核心逻辑 #include <WiFi.h> const char* ssid = "EEG-Link"; const char* password = "12345678"; const char* host = "192.168.4.1"; // ESP32-CYD 的热点 IP const uint16_t port = 8266; WiFiClient client; uint8_t rxBuf[64]; uint8_t frameBuf[32]; uint16_t seq = 0; void setup() { Serial1.begin(57600); // 接脑电模块 WiFi.begin(ssid, password); while (WiFi.status() != WL_CONNECTED) delay(100); client.connect(host, port); } void loop() { // 从串口读取原始字节，逐字节匹配帧头 int n = Serial1.available(); while (n-- > 0) { uint8_t b = Serial1.read(); if (findEEGFrame(rxBuf, b)) { // 在 rxBuf 中匹配到完整模块帧 packAndSend(rxBuf); // 攒够 10 个样本组帧并发送 } } } void packAndSend(uint8_t* samples) { frameBuf[0] = 0xAA; frameBuf[1] = 0x55; frameBuf[2] = 22; // 负载长度 frameBuf[3] = highByte(seq); frameBuf[4] = lowByte(seq); seq++; memcpy(&frameBuf[5], samples, 20); // 10 个 16bit 样本 uint8_t checksum = 0; for (int i = 0; i < 25; i++) checksum ^= frameBuf[i]; frameBuf[25] = checksum; client.write(frameBuf, 26); }

注意这里有一个重要的工程细节：BW16 端不要用delay()来控制发送节奏。脑电模块按照自身的采样时钟连续输出数据，BW16 只需要在串口缓冲区里取数据、攒满一帧就发。你用millis()定时取数，一旦系统调度抖动，就会出现采样间隔不均匀，波形上能看到明显的"毛刺"。让数据自身节奏驱动发送，是最稳定的方式。

3.4 低功耗与稳定性小窍门

采集端如果要做到头戴式供电，功耗是绕不开的话题。BW16 在持续 WiFi TCP 发送时电流约 100mA 左右，脑电模块大约 10mA，加起来 110mA。拿一块 800mAh 锂电池供电，实验两三个小时完全没问题。如果要做成长时间佩戴的版本，可以开启 WiFi 的 DTIM 节能模式让模块在数据间隙休眠，但要注意这会增加延迟，睡眠唤醒后的第一个包可能会迟到，是否值得要看你的应用场景。

还有一个非常容易被忽略的点：天线位置。BW16 模组的天线区域不要贴地线铜箔，也不要被金属外壳完全包裹。我第一次打样的铝合金外壳直接屏蔽了信号，丢包率飙升到 30%。把天线侧暴露在塑料外壳开孔处之后，问题立刻消失。

4. ESP32-CYD 接收端：屏幕波形绘制的几个关键细节

4.1 热点模式与 TCP 服务端

ESP32-CYD 这边要做的事情更多。首先它要建立一个 WiFi 热点，让 BW16 连上来。我设置了 ESP32 同时开启 AP 和 Web 服务，热点 IP 固定为 192.168.4.1。BW16 端连上热点后会向这个 IP 的 TCP 端口发起连接。

TCP 接入的解析逻辑要处理好"流式数据"的问题。WiFi TCP 收到的数据可能一次只有半个帧，也可能一次到了好几帧。我的处理方式是维护一个环形缓冲区，不断把收到的字节追加进去，然后循环尝试从缓冲区头部解析完整的 EEG 帧。只有校验通过、长度吻合，才把帧里的采样值提取出来写入波形缓冲区。

// ESP32-CYD 接收端 - TCP 数据解析 // 伪代码，关键是环形缓冲 + 帧同步的思路 uint8_t ringBuf[256]; uint16_t ringHead = 0, ringTail = 0; void onTCPData(uint8_t* data, size_t len) { for (size_t i = 0; i < len; i++) { ringBuf[ringHead] = data[i]; ringHead = (ringHead + 1) % sizeof(ringBuf); } while (tryParseFrame()); // 不断尝试解析完整帧 } bool tryParseFrame() { if (ringHead == ringTail) return false; // 缓冲区空 // 查找帧头 0xAA 0x55 // 校验长度、校验和 // 若成功：提取 10 个采样值到 waveBuf，返回 true // 若失败：跳过 1 字节，继续找下一帧 }

这里最怕的就是"死等一个完整帧"。如果缓冲区头部的字节是半个帧头，程序必须跳过它继续往后找，而不是阻塞等待。我之前用阻塞式解析，遇到 WiFi 丢包后整个程序卡死，波形直接不动了。

4.2 TFT 屏幕滚动波形怎么画才不闪

320x240 的屏幕，我划分了一个 320x160 的波形区，剩下区域显示采样值、丢包率和连接状态。波形绘制是滚动式的，新数据从右边出现，旧数据往左边移动。TFT_eSPI 库本身不含滚动波形功能，需要自己实现。

最简单的滚动画法：每次来新帧，先把整个波形区左移若干像素，再把新采样绘制在最后一列。实现上有两种做法：

做法一是用fillRect把最左侧一列擦掉，然后把之前的所有列重新画一遍。这个方法代码最简单，但刷新率略低，实测 512Hz 采样约 25fps 的刷新率下，能看到画面轻微闪烁。

做法二是"移动屏幕窗口"。TFT_eSPI 支持通过setScrollMargins和scrollTo实现纵向滚动，但横向滚动没有直接 API。我最终用了另一种方案：双缓冲区。在内存里维护一个 320x160x2 字节的波形位图，每次新数据到达时，在内存里把位图左移一列，然后把新采样值画到最右列，最后通过pushImage一次性把整块位图推到屏幕上。这个方法比逐像素fillRect快得多，实测刷新率稳定在 30fps 以上，画面干净不闪烁。

// 双缓冲滚动逻辑 void updateWaveform(int16_t newValue) { memmove(waveCanvas, waveCanvas + 2, (320 - 1) * 160 * 2); // 在 waveCanvas 最右列绘制 newValue 对应的线段 drawLineToRightColumn(waveCanvas, newValue); tft.pushImage(0, WAVE_Y, 320, 160, (uint16_t*)waveCanvas); }

这里有个细节：memmove是内存拷贝，320x160x2 字节约 100KB，ESP32 的 SRAM 足够；但要在空闲任务里做，不能在 WiFi 中断回调里做。我把解析和绘制拆成两个任务，解析任务只负责往队列里放采样值，绘制任务从队列里取数据刷新屏幕，CPU 双核正好干这事。

4.3 刷新率与屏幕撕裂问题

测了一下实际刷新率，屏幕绘制大约 31fps，也就是每 32ms 刷新一屏。比起专业脑电软件动辄 60fps 的实时刷新，这个数值不算高，但用于波形形态观察足够了。屏幕撕裂现象在某些帧频率下会出现：上半屏和下半屏显示的不是同一时刻的数据。双缓冲天然解决撕裂，因为pushImage是在一帧时间内一次性把完整位图推到屏幕的，不存在上下分屏。

如果你坚持不用双缓冲，也有一个折中方案：只在数据到达时刷新屏幕的四分之一区域，让撕裂现象限于局部。但我建议直接上双缓冲，代码量没多多少，体验完全不一样。

4.4 显示内容和状态监控

屏幕除了波形，我还显示了三行状态信息：实时采样值、帧序列号、错帧计数。序列号一旦跳变，说明 WiFi 链路丢包了；校验失败计数增加，说明数据帧被破坏。屏幕上实时看到这些指标，比事后用串口调试省事很多。我后来排查 WiFi 干扰问题时，就是靠屏幕上的丢包率数字定位了天线位置的问题。

5. 网页端实现：让手机和电脑浏览器看到同一路波形

5.1 为什么选 WebSocket，而不是 HTTP 轮询

接收端除了画屏幕，还要把数据送到浏览器。两种方案：HTTP 轮询和 WebSocket。HTTP 轮询就是浏览器每隔几百毫秒向服务器请求一次最新数据，实现简单，但延迟高，而且客户端多了之后 HTTP 请求会挤占 TCP 连接资源。WebSocket 是长连接，服务器有数据就主动推给浏览器，端到端延迟低，多客户端共享一条数据通道也很自然。

实测对比：HTTP 轮询在 200ms 间隔下，肉眼可见波形有"跳格感"；WebSocket 推送下波形和屏幕端几乎同步，浏览器端延迟大约 30~50ms，完全够实时监控使用。

5.2 ESP32-CYD 上的 Web 服务器搭建

ESP32 端我用了 ESP32 Arduino 生态里的WebServer库提供静态页面，WebSocketsServer库处理 WebSocket 连接。静态页面直接编译成字符串存放在 Flash 里，浏览器访问http://192.168.4.1就能加载页面和 JavaScript 代码。WebSocket 端口单独开一个 8266 之外的端口，比如 8080，避免和 TCP 数据端口冲突。

// ESP32-CYD - WebSocket 数据广播 WebSocketsServer webSocket(8080); void setup() { // ... 热点启动、TCP Server 启动 ... webSocket.begin(); webSocket.onEvent(webSocketEvent); } void loop() { webSocket.loop(); // 当波形队列有新采样时，构造二进制消息并广播给所有客户端 if (newSampleAvailable) { uint8_t msg[4]; msg[0] = 0xAA; msg[1] = highByte(sampleValue); msg[2] = lowByte(sampleValue); msg[3] = 0x55; webSocket.broadcastBIN(msg, sizeof(msg)); } }

WebSocket 的二进制消息里，我直接塞了原始采样值，不做过多的 JSON 封装。二进制的解析开销小，对 Canvas 绘制更友好。如果你要传的数据结构复杂（多通道、带时间戳），再考虑 JSON。

5.3 前端 Canvas 滚动波形绘制

网页端的 JavaScript 核心是维护一个采样值环形数组，收到 WebSocket 二进制消息后，先做字节序转换（ESP32 是小端模式，JS 端 ArrayBuffer 的 DataView 要按小端读取），把采样值追加到数组尾部。绘制时用 Canvas 2D 的putImageData做整幅滚动，原理和 TFT 端双缓冲一模一样。

// 前端简化逻辑 const ws = new WebSocket('ws://192.168.4.1:8080'); const canvas = document.getElementById('waveform'); const ctx = canvas.getContext('2d'); const imageData = ctx.createImageData(320, 160); let offset = 0; ws.binaryType = 'arraybuffer'; ws.onmessage = (event) => { const view = new DataView(event.data); // AA 55 前处理 const value = view.getInt16(1, true); // 小端 16bit // 将 imageData 整体左移一像素，把 value 画到最右列 scrollCanvas(imageData, value); ctx.putImageData(imageData, 0, 0); };

5.4 手机和平板的适配

CYD 的热点默认 IP 是 192.168.4.1，手机连上热点后浏览器直接访问这个地址即可。页面里的 Canvas 宽度我用固定 320px，和 CYD 屏幕一致，但手机上可以用 CSS 缩放适配整个屏幕。实测 iPhone、安卓手机、笔记本都能正常打开，只要浏览器支持 WebSocket，无需插件。

有个小技巧：为了让网页端波形显示比例协调，我在前端把采样值做了二次缩放——屏幕上显示的是原始 ADC 值直接映射到 160 像素高度；网页端我加了自动幅度调节，根据最近 100 个采样点的最大最小值动态调整纵轴范围，这样波形不会一上来就顶到上下边缘。音频设备上的 AGC（自动增益控制）干的是类似的事，人耳听感舒服，波形看起来也舒服。

6. 实测数据与问题排查：延迟、丢包、干扰一个都没少

6.1 实测性能指标

ESP32 和 BW16 之间是 TCP 连接，所以"丢包"的真正含义是重传带来的延迟，而不是数据彻底丢失。波形上偶尔会出现一个"台阶"，其实是延迟抖动造成的采样点到达间隔不均匀，不是真正的丢点。

6.2 踩过的坑：TCP 粘包与半包

这个问题几乎每个做 WiFi 透传的人都会碰到。TCP 是流式协议，底层可能把两个数据包合并成一个包发送，也可能把一个包拆成两次发送。如果接收端直接按"收到一次数据就是完整一帧"来解析，大概率会出错。我的解法就是前面提到的环形缓冲区加帧头同步，无论底层怎么粘、怎么拆，接收端都能从字节流里正确切出每一帧。帧头 0xAA 0x55 的选取也有讲究：EEG 采样值本身不会频繁出现 0xAA 0x55 连续组合，误同步概率低；如果连续多帧校验失败，就主动丢弃这个可疑帧头重新同步。

6.3 踩过的坑：WebSocket 莫名断开

浏览器端的 WebSocket 连接会间歇性断线，尤其在手机浏览器锁屏再解锁之后。原因通常是浏览器的省电策略切断了后台 WebSocket。处理方式：前端在onclose事件里自动重连，重连间隔 1 秒；ESP32 端对每个 WebSocket 客户端做了活跃时间检查，超过 30 秒没收到 ping 就主动释放连接。这样即使客户端断线，用户刷新页面或者重新打开浏览器，几秒内就能恢复波形显示。

6.4 踩过的坑：工频干扰隔空传染

虽然采集端和接收端没有物理连线，但两边的电源插头仍然来自同一个市电网络，50Hz 干扰依然可能通过空间辐射耦合。实际测试发现，当 ESP32-CYD 的充电器离脑电模块电极线较近时，波形上能看到明显的 50Hz 正弦叠加。解决方案有三个，按效果优先级排列：

• 把采集端和电极线尽量远离任何电源适配器，保持 30cm 以上距离。
• 采集端电池供电时，优先用线性 LDO 而非开关电源，开关电源的纹波频带更宽更容易耦合进微弱信号。
• 软件上做 50Hz 陷波滤波器，我在 BW16 端没有做，而是在 ESP32 端用一个简单的 IIR 陷波器滤掉 50Hz 分量，再送去画波形和推网页。但要注意陷波器本身会带来相位延迟，如果你是做数据记录的，一定要保存原始采样值，滤波数据只用于显示。

6.5 判断链路是否健康的一把尺子

这条链路我给自己的"体检标准"就是中帧序列号。BW16 端每一帧都有递增的序列号，ESP32 端解析后统计"收到序列号和期望序列号的差值"。差值为 0 说明链路完美；差值大于 0 说明发生了 TCP 重传，差值里面有空洞。我把这个数字显示在 CYD 屏幕上，长时间跑下来基本稳定在个位数以内。如果你的场景里差值持续增长，优先排查 WiFi 信道拥挤问题，给 ESP32 热点换一个空闲信道，比如从 1 换到 6 或者 11，效果立竿见影。

7. 这套链路还能往哪些方向扩展

7.1 从单通道到多通道

单通道只是验证链路，真正做脑电分析通常需要 8、16 甚至 32 通道。BW16 的串口资源足够扩展多路脑电模块，但带宽要重新算一笔账。32 通道、512Hz 采样率、16bit 精度，原始数据率是 32 x 512 x 2 = 32KB/s，TCP 完全扛得住，但 ESP32-CYD 侧的解析和屏幕绘制压力会变大。屏幕刷新建议从整屏滚动改成只显示其中几个通道，或者把数据全部推给网页端，屏幕只做状态监控。

7.2 加入数据记录功能

脑电实验的数据记录非常关键。目前链路里数据是实时流水，没有落盘。后续可以在 ESP32-CYD 上挂一张 MicroSD 卡，把解析出来的原始采样值和序列号写入 CSV 或者 BDF 格式文件。这样实验结束之后还能离线做源定位、最小范数估计等分析，不依赖在线处理链路。

7.3 脑电源定位和更高层分析的对接

这条链路最终喂给算法的数据格式是干净的原始采样序列，这意味着它可以直接对接 EEG 源定位、最小范数估计、事件相关电位分析等后续处理。实时网页只是链路的前端可视化，真正的价值在于：你有了一个随时随地能提供干净 EEG 数据流的无线管道。管线后面的算法想怎么折腾都行。

从我个人的实际操作感受来说，这套链路最难的不是任何一段单独的技术，而是把四段串在一起时保持节奏一致：采样时钟、WiFi 传输、屏幕刷新、网页推送，每一环的定时抖动都会在最终波形上留下痕迹。好在这条链路每一环的时序约束都比较宽松，只要掌握好"数据驱动发送"和"缓冲区分帧"这两个原则，就不会出大问题。

最后分享一个小技巧：整套系统调试的时候，先用一个简单的正弦波信号源代替真实的脑电模块做联调，确认 BW16→CYD→屏幕和网页整条链路的数据一致性和波形正确性之后，再接上脑电模块。否则一旦波形异常，你根本分不清是生物电信号本身的问题，还是无线链路的问题。信号源测试十分钟，能帮你省下一下午的排错时间。