如果你做过脑电采集的原型实验大概率经历过这种尴尬电极已经贴好被测试者坐在椅子上不敢乱动而为了看波形你得歪着头去够桌上的屏幕或者把笔记本架在旁边。线一多人站起坐下都得小心翼翼。这个痛点直接促成了我这条链路用一个脑电前端模块把人头皮上的微弱信号变成数字流交给 BW16通过 Wi-Fi 送出去接收端用一块 ESP32-CYD既在本地 TFT 屏上画实时波形又顺带开一个网页让手机和电脑能同时看到数据。整套链路跑通后脑电数据从必须插线变成了随手可看。这篇文章就记录我从零搭这条无线 EEG 原型链路的全过程包括硬件选型、通信协议设计、屏幕绘制、网页推送以及中途踩过的那些坑。如果你正在做 BCI/脑电硬件原型、生物电采集或者只是想在 ESP32 上做实时波形显示这篇的思路可以直接复用。1. 为什么非要无线这条原型链路想解决的问题1.1 有线方案的三个痛点最初我用的是最朴素的做法脑电模块通过 USB 转串口直接连电脑在电脑上开一个串口绘图工具看波形。看起来简单实际上问题很多。第一个痛点是实验场景被固定死。脑电采集本身就需要被测试者保持相对放松的状态但一根 USB 线把人和电脑绑在一起稍微离远一点就得加延长线延长线一加干扰和压降都是麻烦。第二个痛点是数据转发路径单一。电脑作为唯一接收端其他人想看实时波形只能挤在屏幕前面或者我再开一套远程桌面延迟和画质都不理想。第三个痛点是布线本身会引入工频干扰。虽然是数字信号但线材在长距离传输时更像一根天线50Hz 及其谐波很容易串进来后期滤波要多做不少工作。无线方案正好把这三个痛点一起解决。发送端跟着人走接收端可以放在任意位置网页推送天然支持多人同时查看短距离无线传输省掉了那根长线干扰源少了一个。对原型验证来说这已经足够划算。1.2 一条链路到底要拆成几个环节我在动手之前先把链路拆成了四段每一段的职责都很单一采集段脑电前端模块负责把电极上的差分信号放大、滤波、模数转换输出数字采样值。发送段BW16监听脑电模块的串口输出把采样值按协议组帧通过 Wi-Fi UDP 发送。接收显示段ESP32-CYD接收 UDP 数据在 2.8 寸 TFT 屏幕上绘制滚动波形。网页推送段同一个 ESP32-CYD 上跑 WebServer 和 WebSocket把同样的数据推给浏览器。这里有一个容易被忽略的设计决策为什么接收端不做成纯网关而是直接带屏幕我的理由是 ESP32-CYD 本身就有完整的 ESP32 算力和屏幕它在接收的同时把数据显示出来调试时不需要额外开电脑网页服务只是它顺手多干的一份活。如果以后想升级成集中式网关把这个 ESP32 换成树莓派或者直接让电脑接收协议不变成本很低。1.3 原型系统和医疗级系统的边界我必须先把话说在前面这条链路做的是原型验证和数据传输演示不是医疗级脑电设备。医疗级 EEG 系统在电极阻抗、共模抑制比、电气安全、数据完整性和校准方面有一整套标准原型链路完全达不到。它的价值在于把采集→传输→显示→远程访问这条数据管道跑通让后续算法开发有真实数据可用。带着这个边界去做就不会在选型上过度纠结。2. 硬件选型为什么是 BW16 和 ESP32-CYD2.1 BW16 作为发送端的理由BW16 的核心是 Realtek RTL8720DN双核 MCU标称主频在 100MHz 级别片上 SRAM 512KB 左右。它最亮眼的配置是除了支持 802.11 a/b/g/n 的双频 Wi-Fi2.4G/5G之外还带 BLE5.0这两样是同时共存的。对于发送端来说这个配置非常契合数据用 Wi-Fi 走控制通道以后可以走 BLE不需要外挂两套射频。在 Arduino 生态里BW16 可以在官方的 Ameba 开发板包里直接使用整体开发体验和 ESP8266 很接近有 WiFi 库、UDP 库、硬件串口基本就是换个平台写一样的逻辑。价格上 BW16 也很便宜带排针的模块十几块钱左右做原型完全不用心疼。对比一下其他候选方案优势不足结论BW16双频 WiFi BLE5.0Arduino 支持便宜资料相对少社区小适合做发送端nRF52840BLE 功耗低生态成熟走 BLE 吞吐有限做音频级数据流吃力更适合低采样率控制ESP8266资料多价格低只有 2.4G没有 BLEIO 少够用但扩展性弱ESP32性能强资料多只有 2.4G功耗比 BW16 略高适合做接收端最终让我选 BW16 的其实是那个双频选项。虽然我在这个项目里最终用的还是 2.4G因为 ESP32-CYD 的 Wi-Fi 只支持 2.4G但发送端留有 5G 能力以后如果接收端换成树莓派或者电脑棒我可以直接在 5G 频段上跑避开家里 2.4G 大量 IoT 设备的互相干扰。2.2 ESP32-CYD接收端和显示端的二合一ESP32-CYD 是市面上一类开发板的常见叫法全称大概是 ESP32-2432S028R也叫 Cheap Yellow Display。它的核心是一块 ESP32-WROOM-32 模组双核 240MHz带 2.4GHz Wi-Fi 和 BLE板载一块 2.8 寸 240×320 的 ILI9341 TFT 屏还带 XPT2046 电阻触摸、MicroSD 卡槽、RGB LED 和串口下载电路。整块板子带屏幕才四五十元确实是便宜又黄。接收端用 ESP32-CYD 的好处是少接一堆线。普通 ESP32 开发板要外挂 TFT 屏、触摸板光接线就有十几根接触不良的概率直线上升。CYD 把屏和主控焊在一起引脚由 PCB 走线固定好我只用关注逻辑不用关注物理连接。TFT_eSPI 库对 CYD 有现成的支持改一下 User_Setup 就能跑。2.3 整条链路的信号流和数据率估算在写代码之前我习惯先把数据率算一遍避免后期被性能问题打脸。假设脑电模块输出单通道 16 位有符号采样值采样率 250Hz原型足够覆盖到 100Hz 脑电频段留出奈奎斯特余量。那么裸数据率是250 样本/秒 × 2 字节/样本 500 字节/秒约 4kbps。如果走批量 UDP 发送我设计每 20 个采样帧打一个包每秒只发 12.5 个包包头开销按每帧 12 字节头部计算总数据率大概是20 帧 × (12 2) 字节 280 字节/包实际发送 12.5 包/秒 ≈ 3.5KB/s ≈ 28kbps。这个量级对 Wi-Fi 来说连零头都算不上。所以这条链路的瓶颈从来不是带宽而是延迟抖动和丢包。后续就算升级到 8 通道、24 位 ADC250Hz 采样总数据率也就 8×250×3×12.5 ≈ 75kbpsBW16 依然毫无压力。这也是我在协议设计时重点盯丢包和时序而不是压缩算法的原因。3. 通信协议设计先定规矩再写代码3.1 为什么数据帧必须有头部、序号和 CRC很多人在做无线传感器原型时会犯一个错误直接把采样值拼成字符串通过 UDP 发出去接收端按行解析。这种方案调试很快但一旦开始丢包、粘包你什么都查不出来。我吸取了之前的教训老老实实定义了二进制帧格式所有整数统一大端序字段长度说明帧头2 字节0xA5 0x5A用于同步帧类型1 字节0x01 数据帧0x02 心跳帧通道数1 字节当前 0x01预留后续序号2 字节单调递增检测丢包时间戳4 字节发送端 millis()单位 ms采样值2/3/4 字节按通道数和 ADC 位数扩展CRC162 字节对前面所有字节计算帧头的作用是接收端找同步起点因为 UDP 虽然不粘包但你一旦批量发送接收端必须能在缓冲区里逐帧切割。序号是最关键的设计接收端看到序号跳变就能立刻知道丢了几个采样点这样才能在绘图时决定是断开还是补插。CRC16 则是为了拦截 Wi-Fi 传输过程中偶发的 bit 翻转脑电这种微弱信号一个错误的采样值在图上就是一根刺。3.2 UDP 批量发送吞吐、延迟和丢包的三角权衡传输层我选了 UDP 而不是 TCP。理由有两个。第一脑电是实时流数据旧样本的可靠重传没有意义。TCP 遇到丢包时会重传和阻塞导致后续数据在接收端排队延迟从 10ms 飘到几百ms这个抖动对波形显示和后续频谱分析都是灾难。UDP 丢就丢了下一包会带着新数据继续来实时性优先。第二UDP 可以批量打包。我实测过单帧单包、每秒 250 个 UDP 小包的发送方式在普通家用路由器上丢包率能到 12% 左右。为什么路由器对单位时间内的包数量有限制小包尤其吃亏。改成 20 帧一包、每秒 12.5 包之后丢包率基本可以忽略不计。批量发送的代价是一条采样点最多延迟 80ms20/250对原型显示完全可接受。如果你的实验对延迟敏感可以调小批大小比如 10 帧一包延迟降一半丢包率略升一点这个参数值得专门测。3.3 时间戳必须以发送端为准这是整个协议里最容易被忽视、但影响最大的设计点。Wi-Fi 传输延迟是抖动的接收端收到包的时刻并不能代表采样发生的时刻。如果接收端用本地 millis() 来当波形的 x 轴时间你会看到波形在时间轴上忽快忽慢周期性每 100ms 顿一下——那是路由器的 Beacon 帧在捣乱。正确做法是发送端记录采样时刻我这里用 BW16 的 millis()放进帧里。接收端画图时x 轴一律用帧内时间戳丢弃本地接收时刻。这样波形在视觉上就稳定了即使 WiFi 延迟在 10ms 到 100ms 之间抖动波形内部的时间关系是原始采样时刻的真实关系。后续如果要送 MNE-Python 做分析这个时间戳也能直接转成采样时间轴。4. BW16 端实现串口收、无线发4.1 接线和电平检查脑电模块和 BW16 之间我用的是 UART。脑电模块的 TX 接 BW16 的 RX地线必须共地波特率先在模块文档里确认常见的脑电前端模块有 115200 和 921600 两种我家这块是 115200。需要注意的是如果脑电模块是 5V 逻辑电平而 BW16 是 3.3V IOTX 线上最好加一个分压电阻不然长期跑容易烧 BW16 的 RX 引脚。如果模块本身是 3.3V 逻辑直接接就行。接线顺序我习惯先接地再接信号线最后接电源。脑电这类高阻抗信号源对电源纹波敏感发送端供电尽量用 LDO 而不是 DCDC我实测用手机充电头加劣质 DCDC 时波形底噪明显变大。4.2 固件逻辑和核心代码BW16 端固件逻辑其实很薄从串口读脑电模块的采样值攒够 20 帧打包发 UDP。不要在发送端做滤波、FFT 之类的事情RTL8720DN 虽然能跑但会挤占接收采样的时间反而增加时间戳抖动。伪代码长这样#include WiFi.h #include WiFiUdp.h const char* ssid 你的热点; const char* pass 你的密码; IPAddress server(192, 168, 1, 50); // ESP32-CYD 的固定 IP const uint16_t port 8266; WiFiUDP udp; uint8_t pktBuf[20 * 14]; // 20帧 × (14字节/帧) uint16_t seq 0; void buildFrame(uint8_t* b, uint16_t sample) { b[0] 0xA5; b[1] 0x5A; b[2] 0x01; // 数据帧 b[3] 0x01; // 单通道 b[4] seq 8; b[5] seq 0xFF; uint32_t ms millis(); b[6] ms 24; b[7] ms 16; b[8] ms 8; b[9] ms; b[10] sample 8; b[11] sample; uint16_t crc crc16(b, 12); b[12] crc 8; b[13] crc 0xFF; seq; } void loop() { int n 0; while (n 20) { if (Serial.available() 2) { uint16_t sample Serial.read() 8 | Serial.read(); buildFrame(pktBuf[n * 14], sample); n; } } udp.beginPacket(server, port); udp.write(pktBuf, n * 14); udp.endPacket(); }实际工程里当然要处理串口断帧、缓冲区溢出这些边缘情况但核心逻辑就是串口读两个字节、拼成采样值、组帧、攒批、发送。这里有个细节我实测发现Serial.read()一次读一个字节在 115200 波特率下250Hz 采样意味着大约每 4ms 来一个采样值CPU 完全跟得上但如果以后升级到 8 通道建议改成 DMA 或中断攒缓冲避免丢串口数据。4.3 发送端的实测表现我把 BW16 放在房间一角ESP32-CYD 放在三米外的桌上中间隔了一堵非承重墙。测试结果RSSI 稳定在 -55dBm 左右发送端固定 IP没有重连情况。丢包率在批量发送模式下几乎为 0连续跑 30 分钟只有一个序号跳变。端到端延迟从 BW16 打时间戳到 ESP32-CYD 解析出帧大约 5~20ms波动主要来自路由器调度。这个表现对原型链路来说足够稳。BW16 的弱点是 5GHz 频段穿墙能力弱但这跟 ESP32-CYD 只支持 2.4GHz 没关系反正这条链路默认走 2.4G。5. ESP32-CYD 端屏幕实时波形绘制5.1 TFT_eSPI 的配置要点ESP32-CYD 这块板子的屏是 ILI9341走 SPI 接口。TFT_eSPI 库需要在User_Setup.h里配置引脚不同批次的 CYD 引脚可能有差异我手上这块的配置如下供参考#define ILI9341_DRIVER #define TFT_WIDTH 240 #define TFT_HEIGHT 320 #define TFT_MISO 19 #define TFT_MOSI 23 #define TFT_SCLK 18 #define TFT_CS 5 #define TFT_DC 21 #define TFT_RST 16 #define TFT_BL 14 #define SPI_FREQUENCY 27000000还有一个容易漏的CYD 板载了 RGB LED 和 SD 卡槽这几个外设和 TFT 共用 SPI 总线或 GPIO如果你没初始化它们默认拉高拉低都可能干扰显示。我直接不初始化 SD 卡并把不用的 GPIO 设为 INPUT_PULLUP能明显减少开机阶段的画面闪烁。SPI 频率我试过 27MHz 和 40MHz40MHz 在部分批次 CYD 上会出现横条纹最后稳定在 27MHz。ESPs 的 SPI 刷 240×320 全屏在 27MHz 下大约 80ms做实时波形显示够用但如果你要跑每秒 30 帧动画就得考虑局部刷新的优化。5.2 滚动波形绘制策略增量画列而不是全屏重绘刚接上的时候我图省事每收到一个采样值就全屏清一次再画整条波形。效果就是屏幕疯狂闪烁一秒钟能闪出残影根本没法看。正确的做法是增量绘制屏幕宽度是 240 像素我把最近 240 个采样值维护成一个环形缓冲区每来一个新值只擦掉最旧一列、画上新一列。SPI 刷一列也就几毫秒刷新率轻松超过 30fps。核心逻辑简写如下#define SCREEN_W 240 #define SCREEN_H 320 int16_t waveBuf[SCREEN_W]; int wavePos 0; void plotSample(uint16_t sampleRaw) { int16_t y map(sampleRaw, 0, 4095, 60, 280); // 按你的 ADC 量程调整 int oldX wavePos; int newX (wavePos 1) % SCREEN_W; // 擦掉旧列注意别把网格线一起擦掉 tft.drawFastVLine(oldX, 60, 220, TFT_BLACK); // 画新列 tft.drawPixel(newX, y, TFT_RED); // 可选从上一列连一条线过来让波形连续 int oldY waveBuf[oldX]; tft.drawLine(oldX, oldY, newX, y, TFT_RED); waveBuf[newX] y; wavePos newX; }Map 函数是 Arduino 自带的做线性映射。我这里把 0~4095 的原始值映射到屏幕竖直方向的 60~280 像素等价于留出上下边距写标题栏。波形是连续的还是点状的取决于你的 EEG 采样率250Hz 在 240 像素宽的屏幕上大概每 0.96 秒滚一屏点与点之间间隔约 4ms连续画线看起来更舒服。5.3 屏幕上的状态信息和触摸操控光画波形还不够我在屏的顶部留了一条状态栏显示当前 RSSI、丢包率、采样序号、以及与发送端的时间戳差值。这四个值来自接收端解析帧时的统计不需要额外通信。丢包率用滑动窗口统计最近 1000 帧的序号跳变数画在屏幕上可以直观看到链路质量。触摸屏我加了三块区域按钮暂停/继续、放大/缩小、清除波形。XPT2046 的触摸读取用 TFT_eSPI 的getTouch()注意电阻触摸需要校准我在启动时让用户点屏幕四角存下校准参数到 NVS。暂停功能很有用当你想细看某一段波形时暂停滚动数据仍然在后台接收只是不画而已。6. 网页端WebSocket 实时显示与远程监控6.1 ESP32 同时跑 WebServer 和 UDP 接收ESP32-CYD 在接收 UDP 的同时还起了两个服务一个 HTTP WebServer 跑在 80 端口提供静态网页一个 WebSocket 服务跑在 /ws 路径负责推送实时数据。ESP32 双核 240MHz这点并发完全扛得住。网页端我坚持用 WebSocket 而不是 SSE 或者轮询。WebSocket 是双向全双工而且可以直接传二进制帧正好匹配我定义的 0xA5 0x5A 帧格式。浏览器收到二进制帧后用 DataView 解析和 C 端解析逻辑一致相当于同一个协议两端复用。需要注意一个细节ESP32 的 WebServer 库和 WebSocketsServer 库可能会抢 WiFi 事件处理我建议 WebSocket 服务放在一个单独的任务里或者至少在loop()里先webSocket.loop()再处理 UDP避免 WebSocket 的 ping/pong 超时把客户端踢掉。6.2 浏览器端解析和绘制网页部分我写了一个单页 HTML里面用 canvas 画波形。关键代码如下const ws new WebSocket(ws://${location.host}/ws); ws.binaryType arraybuffer; let latestSample null; ws.onmessage (e) { const dv new DataView(e.data); // 假设一个包就是多个帧拼在一起 for (let i 0; i 14 dv.byteLength; i 14) { if (dv.getUint8(i) ! 0xa5 || dv.getUint8(i 1) ! 0x5a) continue; latestSample dv.getInt16(i 10, false); // 大端序 } }; function drawLoop() { requestAnimationFrame(drawLoop); if (latestSample null) return; const y mapRange(latestSample, 0, 4095, canvas.height * 0.2, canvas.height * 0.8); pushToCanvas(y); }这里有个关键技巧onmessage里只保留最新的采样值drawLoop每帧界面刷新时取一次。WebSocket 推送频率是 250Hz而浏览器 canvas 刷新上限是 60fps如果每来一个采样就画一次canvas 队列会积压延迟越积越大。用最新值覆盖的方式视觉上最多丢一两个中间点但延迟始终稳定在几十毫秒以内。这就是典型的实时流处理里的latest-wins策略。6.3 多人查看和数据落盘网页的好处是手机、平板、电脑都能同时打开。我在 ESP32 的 WebSocket 服务器里维护一个客户端列表每收到一个 UDP 包就广播给所有连接的客户端。广播前先检查每个客户端的发送缓冲区长度如果超过阈值就跳过该客户端防止一个慢设备拖垮整个服务器。网页端我还加了一个开始录制按钮。点击后浏览器把所有通过 WebSocket 收到的采样值按时间戳缓存起来结束时导出一个 CSV 文件。CSV 第一列是发送端时间戳第二列是原始采样值后续可以直接喂给 Python 脚本做频域分析或最小范数估计。注意浏览器页签切到后台时 JS 定时器会被节流录制期间尽量保持页签在前台。如果是严肃的数据采集我还是建议在 ESP32-CYD 上接 SD 卡落盘后面会说到。7. 调试实测几个让人头大的坑和完整排查过程7.1 波形变梳子UDP 丢包的排查链路第一次跑通时屏幕上波形每隔一段就出现一个很大的竖直跳变看起来像梳子齿。很多人第一反应是脑电模块出了问题或者是电源干扰。我的排查链路是这样的第一步先看脑电模块直接接串口时波形是否正常。用 USB 转串口连模块电脑端画图波形正常。这说明问题出在无线链路段。第二步在 ESP32-CYD 端打印接收到的序号统计跳变。我加了一个临时调试代码把最近 100 个包的序号差值打出来发现几乎每 3~5 个包就有一个缺口丢包率大概在 8%~12%。第三步查 RSSI 和 ping。RSSI -55dBm信号没问题ping BW16 丢包率为 0。这说明丢包不是物理层的而是路由器在转发高频小包时的队列丢弃。第四步就是我前面说的批量发送改造。把单帧单包改成 20 帧一包后丢包率掉到 0.1% 以下波形立刻顺滑。这个问题的根因不是信号弱而是包速率太高。7.2 屏幕刷新卡顿和残影第二个坑是屏幕刷新率的优化。硬件链路的根因是TFT_eSPI默认会做全屏 DMA 刷新而我只画了一条线却让 GPU 把整块屏都刷了。改成drawFastVLine局部擦除之后刷新从 80ms 降到 1ms 左右肉眼完全感觉不到刷新延迟。另外canvas 绘图中我踩了一个小坑TFT_eSPI默认坐标是左上角为 (0,0)y 轴向下而脑电波形习惯上是负值在下方。我的映射函数里用了map(raw, 0, 4095, 280, 60)把 0 映射到屏幕下方4095 映射到屏幕上方。如果你写成 60 到 280 的升序波形显示就是镜像的别问我怎么知道的。7.3 WebSocket 积压导致网页延迟越来越大网页端出现的问题是打开页面半小时后波形明显迟到手机页面上看到的波形比屏幕上慢了好几秒。我一开始以为是 ESP32 卡了后来在浏览器里打印latestSample的更新时间戳发现数据一直在更新但绘制延迟在增长。原因就是我在 6.2 节说的onmessage里每个采样点都调用canvas绘制函数浏览器帧循环来不及消费canvas 内部缓冲越来越多。改成消息只存最新值绘制循环每帧取一次之后延迟稳定在 100ms 内。这是做任何实时 Web 可视化都应该记住的经验。7.4 看似玄学的时间戳抖动问题还有一个很难察觉的问题波形虽然画出来了但用示波器看采样间隔有时候两个采样点之间差了 40ms有时候只有 5ms。这个问题如果不做频谱分析根本发现不了。根因在 3.3 节已经说过WiFi 的 Beacon 帧每 100ms 广播一次发送期间 BW16 的 UDP 发送会被挤占导致采样点到达接收端的时间不均匀。我验证的方法是在接收端打印帧内时间戳与本地接收时间的差值看到每 100ms 有一个明显跳变然后改用帧内时间戳画图问题消失。这里的关键不是修掉 WiFi 抖动做不到而是让显示和记录都基于采样时刻的时间戳把传输抖动从信号路径中隔离出去。8. 向前一步从原型到 EEG 源定位与最小范数估计8.1 单通道只是数据管道不是完整 EEG 系统这条链路现在跑的是单通道脑电它证明的是采集→无线→显示→网页的数据管道是通的。但如果你关注 EEG 源定位source localization单通道远远不够。源定位的目标是根据头皮表面的电位分布反推出大脑内部神经源的位置和强度。头皮上有多少个测点通常就需要多少个通道标准做法是 10-20 系统的 19 通道、64 通道甚至高密度 128 通道。单通道只能看到额叶或枕叶某一点的信号无法提供空间分辨力。所以这条原型链路的真正价值是为后续多通道系统打好传输和可视化基础。协议里的通道数字段我现在只填 0x01但帧格式已经预留了BW16 的吞吐能力跑 8 通道 24 位 250Hz 也绰绰有余。真正需要换掉的硬件是前端采集模块从单通道模组换成一枚 ADS1299 这样的 8 通道 24 位生物电采集芯片后面接一个多路复用器电极按 10-20 系统摆放链路其余部分不用大改。8.2 最小范数估计需要什么数据如果你想把这条路走到底做 EEG 源定位网上搜EEG 源定位 最小范数估计基本都会指向 MNE-Python。最小范数估计Minimum Norm Estimate, MNE是分布式源重构里最常用的方法之一它不是一个能直接吃 UART 数据的算法而是一整套数据管线。它需要三样东西第一多通道脑电数据采样率和通道数必须满足空间采样的基本要求通道数太少源定位结果不稳定。第二头模型和电极位置。被测试者的头部几何模型通常用模板头模如 ICBM152电极坐标要按 10-20 系统换算成 MRI 空间坐标。第三预处理后的干净数据段。基线漂移、眼电伪迹、工频干扰都要先处理否则噪声会让最小范数估计解出假源。MNE 的数学核心可以简化理解成求解一个线性逆问题设头皮电位为 M源空间电流为 J正向模型volume conductor为矩阵 G那么 M G J noise最小范数估计就是在约束 J 的能量尽量小的前提下解 J argmin ||M - G J||² λ||J||²其中 λ 是正则化参数。实际使用的 MNE-Python 会做得更精细比如用协方差矩阵加权、对不同源深度做归一化。但前提是数据质量你给它一堆带 WiFi 丢包的脏数据算出来的源位置就是纸上谈兵。8.3 从原型到正式数据采集的建议我个人的建议是如果你想用这套链路做 EEG 源定位至少要做三件事再开始。第一在 ESP32-CYD 上加 SD 卡记录。把 UDP 收到的原始帧按高效二进制格式存到 microSD而不是靠浏览器缓存导 CSV。WiFi 链路适合实时监控但正式分析的数据必须在采集端实时落盘避免传输丢包污染数据。我设计了帧序号落盘后可以用脚本按序号补齐或剔除异常段。第二在采集端加数字滤波确认数据质量。BW16 上只做轻量级工频陷波50/60Hz和直流基线去除不做重处理因为重处理会挤占采样时间。真正的滤波放在数据回放阶段用 MNE-Python 的filter()一步到位。第三先把采样率和通道数盯死。250Hz 对常规脑电源定位偏低建议至少 500Hz 起步因为源定位对高频瞬态成分比较敏感通道数至少 16不然头表空间采样不足MNE 的结果可信度很低。BW16 和 ESP32-CYD 在这一层的角色不变BW16 负责把多通道数据完整送达ESP32-CYD 负责可视化与落盘。我个人在实际操作中的体会是这类原型链路的成败往往不在硬件性能而在你把实时性和可靠性这对矛盾想清楚了没有实时显示用 UDP 批量发送和 latest-wins数据落盘用帧序号和时间戳兜底两边互不干扰。还有就是波形显示类的项目一定要把时间戳的归属关系想明白谁记录采样时刻谁负责画图这个归属错了后面所有分析都是错。如果你也正在搭类似的无线脑电原型可以从这条单通道链路起步跑通数据管道后再逐步加通道每一步都有清晰的验证标准。