每到学期末物联网工程专业的班级群里就会集中冒出几类求救帖出现频率最高的一个题目就是「睡眠质量检测系统」。这个题目看起来友好——传感器不贵、场景贴近生活、演示效果直观但它真正的坑在于它是少数几个要求你把「感知层采集精度」「边缘侧算法」「云端数据链路」三条线同时打通并且最后还要拿出一份能被非技术背景的人看懂的结论的题目。我前后帮学弟学妹们调过四五个版本的睡眠监测大作业从最开始用压电薄膜加Arduino Uno的简陋版一路做到ESP32-S3加毫米波雷达加云端看板的精修版踩过的坑足够写一本小册子。这篇就把整套思路、选型逻辑、代码骨架、调试实录完整摊开来讲不管你是刚拿到题目的新手还是已经焊好板子但数据一直飘的同学都能从里面找到能直接抄的部分。1. 选题拆解这个期末大作业到底在考什么1.1 别把它当成传感器读数上传的练习很多同学第一反应是把睡眠监测理解成「读一个传感器把数字发到云上画个折线图」。按这个理解做出来的东西答辩时老师问一句「你怎么判断我是深睡还是浅睡」就崩了。睡眠质量检测的核心难点从来不在传输而在于三个层面的推理链条第一层是物理量到生理量的映射比如雷达回波相位变化怎么变成呼吸率和心率第二层是生理量到睡眠状态的映射比如体动、呼吸节律、心率波动怎么组合出睡眠分期第三层是状态到结论的映射比如连续几晚的深睡时长、入睡潜伏期、夜间觉醒次数怎么汇总成一个可读的评分。这个题目之所以被反复选恰恰因为它天然覆盖了物联网的三层架构而且每一层都有真实的不确定性需要处理传感器会被床垫厚度影响算法会被翻身动作干扰网络会在半夜断一次。能把这三类不确定性都交代清楚并给出应对方案才是这个作业的得分上限所在。我在带人的时候常说一句话如果你做出来的系统在白天坐着的状态下也能输出你正在深睡那说明你做的其实是个随机数生成器。判断自己做得对不对最简单的标准是——你愿不愿意让老师把设备带回家睡一晚。1.2 需求侧一个及格的系统必须回答的五个问题把需求列清楚比着急买器件重要得多。我一般会先逼着组员把下面的问题写成一页纸写不出来就别开工。设备放在哪里床垫下、床头柜上、还是枕头边摆放位置直接决定你能用哪一类传感器。测的是谁单人还是双人双人场景下非接触式传感器的串人问题几乎无解必须提前声明单人场景。一晚要采集多久按7小时算采样率200Hz光是原始数据就是上千万个点你必须做边缘侧降采样。用户第二天想看什么入睡时间、起床时间、深睡时长、夜间觉醒次数、平均心率呼吸率、环境温湿度光照噪声。断网了怎么办存本地多久重连后怎么补传把这五条写清楚你的方案选型基本就自动收敛了。这也是答辩时最容易加分的地方——老师问的任何问题你都能回到需求文档上找依据而不是临场编。1.3 适合谁做做完能带走什么这个题目对基础的包容度很高。如果你只学过C语言和一点点单片机用ESP32加DHT11加光敏电阻也能做出一个环境维度的睡眠舒适度监测把重心放在数据链路和可视化上同样能拿不错的分数。如果你愿意多花两周啃信号处理加上毫米波雷达或者压电薄膜就能把生理参数这一块撑起来做成真正有说服力的睡眠分期。从我个人的经验看这个项目最值钱的副产品是三个能力一是把FreeRTOS的多任务调度真正用起来而不是delay到底二是学会用滑动窗口和滤波处理真实世界的脏数据三是走通一条从设备到云端到前端的完整链路这在找实习时是能拿出来讲的实打实的东西。2. 系统总体架构与方案选型2.1 三层架构怎么切分职责我在精修版里用的架构是感知层负责多传感器同步采集边缘层负责滤波、特征提取和睡眠分期推理云端负责存储、长周期统计和可视化。这个切分的关键决定是——把睡眠分期放在设备端算而不是把原始波形传上云再算。原因有三个。第一是带宽200Hz三轴加雷达相位一晚 raw 数据轻松上百兆用WiFi全传上去第二天手机热点流量就没了。第二是延迟和体验用户早上起来想看昨晚的结论如果云端算要等几分钟演示的时候就很尴尬。第三是可靠性分期算法在本地跑断网也不影响核心功能网络只负责锦上添花的报表同步。代价是设备端算力要吃紧一点ESP32-S3的双核加向量指令刚好能扛住这也是我后面选它的主要原因之一。2.2 主控选型为什么最后落在ESP32-S3早期版本我用的是Arduino Uno加ESP-01做到第三周就撑不住了Uno的RAM只有2KB一个20秒的雷达数据窗口都存不下更别说什么滤波。换到ESP8266好一点但只有一个核心WiFi协议栈一忙起来采样任务就丢点。最后换成ESP32-S3主要看中四点。一是双核我可以把一个核心专门喂给采集任务另一个核心跑WiFi和MQTT两边互不抢占。二是自带向量指令做定点FFT和滑动平均的时候比纯软件乘加快不少。三是外设够用I2C、SPI、UART加起来能挂五六种传感器还留了PSRAM扩展位。四是生态成熟Arduino框架和ESP-IDF都能用库的坑别人基本踩过一遍。这里给一个选型对比方便你按自己的时间预算做决定主控适合的场景主要瓶颈我的建议Arduino Uno ESP-01只做环境舒适度监测RAM 2KB无法缓存波形只在时间极紧时选且砍掉生理参数ESP8266单传感器简单上传单核采样易丢点能跑但睡眠分期别想了ESP32经典款双核蓝牙WiFi性价比高ADC线性度一般蓝牙与WiFi共存有干扰预算紧的首选ESP32-S3需要FFT、多传感器、PSRAM价格略高开发板稍贵我最终的方案推荐2.3 传感器组合的取舍逻辑传感器这块最容易花冤枉钱。我的建议是分三层来配先保证前两层跑通再考虑加第三层。第一层是环境量包括温湿度、光照、噪声。这一层成本极低DHT22或者SHT30加一个光敏电阻加一个模拟声音模块几十块钱搞定而且数据直观、不容易出错是答辩时的保底分。第二层是体动量用MPU6050加速度计贴在床板或者床垫下通过体动能量判断翻身和觉醒。这一层是睡眠分期的主力成本也就十几块。第三层才是生理量毫米波雷达或者压电薄膜用来提取呼吸率和心率这一层难度陡增是提分项而不是必需项。很多同学一上来就买雷达结果发现数据全是噪声最后连环境量都没做完。我的顺序建议永远是先把环境量和体动量做扎实腾出两三天时间专门啃雷达能出呼吸率就赚了出不来就把它当体动传感器用也不亏。2.4 云端链路的现实考量云平台这块钱是个变量。学校课程里通常会推荐某个主流物联网平台但平台的产品策略、试用额度、实例购买方式都可能随时间调整去年能免费开通的实例今年可能就需要走别的流程了。所以在动手之前务必先跟老师确认本学期的账号和实例怎么获取别等到答辩前一天才发现连不上。我给出一个稳妥的双轨方案主链路用老师指定的平台走MQTT同时本地用一台笔记本或者树莓派跑一个开源MQTT broker比如Mosquitto或者EMQX做备用接收端。这样即使云端账号出问题你的设备依然能连本地broker完成演示数据链路照样是完整的。这个本地兜底的设计思路本身在答辩时也是一个加分点——它说明你考虑了单点故障。3. 硬件搭建与传感器落位3.1 器件清单与预算分配精修版的完整清单如下我按优先级排了序预算紧的话可以从下往上砍。序号器件型号建议作用参考价1主控ESP32-S3 开发板带PSRAM采集算法联网40-70元2温湿度SHT30I2C环境舒适度15元3光照BH1750I2C判断环境光干扰8元4声音MAX9814 或 模拟麦克风模块夜间噪声、打鼾粗判12元5体动MPU6050I2C翻身、觉醒检测10元6生理24GHz/60GHz 毫米波雷达模块呼吸率、心率150-400元7生理备用压电薄膜电荷放大呼吸起伏30元8执行5V继电器或ULN2003A小风扇联动调节10元9电源5V/2A适配器 一路锂电池备份断电续跑30元注意雷达这一项价格跨度很大便宜的模块往往只能出体动出不来心跳。买之前一定看清模块手册里有没有生命体征检测的例程只写存在感应的那种做呼吸率都费劲。3.2 非接触式检测的落位技巧毫米波雷达的落位是整套硬件里最玄学的一环我总结了三条实战经验。第一别垂直于胸腹正上方。很多人直觉是雷达贴着床垫、正对胸口最好实际上正对时胸腔起伏带来的相位变化太集中容易在呼吸暂停的瞬间丢失信号。把雷达稍微斜置偏离胸腔中心10到20厘米让波束同时覆盖胸腹和部分床面反而更容易捕捉到规律的微动。第二床垫厚度是硬约束。我用的是普通乳胶加弹簧的结构雷达在床板下方能穿透但如果床垫超过25厘米而且夹了金属弹簧层信号衰减会非常明显。这种情况下把雷达挪到床头侧面用侧向波束打上半身效果比床底好。压电薄膜则相反它必须紧贴承重面放在床板与床垫之间越靠近人体越好。第三一定要做空床基线。每次布置完先采集三分钟没人躺的空床数据把这段时间的能量均值算出来当作噪声底后面所有阈值都相对这个底来设。这个操作花三分钟能省下你后面两小时的参数瞎调。我见过太多人拿实验室测的固定阈值回家用结果因为床垫不同整晚数据全被判成清醒。3.3 环境量传感器的布点细节温湿度传感器最忌讳贴着发热源。ESP32-S3本身在WiFi发送时会有明显温升把SHT30直接插在主板旁边测出来的温度会比实际高两三度。我的做法是用一根I2C延长线把传感器引到床头位置离主板至少30厘米并且在固件里加一个简单的温度补偿——设备连续工作一小时后根据实测偏差减掉固定的偏移量。光照传感器要避开你自己的指示灯。开发板上的电源灯和状态灯在夜里非常亮如果BH1750和它共处一室夜间光照读数会被拉高误判成环境光干扰睡眠。我最后是把状态灯直接用黑胶带贴掉只保留一个软件控制的可熄灭LED。声音这块模拟麦克风容易受电源纹波干扰读出来的底噪忽高忽低。建议在麦克风的电源脚上并一个10微法加100纳法的电容软件上再加一层滑动中值滤波。另外麦克风的AGC自动增益要关掉否则安静的夜里它会自动把音量拉满把风扇声放大成打鼾。3.4 IO不够时的扩展思路做到联动控制这一步你会发现IO很紧张风扇、加湿雾化片、蜂鸣器、状态灯再加上传感器占用的I2C和UARTGPIO基本见底。这时候ULN2003A这类达林顿阵列就是救急方案。它一片能提供七路驱动每路能扛500毫安左右的负载输入侧只需要几百微安的电流就能拉低恰好解决单片机IO推不动大负载的问题。接线逻辑很简单单片机GPIO接ULN2003A的输入脚输出脚接负载的负极负载正极接电源正极同时把负载的续流二极管接好模块上一般已经集成。注意三点一是输入脚内部已经有基极电阻一般可以直接接3.3V逻辑但如果你买的是裸芯片要自己串一个1k到2k的电阻二是感性负载比如小风扇、继电器线圈一定要有续流回路否则关断瞬间的反峰会打坏IO三是ULN2003A是灌电流输出不要指望它输出高电平去驱动东西。供电也是同一个道理。雷达模块和WiFi瞬时电流都不小如果全部从开发板的3.3V引脚取电会出现一联网雷达就掉线的怪现象。我的做法是雷达单独走一路低压差稳压器LDO并在模块电源脚就近放一个470微法的电解电容。这个改动很不起眼但把整晚数据的连续性提升了一个档次。4. 固件实现从采样到上传的完整链路4.1 用FreeRTOS把采样节拍拆开别再用一个loop加delay了。采样任务一旦被WiFi阻塞就会出现规律的丢点而你从数据上只会看到昨晚呼吸率奇怪地偏低。我的任务划分是这样的task_radar核心0200Hz定时采样雷达相位与I/Q数据写入环形缓冲区task_env核心1每2秒读一次温湿度光照噪声task_imu核心050Hz读加速度实时算体动能量task_algo核心1每30秒对缓冲区做一次特征提取与分期推理task_net核心1每60秒组包发MQTT断网时写本地队列雷达采样我用定时器中断配合队列做节拍伪代码大致如下// 200Hz 采样5ms 一个节拍 hw_timer_t *t timerBegin(0, 80, true); // 1us 计数 timerAttachInterrupt(t, [](){ radar_sample_t s; s.ts esp_timer_get_time(); radar_read(s.i, s.q, s.phase); xQueueSendFromISR(radar_q, s, NULL); }, true); timerAlarmWrite(t, 5000, true); // 5000us 5ms timerAlarmEnable(t);中断里只做读数入队这一件事所有计算放到任务里做。这是硬性纪律中断里做FFT是新手最常见的翻车点。4.2 数据预处理三层滤波怎么定参数原始数据里主要有三类脏东西高频电子噪声、低频基线漂移、以及翻身引起的尖峰。对应三层处理。第一层去尖峰。用一个长度为5的滑动中值滤波专门干掉翻身瞬间的突变点同时不改变呼吸波形的形状。为什么用中值而不是均值因为均值会被尖峰拉偏一个翻身能把整段均值抬高。第二层带通。呼吸的基频在0.2到0.5Hz之间心跳在0.8到2.0Hz之间我用一个四阶巴特沃斯带通把这两段分开。这里有个参数计算值得说清楚雷达采样率200Hz取20秒窗口就是4000个点做FFT后频率分辨率是200/4000等于0.05Hz。这意味着呼吸频段0.2到0.5Hz之间只有6个频点分辨率非常粗糙。解决办法是把窗口拉到60秒分辨率提升到0.0167Hz代价是时间分辨率下降不适合捕捉呼吸暂停。我在实测里折中取30秒窗口分辨率0.033Hz配合峰值插值呼吸率的误差能控制在每分钟1到2次以内。第三层基线漂移去除。用截止频率0.05Hz的一阶高通或者更省算力的做法——直接减去滑动均值。我后来用的是指数加权移动平均时间常数取20秒一行代码搞定效果够用。处理层方法参数目的去尖峰滑动中值窗口5点抑制翻身突变分离生理量四阶巴特沃斯带通呼吸0.2-0.5Hz / 心跳0.8-2.0Hz提取呼吸与心跳去漂移指数加权移动平均时间常数20s消除基线慢漂平滑输出滑动均值呼吸窗口15s让显示值不跳变注意滤波参数必须在真实床垫上重新标定。实验室铁架床和家里的弹簧床垫最优窗口长度可能差一倍。4.3 睡眠分期的轻量化实现必须先把话说在前面设备端的睡眠分期只能是近似判断不能宣称医疗级。我在代码注释里写得很清楚它是基于体动能量、呼吸率变异性、心率波动三个特征的规则推理不是多导睡眠图的替代品。我用的规则库大致如下状态体动能量呼吸节律心率相对基线持续条件清醒高基线5倍不规则偏高持续2分钟浅睡低-中规律略降是入睡后的默认态深睡极低基线1.2倍规律且偏慢最低连续10分钟疑似REM低但偶有微动不规则、幅度波动波动明显持续5分钟睡意的判定我用了一个入睡潜伏期逻辑连续10分钟体动能量低于阈值且呼吸率方差小于设定值就标记为入睡起点同时把这段之前的清醒时长算作潜伏期。这个指标在答辩时非常好讲因为它是睡眠医学里公认的参考量。分期状态切换我加了迟滞避免在边界来回跳。具体做法是设两个阈值进入深睡需要能量低于低位阈值退出深睡需要高于高位阈值两个阈值之间留20%的缓冲。这个技巧能让你早上的曲线看起来像那么回事而不是一片花斑。4.4 MQTT上云与断网续传数据包我设计成60秒一个JSON结构贴近物模型{ ts: 1730563200, hr: 62, br: 15, motion: 0.03, stage: 2, env: { temp: 24.6, humi: 52.1, lux: 3, db: 34 }, quality: { latency: 420, awaken: 1 } }这里有两个设计细节值得说。第一我传的是分钟聚合值而不是原始波形心率呼吸率取这一分钟的稳健均值去掉最高最低各20%再平均体动能量取均方根。这样一条消息不到200字节一晚也才420条左右流量压力几乎为零。第二我在消息里带了quality字段记录网络的往返延迟。这个字段平时没什么用但当老师问你怎么证明数据是实时上云的把它调出来就能说明问题。断网续传我是这么做的先在SPIFFS里开一个固定大小的环形文件比如512KB够存好几晚发送成功才把记录标记为已发。重连后按时间顺序补发并且带原始的ts而不是补发时刻。这一点很关键——如果你补发时用了当前时间云端的时间序列会全部挤在一起图就废了。// 简化版发送逻辑 if (mqtt.connected()) { if (mqtt.publish(topic, payload.c_str())) { storage_mark_sent(seq); } else { storage_append(payload, seq); // 落盘等下次补发 } } else { storage_append(payload, seq); }4.5 低功耗与供电的实测数据整晚插电当然最省事但如果你要做成可移动的功耗就绕不开。我实测了几个档位工作模式平均电流2000mAh电池续航说明全速雷达常开WiFi常连约150mA约13小时一晚够用但没余量占空比雷达1秒开1秒关约95mA约21小时呼吸率略受影响分类唤醒无人时不采样约40mA约50小时需要雷达保持低功耗存在检测仅环境量体动约35mA约57小时放弃生理参数我最常用的档位是占空比因为它和分类唤醒的差别在于实现复杂度——后者要雷达支持低功耗存在检测模式不是所有模块都有。占空比方案只需要在采集任务里加一个计数器实现成本几乎为零而电池续航能多撑一晚。这里补一句供电的经验锂电池从3.7V升到5V再降到3.3V两次变换的效率损失能到15%以上。如果做纯电池版尽量选支持3.3V直供的模块或者用一颗低压差稳压器从电池直降能省下不少电。5. 云端数据链路与可视化5.1 物模型设计先想清楚属性和事件云平台上最容易做错的事情是把所有字段一股脑塞进一个属性里当字符串发。正确做法是按语义划分持续变化的状态量定义成属性比如当前心率、当前呼吸率、当前分期一次性的行为定义成事件比如检测到觉醒报告生成完成可下发的配置定义成服务比如设置采样间隔校准空床基线。我最终的物模型大致是这样组织的属性里放temperature、humidity、illuminance、noise、heart_rate、breath_rate、body_motion、sleep_stage八项事件里放sleep_report每晚一条携带汇总评分和awaken_event每次觉醒触发。这样后端做统计的时候属性表是时序数据事件表是离散记录两张表各司其职查询起来非常顺。5.2 数据落库与流转规则数据上云之后要能存下来才有价值。我走的是平台规则引擎把消息转发到数据库的路子转发时用一条简单的处理脚本把JSON拍平-- 落库表结构简化 CREATE TABLE sleep_metric ( id BIGINT AUTO_INCREMENT PRIMARY KEY, device_id VARCHAR(64), ts BIGINT, heart_rate INT, breath_rate INT, body_motion FLOAT, sleep_stage TINYINT, temp FLOAT, humi FLOAT, lux INT, db INT ); -- 起床后生成日报的查询思路 SELECT MIN(ts) AS sleep_start, MAX(ts) AS sleep_end, AVG(heart_rate) AS hr_avg, SUM(sleep_stage 2) * 60 AS deep_sleep_sec, SUM(sleep_stage 0) * 60 AS awake_sec FROM sleep_metric WHERE device_id ? AND ts BETWEEN ? AND ?;深睡时长那里我直接用了SUM(sleep_stage 2) * 60因为每条记录代表60秒。这个写法很土但极其好用答辩时老师问深睡时长怎么算的你一句话就能解释清楚不会露怯。如果你用的是自建broker方案把规则引擎换成一段订阅脚本即可逻辑完全一样只是落库要自己写。5.3 看板前端的几个坑看板不用做得花哨但有几个细节不做你在演示时会很难看。第一时区。云平台存的时间戳通常是UTC毫秒或者秒前端直接渲染会显示成下午三点睡觉。我最后是在前端统一做一次时区偏移或者在落库时就转成本地时间戳二选一千万别两头都转会差出八小时。第二曲线的时间轴必须锁死。睡眠数据的横轴应该是当晚20点到次日12点固定住不能随数据自动缩放。我第一版没锁结果只有3小时数据的那晚横轴被拉满看起来像是连续睡了整晚第二天复盘时被组员当场指出非常尴尬。第三缺失值。设备半夜重启过、网络断过都会导致某分钟没有数据。前端不能直接连点成线那样会画出一条不存在的平滑曲线。正确做法是断开处留空或者标灰。这个小细节是专业感的来源很多同学栽在这上面。// 时间轴固定 缺失值断线ECharts 思路 xAxis: { type: time, min: startOfNight.getTime(), max: noonNextDay.getTime() }, series: [{ connectNulls: false, // 关键不要把缺失点连起来 data: points // 缺失处放 null }]5.4 数据隐私要提前考虑睡眠数据是典型的敏感个人信息哪怕只是课程作业也建议在报告里写清楚三条设备只上传聚合后的分钟级数值不传原始波形本地缓存文件在每日同步成功后自动截断设备与云端的通信走加密通道且每台设备使用独立凭证。这三点写进报告既是合规意识的体现也是答辩时能把话题主动权拿在手里的地方。6. 联调踩坑实录与常见问题速查6.1 硬件层那些让你怀疑人生的现象现象一雷达数据每隔十几秒出现一段全零。这个我查了整整一天最后发现是WiFi发送时的瞬时电流把雷达的供电电压拉下去了。解决办法就是前面说的雷达单独走一路稳压加一个大电容。判断方法很简单把WiFi关掉如果数据连续了就是供电问题。现象二SHT30读数比实际高3度。这是主板自发热导致的不是传感器坏了。把传感器用延长线挪远或者按前面说的做固定偏移补偿。现象三加速度数据在半夜出现规律性的1Hz大摆动。这个别急着改代码先想想床旁边是不是有风扇或者空调在吹风会把震动传到床板上。这种物理层面的干扰只能通过安装位置解决滤波去不掉。现象四整机跑几小时后死机。九成是内存泄漏重点查JSON对象的创建和销毁以及MQTT客户端有没有重复初始化。我习惯在任务里周期性打印esp_get_free_heap_size()看到数值一路下滑就说明有泄漏。6.2 数据层算法输出不合理怎么排问题现象最可能原因排查动作呼吸率整晚恒定不变卡在某个默认值信号没进来打印原始窗口数据检查是否全零或饱和呼吸率偏高到30以上把体动或者心跳的二次谐波当成呼吸检查带通参数看频谱峰值位置分期结果全是深睡空床基线没做阈值过松重新采集空床数据重设相对阈值分期结果全是清醒阈值太严或者体动传感器没贴紧检查加速度幅值范围重设迟滞阈值每晚数据长度不一致采样任务被阻塞、丢点统计实际采样点数与理论值之比这里特别说一条经验先看原始数据再看算法输出。我见过太多同学一发现结果不对就去调算法的阈值调了两天最后发现是传感器根本没接好。养成习惯出问题第一件事是把最近5分钟原始数据打印出来或者画出来看一眼波形是不是符合物理直觉。6.3 云端层连接类问题的快速定位连接问题基本可以按下面的顺序二分定位设备能不能连上WiFi看串口日志里的IP地址有没有分配成功。能不能连上broker注意端口普通MQTT和加密MQTT的端口不一样用错端口通常连不上或者立刻断开。凭证对不对三元组产品、设备、密钥任何一个字符错都会握手失败建议把三元组写进单独的配置文件不要硬编码在业务代码里。主题写对了吗上报和下发主题的格式有严格规范多一个斜杠就是无权限。消息发出去了但云端看不到打开平台的日志服务看有没有落库同时用本地broker抓一份对比确定问题在设备侧还是云端侧。关于平台实例开头提过一次这里再强调不同学期、不同批次的可选实例和开通方式可能变化务必以老师当期给的说明为准。我的建议始终是——保留一个本地broker做兜底把演示风险降到最低。6.4 答辩演示的稳定性预案答辩前一晚我一般会做三件事。第一跑一次完整的通宵测试第二天早上导出数据确认时间轴连续、没有大段空洞。如果中间有断档先记下时间点回头查是网络问题还是设备重启。第二准备一份离线演示数据。把最好的一晚数据导出成JSON放进前端即使现场WiFi连不上也能展示完整看板。这不是作弊这是工程预案。第三把关键日志做成截图放进PPT。老师问你怎么确定它是实时上云的你翻出带时间戳的串口日志和云端消息日志对上比口头解释有说服力得多。提示演示时不要把设备放在离路由器太远的位置。夜间监测距离远、穿墙多丢包率会明显上升而演示现场的环境你没法控制挪近两米往往就能救回一场答辩。7. 后续可以继续加的东西如果时间还有富余我会优先加三个方向。第一个是双设备协同床头放一个环境节点床垫下放一个生理节点两者通过低功耗蓝牙或ESP-NOW对时后各传各的这样布线更自由也顺便演示了多节点组网。第二个是本地语音播报早上起床后用一个简单的语音模块念出昨晚的睡眠报告演示效果直接拉满答辩老师会记住你。第三个是把历史数据做成周报和月报用趋势线展示睡眠规律的变化——这一步涉及到数据可视化里的降采样是个不错的延伸点。我在这个项目上前后耗了大概六周真正卡住我的从来不是代码写不出来而是不知道自己的数据对不对。所以最后分享一个我一直在用的小习惯每做完一个模块先用最简单的办法验证它的物理合理性——呼吸率必须在每分钟8到25次之间夜间环境温度应该缓慢下降再回升体动能量在入睡前后应该有明显落差。任何一条不满足就先别往下做回去查。这个习惯帮我省下的时间比我学会任何一个库都多。
