最近把这几年积累的传感器开发和嵌入式方案经验，全部沉淀到了一个项目上：基于STM32的毫米波雷达智能睡眠监测系统。说白了就是用一块24GHz毫米波雷达模块，配合STM32做主控，实现非接触式的呼吸检测、心率提取和睡眠状态判断。这套方案不需要在身上贴任何电极，也不用戴手环，人往床上一躺，雷达就能隔空感知到胸腹部的微动，再把呼吸和心跳频率算出来。整体做下来，项目从硬件选型到算法落地再到板上调试，链路非常完整，很适合作为毕业设计、智能家居产品原型或者医疗看护设备的前置验证。
先交代一下背景。这两年睡眠健康话题越来越受关注，但传统监测手段要么侵入感强，要么对环境要求苛刻。手环和指夹血氧仪虽然便宜，但戴着睡总归不舒服，而且翻身多了容易脱落；摄像头方案又牵扯隐私，夜里光线不足也会影响效果。毫米波雷达恰好绕开了这些痛点：不接触人体、不受光照影响、能穿透床单被褥，直接通过微动信号感知生命体征。再加上STM32系列芯片性能足够、外设丰富、开发资料多，两者一搭配，整个系统的硬件成本和开发门槛都能控制在很低的范围。如果你正在做类似的项目，或者想从零开始做一个“传感器+MCU+算法”的完整嵌入式项目，这篇文章应该能帮你少踩很多坑。
1. 项目整体设计与方案选型
1.1 为什么是毫米波雷达，而不是摄像头或普通传感器
刚开始立项的时候，我也纠结过到底用哪种传感器。第一反应是普通的红外热释电传感器，但热释电只能检测人体移动，分辨不了呼吸这种微弱动作。后来又考虑过摄像头加视觉算法，但隐私问题直接劝退——睡眠监测的应用场景是卧室，你不可能在床头架一个摄像头对着人拍。对比下来，毫米波雷达的优势就很明显了。
毫米波雷达的基本原理并不复杂，它通过天线发射高频电磁波，电磁波碰到人体表面后反射回来，雷达接收端再对回波信号做混频和解调。关键点在于，人体在呼吸和心跳时，胸腹部会有非常微弱的周期性起伏，幅度通常在毫米甚至亚毫米级别。这个起伏会让雷达回波的相位产生对应的变化，通过提取和分析回波相位，就能还原出呼吸频率和心率。
打个比方，你站在远处看一个正在缓慢充气放气的气球，肉眼很难看清它的变化，但如果用一把高精度的尺子去量它的直径，还是能发现规律。毫米波雷达就相当于那把尺子，只不过它量的是电磁波相位。FMCW体制的雷达模块还能通过距离FFT区分不同距离上的目标，这样即使人盖着被子或者侧躺，雷达也能锁定人体所在的距离单元，继续提取微动信号。
方案对比下来，毫米波雷达在睡眠监测场景里有几个不可替代的优势：非接触、无感监测；不受光线影响；能穿透被子衣物的遮挡；不采集图像，没有隐私争议；硬件模块成熟，价格已经降到百元级。这些特性决定了它是目前做智能睡眠监测最合理的传感器选择。
1.2 为什么主控选STM32，系统架构怎么搭
传感器定了，主控的选型就容易了。系统需要做的事情包括：接收雷达模块的数据、做滤波和频谱分析、判断睡眠状态、驱动显示模块，可能还要联网上报数据。这些任务对主控的要求是：具备UART、I2C、SPI、ADC等常用外设，有足够的运算能力跑FFT，功耗不能太高，开发工具链要成熟，资料要多。
对比一下其他方案就能看出STM32的合理之处。树莓派确实算力强，Python写算法也舒服，但一个树莓派的成本和体积，对睡眠监测这种小设备来说严重过剩，而且启动慢、实时性一般。Arduino Mega倒是简单，但ATmega2560的算力跑几十点FFT都很吃力，更别说叠加状态机逻辑。STM32刚好卡在中间：以经典的STM32F103C8T6为例，72MHz主频、64KB Flash、20KB RAM，跑256点FFT完全能胜任，一块最小系统板成本才十几块，开发环境无论是标准库还是HAL库都有大量现成例程。
整个系统的架构很清晰，分三层：
- 感知层：24GHz毫米波雷达模块，负责发射和接收雷达信号，输出人体目标信息（距离、微动幅度或直接输出呼吸心率数据）。
- 主控层：STM32负责接收雷达数据、执行信号处理算法、判断睡眠状态，并驱动显示和通信模块。
- 交互层：OLED屏幕本地显示呼吸心率，或者通过ESP8266/WiFi模块把数据上报到手机或上位机。
我这次用的方案是STM32F103C8T6最小系统板加一个串口输出的24GHz生命体征检测模块。如果后续想跑更复杂的算法，比如多目标跟踪或者神经网络存在检测，可以升级到带FPU的STM32F401/F411系列，代码框架不需要动太多。预算上，整套核心硬件控制在200元以内完全没有压力。
2. 硬件核心：24GHz雷达模块与STM32的配合细节
2.1 雷达模块怎么选，输出数据格式到底是什么
这是项目里第一个容易踩坑的地方，市面上的24GHz毫米波雷达模块看起来都差不多，实际上分成两种完全不同的类型。
第一种是带算法封装的成品模块，雷达前端、信号处理、生命体征算法全部集成在模块里，对外通过UART输出解析好的数据，比如目标状态、距离、呼吸频率、心率、体动等级。这种模块开发最简单，STM32只需要做串口接收和协议解析，二三十分钟就能跑通通信。
第二种是雷达前端模块，只输出I/Q中频信号，所有信号处理都要自己在MCU里做。这种模块自由度更高，适合想深入研究雷达算法的人，但开发周期会明显拉长。我自己的建议是，如果你做这个项目的核心目标是展示系统集成能力和睡眠状态判断逻辑，选第一种就够了；如果你想在算法上有亮点，比如自己写FFT提取生命体征参数，那就选第二种，用STM32的ADC采集I/Q信号。
具体到模块参数，注意几个点。检测距离方面，睡眠监测不需要像车载雷达那样做到几十米，一般0.5米到2米的近距检测足够，床头柜安装和床侧安装都能覆盖。视角也很重要，优先选择横向视场角比较大的模块，保证人在床上翻身移动时不会丢失目标。再就是输出频率，如果串口型模块输出的呼吸心率刷新率太低（比如1秒1次），体验会很差，建议选刷新率在10Hz以上的。
串口型模块的数据格式通常是一组定长帧，我遇到的是这样的结构：帧头（如0xA5 0x5A）＋数据长度＋目标状态＋目标距离＋呼吸频率＋心率＋体动等级＋校验字节。不同厂家协议差异很大，做开发前一定要先去下载模块的串口协议文档，看清楚每个字节的含义。一个非常实用的调试技巧是，先用USB转TTL把模块接到电脑串口助手，直接看原始数据。如果模块输出的是一堆看似乱码的数据，多半是波特率不对，常见波特率有9600、115200，逐个试一遍。
2.2 硬件接线与电气注意事项
硬件连接上，如果选用串口型模块，接线非常简单：
| 雷达模块引脚 | STM32引脚 | 说明 |
|---|---|---|
| VCC | 3.3V或5V（按模块手册） | 供电 |
| GND | GND | 共地 |
| TXD | PA10（USART1_RX） | 雷达发送数据给STM32 |
| RXD | PA9（USART1_TX） | 可选，STM32发送配置命令给雷达 |
需要特别注意电平匹配。很多24GHz雷达模块的串口是3.3V TTL电平，和STM32的引脚电平一致，可以直接连接。但也有一部分模块标注的是5V电平，如果直接怼到STM32的PA10上，时间长了可能烧坏GPIO。稳妥的做法是先用万用表量一下模块TXD引脚的空闲电平，3.3V左右可以直接连，5V就加一个电平转换模块，或者用两个电阻做分压。
雷达模块的安装位置和角度对信号质量影响非常大，这一点特别容易忽略。我踩过的坑是：一开始把雷达模块平放在床头柜上，天线面朝上，结果人在床上怎么躺都检测不到稳定信号。后来翻手册看到，雷达的天线面应该尽量正对人体胸腹部，最好的安装方式是挂在床头靠板或者床侧的支架上，让雷达波束斜向下照射到人的躯干。模块周围不要有金属物体，天线正前方不要被金属装饰、金属框架遮挡。如果设备需要装进外壳，外壳在雷达天线区域一定不能用金属，最好开窗或者用非金属薄板覆盖。
还有一个供电问题。我一开始用电脑USB口给整套系统供电，雷达模块的呼吸心率数据经常出现间歇性丢失，用示波器一看，3.3V电压纹波非常大，而且USB口供电能力有限，雷达发射瞬间的电流波动直接把电压拉下去了。后来改用单独的5V/1A适配器给系统供电，在雷达模块电源引脚附近加了10uF和100nF的退耦电容，问题立刻消失。做这类射频相关项目，供电质量再强调都不为过。
3. 核心算法：睡眠状态怎么从雷达数据里算出来
3.1 从微动信号到呼吸、心率：滤波与FFT
如果用的是串口型模块，呼吸和心率已经由模块内部算好，STM32可以直接用；但如果你想自己在STM32上做完整的数据处理，或者准备在答辩时讲清楚原理，这条信号处理链路必须理解。
呼吸频率和心率在频谱上处于完全不同的频段：正常成年人呼吸频率约0.1~0.5Hz，对应每分钟6到30次；心率约0.83~2Hz，对应每分钟50到120次。所以算法流程可以这样设计：
- 从雷达模块获取目标距离门上的I/Q信号（或者微动幅度序列）。
- 对数据做去直流处理，去掉由于人体静态位置带来的直流偏置。
- 用带通滤波器分离两个频段：呼吸通道滤波通带设为0.1~0.5Hz，心率通道滤波通带设为0.8~2.5Hz。没有高通滤波时，人体缓慢翻身造成的基线漂移会完全淹没微弱的呼吸峰，这是新手最常见的失败原因。
- 对滤波后的数据加窗（汉宁窗或汉明窗），减少FFT的频谱泄漏。
- 做FFT，在对应频段内找峰值，换算成每分钟次数。
具体参数上，如果通过ADC采集I/Q信号，采样率不需要太高。心率最高频率2Hz左右，采样率设到20Hz以上就够了，建议用50Hz留余量。FFT点数越多，频率分辨率越高，例如50Hz采样率下做256点FFT，每帧数据覆盖5.12秒，频率分辨率为0.195Hz，可以满足呼吸和心率的区分需求。每次滑动窗口取一帧数据做一次FFT，然后更新一次频率，实际体验就很流畅。
STM32能否跑这些运算？完全没问题。CMSIS-DSP库本身就包含FFT函数，使用ARM优化的浮点或者定点FFT内核。即使在STM32F103这种Cortex-M3芯片上，256点FFT耗时也就几毫秒到十几毫秒，完全不影响实时性。如果从零手写FFT也不是不可以，但没必要，直接用标准库效率更高。
代码逻辑大致是这个思路：
// 假设adc_buff已填充N点原始信号 for (int i = 0; i < N; i++) { // 1. 去直流 signal[i] = adc_buff[i] - dc_offset; // 2. 加汉宁窗 signal[i] *= 0.5f * (1.0f - arm_cos_f32(2.0f * PI * i / (N - 1))); } arm_cfft_f32(&arm_cfft_sR_f32_len256, signal, 0, 0); arm_cmplx_mag_f32(signal, mag, N); // 3. 在呼吸频段索引范围内找峰值 // 呼吸频段索引: 0.1Hz~0.5Hz / fs * N要提醒的是，如果直接用串口型模块，这些工作模块内部都处理好了，你只需要解析出呼吸心率的数值然后做高层逻辑。我的经验是先把模块数据用上位机软件录下来，对比一下原始数据和模块输出的差值，能帮助你判断模块内部算法的稳定性。
3.2 睡眠分期：清醒、浅睡、深睡怎么判定
睡眠状态判断是这个系统最有“智能感”的部分。专业睡眠监测用的是多导睡眠图PSG，要测脑电、眼电、肌电，工程实现成本极高。但是做民用级别的睡眠状态判断，不需要那么复杂的模态，用三个特征就够：体动情况、呼吸频率和心率变化趋势。
判断逻辑并不复杂，核心是给状态分档：
| 特征 | 清醒 | 浅睡 | 深睡 |
|---|---|---|---|
| 体动 | 频繁，比如30秒窗口内多次翻身 | 偶有体动，翻身较少 | 基本静止，长时间无体动 |
| 呼吸 | 呼吸频率偏快且不平稳 | 比清醒时降低，呼吸有波动 | 呼吸慢而平稳，节律规律 |
| 心率 | 相对较高 | 略低于清醒状态 | 最低，且曲线平缓 |
工程实现时，我用一个滑动窗口扫描雷达输出的数据，每30秒统计一次体动事件数量，同时记录窗口内呼吸心率的平均值和方差。然后做一个简单的状态机：
- 初始状态为“清醒”。
- 如果连续10分钟以上，体动事件很少、呼吸频率低于清醒阈值、心率下降到某个基线以下，则进入“浅睡”状态。
- 如果“浅睡”状态下继续满足“无体动且呼吸非常平稳”的条件，保持一段时间后升级为“深睡”。
- 任何状态下，如果短时间内连续监测到多次强体动，或者呼吸心率明显升高到接近清醒水平，就回到“清醒”状态。
这个逻辑最大的好处是稳健。你不会因为用户刚躺下玩手机5分钟就误判成入睡，因为状态切换有条件要求，必须连续满足一定时长才更新。
3.3 数据平滑策略与误判处理
数据处理光有算法不够，实际运行时会有一堆干扰问题。我调试中遇到最典型的情况是：用户躺在床上一动不动，呼吸心率明明很规律，但系统偶尔会把心率算成某个离谱的值。原因通常是翻身瞬间信号能量突变，或者被子抖动的瞬间微动信号叠加到了心率频段。
解决思路有三个：
- 加中值滤波：将最近5次计算出的心率值排序取中间值，单次毛刺就会被滤掉。
- 加幅度阈值：雷达目标幅度信号如果低于阈值，说明目标信号太弱，计算结果不可信，这段时间的数据直接丢弃，不参与状态判断。
- 一致性检查：呼吸频率和心率不会瞬间突变，如果相邻两次计算结果差值超过20%，大概率是异常，上一帧的结果优先保留。
如果雷达模块支持多目标检测，建议把检测距离范围限制在床面附近，比如只检测0.5米到1.5米内的目标，并选择微动幅度最大的目标作为监测对象。这样做可以避免空调、风扇、窗外的移动物体干扰。
4. 软件实现：从CubeMX配置到系统跑通
4.1 开发环境搭建与首次烧录
软件部分，我的建议是用STM32CubeMX加Keil MDK这套组合，兼顾自动生成代码和手动调试的便利性。如果不想折腾Keil的License，直接用STM32CubeIDE一个工具搞定也行，尤其是新手，IDE集成了编译、下载、调试，少了很多环境配置的烦恼。
第一次使用CubeMX创建工程时，芯片型号选择STM32F103C8Tx。如果发现列表里搜不到，需要先在CubeMX的固件包管理里安装STM32CubeF1固件包，这一步网络不好的时候容易卡住，可以手动下载固件包后离线安装。
时钟配置环节，把HSE设为外部晶振，主频配置为72MHz。如果用的是最小系统板，板上一般有8MHz晶振。外设配置方面，需要使能USART1用于接收雷达数据，如果需要驱动OLED，使能I2C1或SPI1。如果计划自己采集雷达I/Q信号，还要配置ADC。最后在Project Manager里生成工程，选择MDK-ARM V5工具链。
Keil里编译下载的时候有两个常用坑。一是烧录后程序不自动运行，每次复位都要手动按一下复位键，解决办法是在Flash Download页面勾选Reset and Run。二是ST-Link V2识别不到芯片，多半是驱动问题或者SWD接线不对，SWDIO、SWCLK、GND、3.3V四根线一定要接对，如果之前烧过错误的引脚配置把调试口关了，可以用ST-Link的connect under reset模式强制连接。
4.2 串口接收雷达数据的关键坑
串口接收是整个项目里最容易出问题的环节之一。雷达模块持续向STM32发送数据帧，如果处理不好丢帧和粘包，解析出来的呼吸心率就会乱跳。
强烈不建议在主循环里用一个字节一个字节阻塞读取串口数据，也不要一收到中断就做长耗时解析。推荐的方式是用DMA加串口空闲中断来接收不定长数据帧。CubeMX里把USART1的模式配置为Asynchronous，然后在NVIC设置里使能UART全局中断，代码里这样初始化：
// 启动DMA接收，BUFFER_SIZE要比最大帧长更大 HAL_UART_Receive_DMA(&huart1, (uint8_t *)uart_rx_buff, BUFFER_SIZE);在中断回调函数里解析完整帧：
void HAL_UARTEx_RxEventCallback(UART_HandleTypeDef *huart, uint16_t Size) { if (huart == &huart1) { // Size表示收到的字节数 parse_radar_frame(uart_rx_buff, Size); // 重新启动接收 HAL_UART_Receive_DMA(&huart1, (uint8_t *)uart_rx_buff, BUFFER_SIZE); } }注意，老版本的HAL库没有HAL_UARTEx_RxEventCallback这个回调，用的是HAL_UART_RxCpltCallback配合DMA半满/全满中断，逻辑会稍微绕一些。遇到报错或者编译不过，先查自己的HAL库版本和对应函数原型。
解析帧时，一定要校验帧头和数据长度字段，再确认校验字节。我见过有人直接把收到的所有字节塞进解析器，结果某个数位错位导致后面所有数据全乱。正确的做法是：先找到帧头，确认数据长度符合预期，再校验CRC或累加和，校验通过才把数据拷贝到结构体里。另外，雷达模块上电后会有几秒初始化时间，最好在上电后丢弃前几个数据帧，或者等模块输出第一个有效帧后再开始解析。
4.3 数据展示与上报：OLED或用ESP8266上云
系统的显示端我用了一块0.96寸OLED屏，128x64分辨率，I2C接口，只需要SCL和SDA两根线接到STM32。界面很简单：第一行显示呼吸频率，第二行显示心率，第三行显示睡眠状态。刷新频率不用太高，每秒更新一次完全够用，因为呼吸和心率本身变化不快，刷新太频繁反而显得数字跳动吓人。
如果想把数据做成远程可查看的系统，建议加一块ESP8266模块，走WiFi上报。STM32通过UART把打包好的睡眠数据发送给ESP8266，ESP8266负责连接MQTT服务器或者HTTP接口。我在这个项目里是把STM32当成纯数据采集终端，联网协议栈全部放到ESP8266侧处理，开发起来非常省心。硬件上ESP8266也是一块非常成熟的WiFi模块，成本低、资料多，和STM32串口通信没有障碍。
上报数据的帧格式建议自己定义一个简单的协议，比如：
- 帧头：0xAA 0x55
- 数据长度：1字节
- 数据内容：呼吸率（1字节）、心率（1字节）、睡眠状态（1字节）、体动次数（1字节）
- 校验：累加和
这个格式在STM32端组包发送，上位机或手机端按同样格式解析，排障的时候用串口助手看报文即可的问题一目了然。
5. 调试实录：常见问题与排查速查表
5.1 串口明明有数据，但呼吸心率一直为零
这个问题看起来诡异，排查思路其实很固定。首先用上位机串口助手直接接雷达模块，查看原始数据帧中目标状态字段。如果目标状态一直是“无人”，说明雷达压根没有锁定人体。这时候优先检查安装角度：雷达波束是否正对床面，人体是否处于模块的检测距离范围内，有没有被金属遮挡。我用一个折叠手机支架把雷达模块斜对着床的方向，检测稳定性比平放提升了不止一个档次。
如果目标状态已经是“有人”，但呼吸心率为零，就要看模块的配置了。很多成品模块默认工作在低功耗模式，在这种模式下只输出目标距离，不会输出生命体征数据，需要发送配置命令开启呼吸心率检测功能。翻一下模块手册，找到开启生命体征检测的指令，在STM32启动后发送一次即可。我当时在这上面卡了大半天，后来看到手册里一行说明才明白过来。
如果用的是I/Q前端模块，没有任何串口数据，重点检查ADC采样到的信号幅度。用示波器看I和Q通道，正常情况应该能观察到微伏到毫伏级且带明显包络起伏的中频信号。如果幅度太小，考虑加一级放大电路，或者把模块移近人体。
5.2 呼吸频率波动大，心率数值乱跳
这类问题90%出在数据处理而不是硬件上。最常见的原因是FFT点数太少导致频率分辨率不够。我之前试过50Hz采样率配64点FFT，频率分辨率0.78Hz，想把呼吸和心跳分开根本不可能，两个频峰糊在一起。后来改成256点FFT，分辨率到0.2Hz，效果立竿见影。
第二个高发原因是忘记去直流和滤波。人体静态位置产生的直流偏置会占据FFT频谱第0个频点，同时由于频谱泄漏，低频大能量会对附近频点产生干扰。解决方法是先做滑动平均去直流，再进行带通滤波。
第三个原因是环境干扰。如果卧室里有风扇、空调或者空气净化器，它们产生的周期性气流也可能被雷达捕捉。我的做法是在算法里对目标回波幅度设置阈值，当幅度低于某个值时认为信号不可靠，直接丢弃这帧数据。你还可以根据实际环境调整雷达的检测距离门限，把检测范围压缩到床面附近，干扰会大幅减少。
5.3 程序跑飞或者进入HardFault的排查
跑飞几乎是MCU项目必踩的坑，我这个项目也不例外。典型表现是运行一段时间后OLED突然没反应，串口也不输出了。在Keil里连接调试器后，看到程序停在HardFault_Handler里。
有一个很实用的排查入口是查看SCB->CFSR寄存器。比如寄存器值为0x00008200时，表示的是总线错误（BFSR）区域触发了标志，这类错误通常是因为访问了非法地址，比如数组越界、指针未初始化、DMA缓冲区访问越界。解决办法是检查所有涉及数组下标的操作，尤其是串口接收缓冲区的大小和实际收到的数据长度是否匹配。如果雷达一帧数据有几十字节，但你定义的缓冲区只有16字节，DMA写穿缓冲区就会直接触发总线错误。
另一个常见死机原因是延时函数卡死。如果开了中断，又在高优先级的中断服务函数里调用阻塞式HAL_Delay，SysTick中断优先级比当前中断低的话，延时永远不会结束。解决方法是把SysTick中断优先级设为最低，或者在高优先级中断里改用非阻塞的延时计数方式。这些细节在简单Demo中看不出来，一旦资源紧张就疯狂暴露。
5.4 常见问题速查表
| 现象 | 可能原因 | 解决办法 |
|---|---|---|
| 雷达一直报“无人” | 安装角度不对/距离超范围/金属遮挡 | 调整安装角度，确保天线正对人体，检查天线净空 |
| 有人但呼吸心率为0 | 模块未开启生命体征检测模式 | 发送配置命令开启该功能 |
| 呼吸心率跳变严重 | FFT点数不足/未滤波/环境干扰 | 增加FFT点数，加带通滤波，增加幅度阈值 |
| OLED偶现乱码 | 电源纹波过大/I2C干扰 | 在OLED电源脚加100nF电容，缩短I2C走线 |
| 运行一段时间硬死机 | 数组越界/DMA缓冲区溢出/中断死锁 | 检查缓冲区长度、数组下标、SysTick优先级 |
| 上电后模块无数据 | 供电不足/模块初始化时间短 | 独立供电，复位后延时2秒以上 |
| 串口数据全是乱码 | 波特率不匹配 | 用示波器或逻辑分析仪抓实际波特率 |
5.5 一个关于资料查找的实在建议
这套系统做下来，一个很深的感受是：很多时候不是技术难，而是你拿不到模块的准确资料。雷达模块这种偏小众的器件，说明书经常写得含糊，协议文档还要找客服要。我的做法是拿到模块之后，先用逻辑分析仪抓一遍串口波形，确认实际波特率，再用串口助手看原始数据流，把所有可能的命令都试一遍，自己把协议逆向出来。这个过程虽然有点原始，但非常可靠——很多厂商文档和实际固件行为并不完全一致，实测数据才是最靠谱的依据。
6. 扩展方向：让系统从“能跑”到“好用”
6.1 多传感器融合：雷达加环境传感器
睡眠质量不只看呼吸心率，房间的温度、湿度甚至噪音都会影响判断的准确性。我后来在这个项目上做了一个小改动，加了一颗DHT20温湿度传感器，通过I2C接入STM32。将温湿度数据和雷达数据一起打包上报到上位机后，能很清楚地看到“温度偏高时心率整体上升”这种规律。这样的多传感器融合才是完整的产品级体验，睡眠监测不能只关注人本身，环境上下文同样重要。
6.2 数据上云与远程查看
给系统加一个ESP8266模块，接上家里的WiFi，睡眠数据就能通过MQTT上传到服务器，手机端做一个简单的界面就能看到昨晚的深睡比例、夜间心率变化曲线。这个功能对于家里有老人的场景特别实用，子女可以远程查看父母夜间的生命体征趋势。技术上，把ESP8266的AT固件和MQTT库用起来，两天就能打通。
6.3 算法层面的进阶空间
如果想让项目技术上有更多亮点，可以做两个方向的升级：一是引入微动能量分析，通过体动次数和翻身频率进一步判断睡眠质量；二是尝试在STM32上跑轻量级的呼吸暂停检测算法，检测呼吸波形的周期性中断。后者需要更精细的调制解调处理，算力需求更高，建议把主控升级到带DSP指令的M4内核，例如STM32F401系列，整个代码框架基本可以复用。
最后说个个人体会。做这类感知项目，最花时间的不是硬件接线，也不是写业务逻辑，而是调阈值。每个房间、每张床、每个人，信号基线都会有细微差异，把参数写死进代码永远不够。我踩过几次坑之后，把灵敏度、检测距离、状态切换时间全部改成了可配置项，通过串口下发参数就能现场调节，整个系统才算真正稳定下来。这个经验对任何传感器项目都适用：宁可前期多写几个可调参数，也好过后期为每个使用场景单独改代码重新烧录。
