1. 从脑电信号到红外遥控这个项目到底在做什么脑机接口这个词听起来像是实验室里的高精尖项目但实际上用消费级脑电模块配合一块 ESP32 来控制家里的空调、电视、风扇已经是一个完全可以跑通的方案。我最近花了大概三周时间把 NPG Lite 脑电采集模块、ESP32 开发板和红外收发模块串成了一条完整的链路实现了“注意力集中就开灯、放松就关灯”这种最基础的脑控家电功能。整套硬件的成本控制在三百元以内代码量也不算大但中间踩的坑确实不少。这个项目的核心逻辑其实不复杂NPG Lite 负责采集前额叶的脑电信号通过串口把原始数据或者预处理后的注意力/放松度指标发给 ESP32ESP32 拿到这些指标之后按照预设的阈值判断当前用户的意图状态然后驱动红外发射模块发出对应家电的红外编码完成开关或调节操作。整个链路里ESP32 扮演的是“翻译官指挥官”的角色它一边要稳定地读取脑电模块的数据一边要管理红外编码的发送同时还得兼顾 WiFi 或蓝牙的连接状态让用户能通过手机查看当前脑电状态和手动覆盖控制。适合谁来参考这篇内容如果你已经玩过 Arduino 或者 ESP32 的基础项目对串口通信、红外编码有基本概念那这篇内容可以直接帮你省掉大量试错时间。如果你是完全零基础的小白建议先把 ESP32 的 GPIO 操作和串口收发搞明白再回来看不然中间的一些配置细节可能会让你卡住。关键词里提到的 NPG Lite、IR Transceiver、Arduino IDE、ESP32、BCI 这五个点基本覆盖了整个项目的技术栈后面我会逐个拆开讲。注意脑电模块采集的是人体生物电信号属于弱电信号范畴接线和供电一定要和红外发射模块的大电流回路做好隔离否则噪声会直接淹没有效信号。2. NPG Lite 脑电模块的数据读取与注意力指标提取2.1 NPG Lite 的串口协议与数据帧格式NPG Lite 这个模块在创客圈里用得比较多主要是因为它把复杂的脑电放大和滤波电路都集成好了对外只暴露一个串口接口波特率默认是 57600。它输出的数据帧格式是固定的每帧包含一个帧头 0xAA、一个帧尾 0x55中间夹着若干字节的有效数据。具体来说一帧完整的数据包含帧头1字节、数据长度1字节、有效载荷N字节、校验和1字节、帧尾1字节。有效载荷里面又分为两种类型一种是原始脑电波形数据另一种是模块内部算法计算出来的注意力值和放松度值。我实测下来NPG Lite 的注意力值范围是 0 到 100数值越高代表注意力越集中。放松度也是 0 到 100数值越高代表越放松。这两个指标每秒钟更新一次对于控制家电来说这个刷新率完全够用。原始波形数据的采样率是 512Hz如果你要做更复杂的信号处理比如自己写 FFT 或者小波变换那就得用原始数据。但对于“注意力开灯、放松关灯”这种简单场景直接用模块算好的指标就行省事而且稳定。在 Arduino IDE 里读取 NPG Lite 的数据核心就是串口解析。我建议用一个固定长度的缓冲区来接收字节然后逐字节判断帧头和帧尾。下面这段代码是我实际在用的解析逻辑#define NPG_BAUD 57600 #define FRAME_HEADER 0xAA #define FRAME_TAIL 0x55 #define MAX_PAYLOAD 32 uint8_t rxBuf[MAX_PAYLOAD 4]; uint8_t rxIndex 0; bool frameStarted false; void parseNPGByte(uint8_t b) { if (b FRAME_HEADER) { rxIndex 0; rxBuf[rxIndex] b; frameStarted true; return; } if (!frameStarted) return; if (rxIndex sizeof(rxBuf)) { rxBuf[rxIndex] b; } if (b FRAME_TAIL) { processFrame(rxBuf, rxIndex); frameStarted false; rxIndex 0; } }这段代码的关键点在于帧头判断要放在最前面一旦检测到 0xAA 就重置索引并开始记录帧尾判断放在最后收到 0x55 就触发处理函数。中间如果缓冲区满了还没收到帧尾就直接丢弃这一帧防止数组越界。2.2 注意力值的平滑处理与阈值设定直接从 NPG Lite 读出来的注意力值会有抖动比如你明明在集中注意力但数值可能在 60 到 75 之间来回跳。如果直接用瞬时值去判断开关灯就会疯狂闪烁。所以必须做平滑处理。我试过三种方案滑动平均、指数加权平均、中值滤波。最后用的是指数加权平均因为它计算量小而且对突变响应快。指数加权平均的公式是smoothed alpha * current (1 - alpha) * smoothed。alpha 取 0.2 到 0.3 之间比较合适。alpha 太小响应迟钝alpha 太大平滑效果不够。我实测 alpha 0.25 的时候既能滤掉大部分抖动又不会让用户觉得“我明明集中注意力了怎么灯还不亮”。阈值设定方面我建议不要设一个固定值而是设一个“触发区间”。比如注意力值超过 70 持续 1 秒以上才触发开灯低于 40 持续 1 秒以上才触发关灯。中间 40 到 70 这个区间作为“死区”不做任何操作。这样可以避免用户在临界值附近反复触发。具体阈值因人而异有些人天生注意力值偏高静息状态就有 50 多有些人偏低集中注意力也就 60 出头。所以最好在代码里加一个校准模式上电后前 10 秒采集用户的静息基线然后根据基线动态调整阈值。提示NPG Lite 的电极片用久了会氧化接触电阻变大信号质量会明显下降。建议每两周换一次电极片或者改用导电硅胶电极虽然贵一点但稳定得多。2.3 串口数据与 ESP32 的电气连接细节NPG Lite 的输出电平是 3.3V TTL和 ESP32 的 UART 电平完全匹配所以不需要电平转换模块。接线也很简单NPG Lite 的 TX 接 ESP32 的 RX比如 GPIO16NPG Lite 的 RX 接 ESP32 的 TX比如 GPIO17GND 共地VCC 接 3.3V。但这里有一个很容易忽略的问题ESP32 在烧录程序的时候UART0 会被占用如果你把 NPG Lite 接在 UART0 上烧录时就会冲突。所以我一律建议用 UART2也就是 GPIO16 和 GPIO17 这一组避开烧录口。另外NPG Lite 的功耗大概在 30mA 左右ESP32 的 3.3V 稳压器如果同时给 WiFi 和 NPG Lite 供电在 WiFi 发射瞬间可能会有电压跌落导致 NPG Lite 复位。我的做法是给 NPG Lite 单独加一个 100uF 的电解电容在 VCC 和 GND 之间做本地储能。这个电容的位置要尽量靠近 NPG Lite 的电源引脚否则效果打折扣。3. ESP32 端的红外收发与家电编码管理3.1 红外收发模块的选型与接线红外收发我用的是一体化的 IR Transceiver 模块型号是常见的 VS1838B 接收头加一个 940nm 红外发射管。接收头负责学习家电遥控器的编码发射管负责发送编码。ESP32 驱动红外发射管的时候不能直接用 GPIO 推挽输出因为红外发射管需要较大的瞬时电流通常 100mA 以上ESP32 的 GPIO 最大只能输出 40mA 左右。所以必须加一个 NPN 三极管或者 N-MOSFET 做驱动。我的电路是这样的ESP32 的 GPIO25 接一个 1k 电阻到 S8050 三极管的基极三极管的集电极接红外发射管的负极发射极接地红外发射管的正极通过一个 10 欧姆的限流电阻接 5V。这样当 GPIO25 输出高电平时三极管导通红外发射管通电发光。接收头的输出直接接 ESP32 的 GPIO26接收头内部已经有上拉和滤波外部不需要额外元件。这里有一个坑红外发射管的限流电阻不能省而且阻值要算对。假设红外发射管的正向压降是 1.2V5V 供电想要 150mA 的峰值电流那么电阻就是 (5 - 1.2) / 0.15 25.3 欧姆。我实际用的是 10 欧姆峰值电流大概 380mA虽然超过发射管额定值但因为红外编码的占空比很低通常不到 30%平均电流并不大实测长时间工作也没有烧毁。但如果你追求稳妥用 22 欧姆或者 33 欧姆更安全。3.2 用 IRremoteESP8266 库学习与发送红外编码在 Arduino IDE 里红外编码的处理我强烈推荐 IRremoteESP8266 这个库。虽然名字里带 ESP8266但它对 ESP32 的支持非常完善。安装方式很简单在 Arduino IDE 的库管理器里搜索 “IRremoteESP8266” 然后安装最新版就行。学习遥控器编码的流程是这样的先把接收头对准遥控器按下遥控器上的按键ESP32 通过接收头捕获红外信号然后用results-decode()解析出协议类型、编码值、位数等信息。下面这段代码是我用来学习编码的#include IRremoteESP8266.h #include IRrecv.h #include IRutils.h #define RECV_PIN 26 IRrecv irrecv(RECV_PIN); decode_results results; void setup() { Serial.begin(115200); irrecv.enableIRIn(); } void loop() { if (irrecv.decode(results)) { Serial.print(Protocol: ); Serial.println(typeToString(results.decode_type)); Serial.print(Value: 0x); Serial.println(results.value, HEX); Serial.print(Bits: ); Serial.println(results.bits); irrecv.resume(); } }拿到协议类型和编码值之后发送就很简单了。比如你学到的是 NEC 协议、编码 0x00FF6897、32 位那么发送代码就是#include IRsend.h #define SEND_PIN 25 IRsend irsend(SEND_PIN); void sendPower() { irsend.sendNEC(0x00FF6897, 32); }但这里有一个实际问题很多家电遥控器的编码不是标准的 NEC 协议而是厂商自定义的协议IRremoteESP8266 可能无法自动识别。这时候你就需要手动分析时序或者用irsend.sendRaw()直接发送原始时序数组。原始时序数组的获取方法是在学习模式下把results.rawbuf和results.rawlen打印出来然后复制到发送代码里。这个方法虽然笨但兼容性最好几乎能搞定所有红外遥控器。3.3 多设备编码的存储与索引管理一个家庭里通常有电视、空调、风扇、机顶盒等多个红外设备每个设备又有多个按键。如果把这些编码全部硬编码在代码里代码会非常臃肿而且换一个设备就要重新编译烧录。我的做法是用 ESP32 的 Preferences 库基于 NVS 闪存来存储编码每个编码分配一个唯一的 ID比如 “tv_power”、“ac_temp_up”、“fan_speed” 这样的字符串键。学习模式下用户按遥控器ESP32 把解析出来的协议、编码值、位数存到 Preferences 里控制模式下根据 ID 读取编码并发送。Preferences 库的使用很简单#include Preferences.h Preferences prefs; void saveCode(const char* key, uint16_t protocol, uint64_t value, uint16_t bits) { prefs.begin(ir_codes, false); prefs.putUShort((String(key) _proto).c_str(), protocol); prefs.putULong64((String(key) _val).c_str(), value); prefs.putUShort((String(key) _bits).c_str(), bits); prefs.end(); }这样设计的好处是用户可以通过手机 App 或者网页界面进入学习模式不需要重新烧录固件就能添加新设备。NVS 的读写寿命大概是 10 万次左右对于红外编码这种低频写入场景完全够用。注意Preferences 的键名长度有限制最长 15 个字符。所以 “tv_power_proto” 这种命名可能超长建议用缩写比如 “tvp_p”、“tvp_v”、“tvp_b”。4. 脑电指标到红外指令的映射逻辑与状态机设计4.1 从注意力/放松度到控制指令的映射策略把脑电指标映射到红外指令最直接的方式是阈值触发注意力值超过阈值就发开灯指令放松度超过阈值就发关灯指令。但实际用起来会发现两个问题第一用户不可能一直保持高注意力灯开了之后如果注意力下降灯又关了体验很差第二不同家电的控制逻辑不一样电视是开关切换空调是温度加减风扇是风速档位不能都用同一套阈值。我的解决方案是引入一个“状态机”层。状态机维护当前家电的开关状态和参数状态脑电指标只负责触发状态迁移不直接对应红外指令。比如对于灯状态有“关”和“开”两个注意力超过阈值且当前是“关”状态就迁移到“开”状态并发送开灯红外码放松度超过阈值且当前是“开”状态就迁移到“关”状态并发送关灯红外码。如果当前已经是“开”状态再高的注意力值也不会重复发送开灯指令。对于空调这种多参数设备状态机就更复杂一些。我设计的状态包括关机、制冷、制热、送风四个主状态每个主状态下面还有温度值16 到 30和风速档位低、中、高。脑电指标只控制主状态的切换温度和风速通过手机 App 手动调节。这样既保留了脑控的核心体验又避免了脑电信号精度不够导致的误操作。4.2 防误触与指令去抖的工程实现脑电信号的一个特点是“来得快、去得也快”。你可能突然想到一件事注意力值瞬间冲到 80但两秒后又回落到 50。如果阈值触发没有去抖机制灯就会闪一下又灭。我的做法是加一个“持续时长”条件注意力值必须连续超过阈值 1.5 秒以上才认定为有效触发。这个 1.5 秒是我反复测试后确定的太短容易误触太长用户会觉得反应慢。实现上我用一个计时器变量来记录“连续超阈值”的时长。每次读取到新的注意力值如果超过阈值计时器累加如果低于阈值计时器清零。只有当计时器超过 1500 毫秒时才执行状态迁移。同时状态迁移之后有一个 3 秒的“冷却期”冷却期内不再响应任何脑电触发防止连续指令把家电搞乱。还有一个细节NPG Lite 在用户眨眼或者咬牙的时候会产生很大的伪迹注意力值可能会瞬间飙到 90 以上。这种伪迹触发的指令是用户不想要的。我的过滤方法是如果注意力值在 200 毫秒内从低于 50 跳到高于 85就判定为伪迹直接丢弃这一帧数据。这个规则虽然简单但实测能过滤掉八成以上的眨眼伪迹。4.3 手动覆盖与脑控模式的优先级仲裁脑控虽然酷但不可能完全替代手动控制。比如家里来了客人客人想开电视总不能让人家戴脑电头环吧。所以系统必须支持手动覆盖。我的设计是手机 App 和物理按键的手动指令优先级最高一旦收到手动指令脑控模式自动暂停 30 秒30 秒后如果没有新的手动指令再恢复脑控。这样既保证了脑控的连续性又不会在需要手动操作时被脑控干扰。优先级仲裁的逻辑用简单的状态变量就能实现enum ControlMode { BRAIN, MANUAL, COOLDOWN }; ControlMode currentMode BRAIN; unsigned long lastManualTime 0; void loop() { if (currentMode MANUAL millis() - lastManualTime 30000) { currentMode BRAIN; } if (currentMode BRAIN) { checkBrainTrigger(); } checkManualInput(); }这个逻辑虽然简单但实际跑起来很稳。唯一需要注意的是手动指令的检测要放在脑电触发检测之前否则手动指令可能会被脑电触发覆盖。5. 无线连接与远程监控的工程取舍5.1 ESP32 同时跑 WiFi 和蓝牙的可行性验证热词里有人问“esp32蓝牙和wifi可以一起用吗”这个问题我在这个项目里正好遇到了。答案是可以同时用但有很多限制。ESP32 的射频模块是共享的WiFi 和蓝牙不能真正“同时”收发而是分时复用。实际表现就是WiFi 吞吐量会下降蓝牙的延迟会增加但功能上都能跑通。我的用法是WiFi 用来跑一个轻量级的 Web 服务器用户可以通过浏览器查看当前脑电状态和手动发送控制指令蓝牙用来做配网和紧急手动控制因为蓝牙不需要路由器手机直接连上就能用。实测下来WiFi 和蓝牙同时开启时Web 服务器的响应时间从 50ms 增加到 150ms 左右蓝牙指令的延迟从 20ms 增加到 80ms 左右。对于家电控制来说这个延迟完全可以接受。但有一个坑ESP32 的蓝牙和 WiFi 共存时如果 WiFi 正在大量传输数据比如 OTA 升级蓝牙可能会断连。所以我的建议是OTA 升级期间关闭蓝牙升级完成后再重新开启。另外WiFi 和蓝牙的天线是同一个PCB 布局不好的话同时工作时信号质量会明显下降。如果条件允许选带外部天线接口的 ESP32 模块比如 ESP32-WROVER-B会稳定很多。5.2 用 Web 服务器做脑电状态可视化在 ESP32 上跑 Web 服务器我推荐用 ESPAsyncWebServer 库它比同步的 WebServer 库响应快得多而且支持 WebSocket可以实时推送脑电数据到浏览器。我的实现是ESP32 每 100 毫秒通过 WebSocket 推送一次当前的注意力值、放松度和家电状态浏览器端用 JavaScript 接收并绘制成实时曲线。WebSocket 的代码大概长这样#include AsyncTCP.h #include ESPAsyncWebServer.h AsyncWebServer server(80); AsyncWebSocket ws(/ws); void onWsEvent(AsyncWebSocket *server, AsyncWebSocketClient *client, AwsEventType type, void *arg, uint8_t *data, size_t len) { if (type WS_EVT_CONNECT) { Serial.printf(Client %u connected\n, client-id()); } } void setup() { WiFi.begin(SSID, PASSWORD); while (WiFi.status() ! WL_CONNECTED) delay(500); ws.onEvent(onWsEvent); server.addHandler(ws); server.begin(); } void loop() { static unsigned long lastPush 0; if (millis() - lastPush 100) { String json {\attention\: String(attentionValue) ,\relax\: String(relaxValue) }; ws.textAll(json); lastPush millis(); } }浏览器端用new WebSocket(ws:// location.host /ws)建立连接然后在onmessage回调里解析 JSON 并更新图表。整个页面我放在 ESP32 的 SPIFFS 文件系统里通过server.serveStatic(/, SPIFFS, /)提供访问。这样用户只需要在浏览器输入 ESP32 的 IP 地址就能看到脑电波形和家电状态不需要安装任何 App。5.3 蓝牙串口作为备用控制通道蓝牙串口我用的是经典蓝牙 SPP 模式因为它的兼容性最好安卓和 iOS 都有现成的串口 App 可以用。ESP32 的经典蓝牙库是BluetoothSerial使用起来非常简单#include BluetoothSerial.h BluetoothSerial SerialBT; void setup() { SerialBT.begin(BrainHomeCtrl); } void loop() { if (SerialBT.available()) { char cmd SerialBT.read(); handleBluetoothCommand(cmd); } }蓝牙串口的用途主要有两个一是配网当 ESP32 第一次上电或者 WiFi 密码变了用户通过蓝牙发送 WiFi 的 SSID 和密码ESP32 收到后保存到 Preferences 并重启连接二是紧急手动控制当 WiFi 出问题或者手机连不上路由器时用户可以通过蓝牙直接发送控制指令比如发送字符 1 开灯、0 关灯。这里有一个实际经验ESP32 的经典蓝牙和 BLE 不能同时使用但经典蓝牙和 WiFi 可以共存。如果你需要 BLE 的低功耗特性那就得放弃经典蓝牙 SPP改用 BLE 串口服务。但对于这个项目来说经典蓝牙 SPP 的简单性和兼容性更重要所以我没有用 BLE。6. 实际部署中踩过的坑与排查过程6.1 红外发射距离短且角度敏感的根因分析最开始我用的红外发射管是普通的 5mm 直插式发现控制距离只有两米左右而且必须对准家电的红外接收窗才能触发。我一开始以为是发射管功率不够换了更大功率的发射管但改善不明显。后来用示波器看发射管两端的波形才发现问题出在驱动三极管的基极电阻上。我最初用的 10k 基极电阻导致三极管没有完全饱和导通发射管的峰值电流只有 30mA 左右远低于额定的 100mA。把基极电阻换成 1k 之后三极管进入深度饱和发射管峰值电流达到 150mA控制距离直接拉到 8 米以上而且角度宽容度也大了很多。这个问题的根因是ESP32 的 GPIO 输出高电平是 3.3V三极管的基极-发射极压降约 0.7V基极电流 (3.3 - 0.7) / 10000 0.26mA乘以三极管的放大倍数S8050 大概 100 倍集电极电流只有 26mA。换成 1k 之后基极电流 2.6mA集电极电流 260mA足够驱动发射管了。提示如果你用的是 MOSFET 而不是三极管基极电阻的问题就不存在了因为 MOSFET 是电压驱动。但 MOSFET 的栅极电容需要充放电开关速度可能不如三极管对于 38kHz 的红外载波来说要选栅极电荷小的型号比如 2N7002。6.2 NPG Lite 数据丢帧与串口缓冲区溢出项目跑到第二天的时候发现脑电数据偶尔会丢帧表现就是注意力值突然变成 0 或者保持不变。我用逻辑分析仪抓了串口波形发现 NPG Lite 的数据帧是连续的没有丢失但 ESP32 这边确实没有解析出来。问题出在串口接收缓冲区上Arduino 的 HardwareSerial 默认接收缓冲区只有 256 字节而 NPG Lite 在 57600 波特率下每秒钟产生大约 5760 字节的数据如果主循环里有延时或者 WiFi 处理占用时间过长缓冲区就会溢出。解决方法有两个一是增大串口接收缓冲区在HardwareSerial.h里把RX_BUFFER_SIZE从 256 改成 1024但这需要修改库文件不太优雅二是在主循环里优先处理串口数据把 WiFi 和 WebSocket 的推送放在串口处理之后并且保证loop()里没有delay()调用。我采用的是第二种方案把所有的延时都改成了非阻塞的millis()计时主循环的执行时间控制在 5ms 以内丢帧问题就彻底消失了。另外NPG Lite 的数据帧之间其实有固定的间隔我利用这个间隔做了一次“帧同步”如果超过 100ms 没有收到任何数据就重置解析状态机防止因为半帧数据导致后续所有帧都解析错误。这个保护机制在实际运行中救了好几次尤其是在电磁干扰导致串口出现乱码的时候。6.3 WiFi 连接不稳定导致 WebSocket 频繁断连WiFi 不稳定是我遇到的第三个大坑。表现是手机浏览器上的脑电曲线经常卡住WebSocket 连接时不时断开。我一开始以为是 ESP32 的 WiFi 信号弱换了路由器、加了天线改善有限。后来用WiFi.RSSI()打印信号强度发现 RSSI 在 -60dBm 左右不算差。真正的问题是 ESP32 的 WiFi 省电模式默认情况下ESP32 会在没有数据传输时进入 modem sleep导致 WebSocket 的心跳包丢失连接被服务器端断开。解决方法是在WiFi.begin()之后调用WiFi.setSleep(false)关闭省电模式。关闭之后WebSocket 的连接稳定性大幅提升连续运行 24 小时没有断连。代价是功耗增加大概从 80mA 增加到 120mA但对于插电供电的家电控制场景来说这点功耗完全可以接受。还有一个细节ESPAsyncWebServer 的 WebSocket 默认没有心跳机制如果客户端异常断开服务器端可能不会立即感知。我的做法是在 WebSocket 事件里记录客户端连接时间然后在主循环里定期检查如果某个客户端超过 30 秒没有发送任何数据就主动断开它释放资源。6.4 脑电触发与红外发送的时序冲突最后一个坑比较隐蔽当脑电触发和红外发送同时发生时ESP32 会先处理红外发送因为 IRremoteESP8266 的sendNEC()是阻塞式的发送一帧 NEC 编码大概需要 68ms。在这 68ms 里串口数据继续进来但主循环被阻塞导致串口缓冲区溢出脑电数据丢帧。如果连续触发多个红外指令丢帧会更严重。我的解决方案是把红外发送也改成非阻塞的。IRremoteESP8266 库本身不直接支持非阻塞发送但可以通过irsend.sendNEC()的重复发送功能来模拟先发送一次然后立即返回在下一个循环里检查是否需要重复发送。或者更简单的方法把红外发送放在一个独立的 FreeRTOS 任务里通过队列接收发送请求这样主循环就不会被阻塞。我用的是 FreeRTOS 任务方案QueueHandle_t irQueue; void irTask(void *param) { uint64_t code; while (1) { if (xQueueReceive(irQueue, code, portMAX_DELAY)) { irsend.sendNEC(code, 32); } } } void setup() { irQueue xQueueCreate(10, sizeof(uint64_t)); xTaskCreatePinnedToCore(irTask, IRTask, 4096, NULL, 1, NULL, 0); }这样红外发送在核心 0 上跑脑电解析和 WiFi 处理在核心 1 上跑互不干扰。实测下来即使连续触发 10 个红外指令脑电数据也不会丢帧。7. 从原型到可用产品的几个优化方向7.1 电极方案的改进与信号质量提升NPG Lite 原装的电极片是干电极优点是方便缺点是接触阻抗大信号噪声明显。我后来换成了导电硅胶电极接触阻抗从几十千欧降到几欧姆信号质量提升非常明显。注意力值的波动从 ±15 降到了 ±5阈值判断的准确率大幅提高。如果你打算长期使用这个项目我强烈建议换电极虽然一对导电硅胶电极要几十块钱但体验提升绝对值这个价。另外电极的位置也很关键。NPG Lite 是单通道模块通常放在前额叶位置FP1 或 FP2参考电极夹在耳垂上。我试过把电极放在额头上方和太阳穴位置信号质量都不如 FP1。如果你戴眼镜电极片可能会被眼镜腿压住导致接触不良这时候可以把电极稍微往内侧移一点避开眼镜腿。7.2 增加本地物理按键作为兜底控制脑控虽然方便但万一脑电模块没电了、电极掉了、或者用户就是不想戴头环系统就完全失控了。所以我在原型上加了三个物理按键一个开灯、一个关灯、一个切换模式。按键直接接 ESP32 的 GPIO用内部上拉按下时接地。代码里用中断或者轮询检测优先级高于脑控。这样即使脑电部分完全失效用户至少还能手动控制家电。物理按键的另一个用途是“校准触发”。长按某个按键 3 秒系统进入校准模式采集 10 秒的静息基线然后自动更新注意力阈值。这个功能在实际使用中非常实用因为用户的脑电基线会随着疲劳程度、情绪状态变化固定阈值用久了就不准了。7.3 用 OTA 升级避免反复插拔烧录项目部署到墙上之后每次改代码都要把 ESP32 拆下来插 USB 烧录非常麻烦。所以我加了 OTAOver-The-Air升级功能。Arduino IDE 里用ArduinoOTA库几行代码就能实现#include ArduinoOTA.h void setup() { ArduinoOTA.begin(); } void loop() { ArduinoOTA.handle(); }烧录一次带 OTA 的固件之后后续就可以在 Arduino IDE 里选择网络端口直接上传不需要插 USB。OTA 升级的时候要注意升级期间关闭红外发送和脑电解析避免升级过程中触发误操作。另外OTA 的密码一定要设不然同一个 WiFi 网络下的任何人都能给你刷固件。7.4 功耗优化与供电方案选择如果这个项目要长期挂在墙上供电方案就得认真考虑。我试过三种供电USB 充电器、18650 锂电池、PoE以太网供电。USB 充电器最简单但线露在外面不好看18650 锂电池可以藏在设备盒里但需要定期充电而且 ESP32 的 WiFi 功耗不低2000mAh 的电池大概只能撑 8 小时PoE 最优雅一根网线同时供电和传数据但需要额外的 PoE 分离模块成本高一些。最终我选择了 USB 充电器加隐藏走线因为家里装修时已经在墙角预留了 USB 插座。如果你没有预留插座我建议用 18650 电池加太阳能板白天充电晚上用虽然麻烦一点但完全无线。功耗方面关闭 WiFi 省电模式后ESP32 的平均电流在 120mA 左右加上 NPG Lite 的 30mA 和红外模块的待机电流总功耗大概 160mA。如果用 5000mAh 的电池理论续航 30 小时左右实际因为电池放电曲线和转换效率大概 20 小时。8. 一些关于脑控家电的实话这个项目做下来我最大的感受是脑控家电在技术上已经完全可行但它的定位应该是“辅助控制”而不是“替代控制”。注意力值这个指标虽然直观但它的精度和稳定性还不足以支撑精细操作。比如你想用脑控调空调温度从 26 度调到 25 度这个“调一度”的意图很难从脑电信号里可靠地识别出来。但“开”和“关”这种二值操作脑控的准确率可以做到 90% 以上体验就很好了。另一个体会是脑电模块的佩戴舒适度直接决定了这个项目会不会被长期使用。NPG Lite 的头环戴久了会夹头电极片贴久了会痒这些都是实际使用中的痛点。如果你打算把这个项目产品化佩戴舒适度的优先级应该排在信号精度之前。毕竟一个不舒服的设备信号再好用户也不想戴。最后说一个我踩过的坑不要试图用脑电信号做“连续控制”比如用注意力值的高低来控制灯的亮度。我试过效果很差因为注意力值本身波动就大映射到亮度上就是忽明忽暗看起来像接触不良。二值控制加状态机才是脑控家电最务实的方案。
