把STM32和R60ABD1毫米波雷达凑到一起做非接触式睡眠监护系统是我最近大半年做得最值的一个嵌入式项目。起因是家里老人不肯戴手环睡觉说戴着硌手、怕辐射半夜翻身还会把表带压松我一开始也试过压电薄膜、麦克风拾音这些土办法要么睡着睡着就移位要么被呼噜声干扰得没法看。后来换成60GHz毫米波雷达人往床上一躺不接触皮肤也能拿到呼吸频率和心率再用STM32做解析、判断、记录和报警整套东西才真正像一个能长期跑的监护系统。这篇分享不打算写成一个“照着接几根线就能跑”的教程合集而是把从硬件选型、串口协议、睡眠状态机到调试踩坑的整个链路讲清楚。手里已经有R60ABD1、准备做毕业设计或者床头监护产品的同学可以参考第一次用毫米波雷达做生命体征项目的工程师也能从中找到几条能直接落地的经验。1. 为什么我坚持用“雷达STM32”而不是可穿戴设备1.1 睡眠监护最麻烦的不是测不准而是“不肯戴”睡眠监护这个需求听起来不复杂做起来全是细节。市面上常见的方案是手环、智能手表、体动带、心电贴但它们有一个共同的硬伤必须贴在身上。老人睡觉普遍浅手腕上多一个东西很容易醒皮肤敏感的人贴心电电极片两三天就会发红体动带勒在胸口翻身多几次就跑到肚子上去了。你花大价钱买的设备最后往往因为“佩戴体验差”被扔在床头柜里吃灰。所以“非接触”不是炫技是这类产品能不能真正落地的前提。人只要躺在床上不碰皮肤、不用穿脱监护才能变成一件“无感”的事情。这也是我选毫米波雷达而不是摄像头的原因雷达不采集图像隐私压力很小而且黑暗环境完全不影响它工作夜里关灯照样能拿到呼吸和心率数据。1.2 R60ABD1到底帮你做了哪些事R60ABD1是60GHz频段的毫米波雷达模组核心价值在于它内部已经把多普勒信号和目标识别算法处理完了对外直接通过UART输出检测结果。我做STM32固件的时候不需要自己去写FFT、CFAR这类雷达信号处理算法只需要解析协议帧然后做业务逻辑。从实际代码里能看到的数据大致包括这几类目标状态无目标/有人活动/静止有人、呼吸频率、心率、呼吸置信度、心率置信度、目标距离、运动干扰标志。有些固件版本还支持跌倒检测、存在感应、微动感应做睡眠监护优先选带呼吸心率输出的固件。理解这一点很重要它决定了整个项目的工作量边界。STM32端的核心任务不是“从零计算生命体征”而是把模组输出的原始帧变成稳定、可信、能报警的监护数据。1.3 主控为什么选STM32稳定和可控高于一切有人问过我直接用ESP32接雷达不是更方便吗还能直接联网。但从做产品原型和长期运行的角度看STM32有几个明显优势一是串口解析的实时性和确定性更好不用跟WiFi协议栈抢CPU二是运行稳定不开RTOS也能用裸机状态机把整机逻辑跑得很干净三是外设资源丰富UART、I2C、SPI、DMA、IWDG这些做监护系统足够用芯片成本还低。如果你只是想快速验证雷达效果用USB转TTL接电脑上位机看数据是没问题的。但要做成一个放在床头的独立设备还是得靠单片机。STM32在这里的角色是“数据管家”接住雷达吐出来的原始数据过滤噪声判断睡眠状态驱动显示和报警再把需要留存的数据写入存储或者上报。2. 硬件搭建器件选型、供电、接线与安装位置2.1 整套系统的物料清单先列一份我实际用到的物料照着配基本能跑器件型号/规格作用主控板STM32F103C8T6最小系统板数据解析、状态判断、外设控制毫米波雷达R60ABD160GHzUART TTL输出非接触检测呼吸、心率、目标状态显示0.96寸OLEDSSD1306I2C接口实时显示心率、呼吸、状态报警有源蜂鸣器模块低电平触发心率/呼吸异常、离床报警存储Micro SD卡模块 FatFS睡眠数据落盘记录通信ESP-01S / ESP8266可选数据上报到局域网或云端电源5V/2A USB适配器或锂电池升降压板整机供电我建议先不着急接SD卡和WiFi第一版跑通串口和OLED就够了。多加一个外设调试时就要多排查一个变量。2.2 电平匹配和供电细节R60ABD1的供电电压以模组手册为准我手上这块是5V供电电流大概几十毫安用STM32板载的5V引脚供电没有问题。但要特别注意雷达的UART TX/RX电平如果模组接口是3.3V TTL可以直接连STM32的串口如果手册写的是5V TTL串口线上必须加电阻分压或者用电平转换模块不能直接把5V信号怼进STM32的IO口。供电纹波是这类雷达最容易踩的坑。呼吸和心率本质上是提取胸腔微动的信息电源上的毛刺很容易被当成有效信号。我的做法是雷达供电脚旁边并联一个100nF陶瓷电容和一个10uF电解电容雷达和蜂鸣器不要共用同一路LDO蜂鸣器动作瞬间的电流跌落真的会让心率数值抖一下。接线顺序也有讲究先把雷达GND和STM32的GND连好再插TX/RX避免带电插拔损坏IO口。2.3 UART接线与模块安装位置硬件连接就四根线雷达VCC接5VGND接GND雷达TX接STM32的PA10USART1_RX雷达RX接PA9USART1_TX。如果你的系统只是单向读数据雷达RX可以不接但我建议还是接上因为后面调灵敏度、距离门这些参数多半要靠UART下发命令。安装位置比接线更影响数据质量。雷达应该放在床头方向天线面朝向人的胸口不要放在枕头正下方也不要藏在金属外壳后面。我实测下来雷达到胸口的距离在40到70厘米范围内数据最稳定太近反而容易触发运动干扰标志太远信噪比急剧下降。用金属支架固定时尤其要注意金属件要离天线窗口远一点否则反射会干扰算法。3. STM32端工程配置与毫米波雷达数据解析3.1 开发环境里最容易被新手卡住的两个点工程搭建本身不复杂但新手第一次用Keil MDK搭STM32工程时最常见的两个卡点一是打开工程发现器件列表里没有STM32这是因为没装芯片包需要先在Keil官网下载STM32F1xx_DFP并在Pack Installer里安装二是ST-LINK下载时报“No ST-LINK detected”多数是驱动没装好或者ST-Link固件太旧用STM32 ST-LINK Utility连一下并升级固件就好了。如果用的是标准库而不是HAL库还要注意Keil版本和工程模板的匹配避免出现“Keil5中没有STM32库”这种尴尬。我建议新项目直接用STM32CubeMX生成HAL库工程外设配置图形化后续切换芯片也方便。这篇里的代码基于HAL库和Keil MDK5芯片选STM32F103C8T6。3.2 CubeMX中的串口和DMA配置雷达数据是持续不断的串口流如果每次都用阻塞接收主循环会被拖死。我第一版就是直接在while循环里HAL_UART_Receive结果雷达一到数据OLED刷新就明显卡顿后来改成DMA加IDLE中断才解决。CubeMX里需要做三件事USART1选择Asynchronous模式波特率1152008位数据位1位停止位无校验。在DMA Settings里添加USART1_RX方向Peripheral to MemoryMode为Circular。开启USART1全局中断。生成的HAL代码会自动做好DMA和中断的关联然后在main函数里启动接收uint8_t uart_rx_buf[128]; HAL_UARTEx_ReceiveToIdle_DMA(huart1, uart_rx_buf, sizeof(uart_rx_buf));当串口线上出现一段空闲时间HAL会认为一帧数据接收完成并触发RxEventCallback。不过DMA环形缓冲存在跨边界问题新手在这里很容易绕晕。我的建议是第一版先用单字节中断接收把每个字节喂给状态机逻辑最清晰等协议跑通了、系统稳定了再回头优化成DMA。115200波特率下单字节中断对STM32F103来说CPU占用完全能接受。3.3 用状态机解析协议帧毫米波雷达协议帧通常包含帧头、长度、正文、校验几部分。不同固件版本的R60ABD1帧格式可能有差异下面以我调过的一段协议为例帧头是04 02 04 00第5、6字节是正文长度正文后面跟一个累加和校验字节。解析方式用状态机最稳妥typedef enum { ST_WAIT_HEAD0, ST_WAIT_HEAD1, ST_WAIT_HEAD2, ST_WAIT_HEAD3, ST_WAIT_LEN_H, ST_WAIT_LEN_L, ST_WAIT_BODY, ST_WAIT_CRC } radar_state_t; static radar_state_t radar_state ST_WAIT_HEAD0; static uint8_t frame_buf[64]; static uint16_t frame_pos 0; static uint16_t body_len 0; void radar_byte_handler(uint8_t byte) { switch (radar_state) { case ST_WAIT_HEAD0: if (byte 0x04) { frame_buf[0] 0x04; frame_pos 1; radar_state ST_WAIT_HEAD1; } break; case ST_WAIT_HEAD1: if (byte 0x02) { frame_buf[1] 0x02; frame_pos 2; radar_state ST_WAIT_HEAD2; } else radar_state ST_WAIT_HEAD0; break; case ST_WAIT_HEAD2: if (byte 0x04) { frame_buf[2] 0x04; frame_pos 3; radar_state ST_WAIT_HEAD3; } else radar_state ST_WAIT_HEAD0; break; case ST_WAIT_HEAD3: if (byte 0x00) { frame_buf[3] 0x00; frame_pos 4; radar_state ST_WAIT_LEN_H; } else radar_state ST_WAIT_HEAD0; break; case ST_WAIT_LEN_H: body_len (uint16_t)(byte 8); frame_buf[frame_pos] byte; radar_state ST_WAIT_LEN_L; break; case ST_WAIT_LEN_L: body_len | byte; frame_buf[frame_pos] byte; if (body_len 32) { radar_state ST_WAIT_HEAD0; } else radar_state ST_WAIT_BODY; break; case ST_WAIT_BODY: frame_buf[frame_pos] byte; if (frame_pos 6 body_len) radar_state ST_WAIT_CRC; break; case ST_WAIT_CRC: { uint8_t sum 0; for (uint16_t i 0; i frame_pos; i) sum frame_buf[i]; if (sum byte) { radar_frame_parse(frame_buf, frame_pos); } radar_state ST_WAIT_HEAD0; } break; } }每次串口收到一个字节就调用一次radar_byte_handler。如果后续遇到一帧里包含多个子帧或者帧头存在伪匹配状态机会自动回退到ST_WAIT_HEAD0重新找帧头不需要手动清理缓冲这也是状态机比直接memcpy解析更稳的原因。3.4 帧内字段的含义与数据质量正文解析完成之后一般会得到这样一个结构体typedef struct { uint8_t target_state; // 0无目标 1有人活动 2静止有人 3睡眠 uint8_t resp_rate; // 呼吸频率单位0.1次/分 uint8_t heart_rate; // 心率单位0.1次/分 uint8_t resp_conf; // 呼吸置信度 0-100 uint8_t heart_conf; // 心率置信度 0-100 uint16_t distance_cm; // 目标距离 uint8_t interfere_flag; // 运动干扰/遮挡标志 } radar_frame_t;用户看到的是“心率68、呼吸16”但我在代码里更关心置信度和干扰标志。置信度代表算法对这个测量值的把握程度不是简单的好或者坏。我设的经验值是呼吸置信度低于50或者心率置信度低于40时这一帧的生命体征数据就不应该立即更新到显示上而是保持上一次有效值同时把“信号弱”的状态通过OLED提示出来。这样能避免半夜翻身时显示一个吓人的假数值。关于表补实际项目中有人还会在帧里加入体动事件、跌倒事件、活体探测结果等字段不同固件版本定义差异很大最可靠的手段还是用串口助手抓帧、对着官方协议文档逐字节核对。上面这段框架适用于大多数补充帧。4. 睡眠状态判断、滤波和报警从“有数据”到“有用”4.1 状态机定义无目标/有人活动/睡眠静置拿到雷达数据之后最忌讳的是直接拿心率值做一堆“if判断”就完事。睡眠监护的核心不是单点数值而是状态迁移人有没有在床上是清醒还是入睡是不是长时间离床了。我根据目标状态和连续帧统计设计了一个三级状态机当前状态进入条件切换结果无目标雷达连续30秒检测不到目标保持无目标不产生任何报警有人活动检测到目标运动干扰标志频繁置位认为人在床上但未入睡睡眠静置目标状态为静止且生命体征持续120秒稳定进入睡眠开始记录数据代码核心是这样一段逻辑按1秒一帧的接收周期来算static uint8_t system_state DEV_STATE_NONE; static uint16_t still_tick 0; static uint16_t absent_tick 0; void sleep_state_update(radar_frame_t *frame) { if (frame-target_state 0) { absent_tick; if (absent_tick 30) { set_system_state(DEV_STATE_NONE); } return; } absent_tick 0; if (frame-target_state 2) { still_tick; if (still_tick 120 system_state ! DEV_STATE_ASLEEP) { set_system_state(DEV_STATE_ASLEEP); } } else { still_tick 0; if (system_state DEV_STATE_ASLEEP) { set_system_state(DEV_STATE_AWAKE); } } }这套状态机的关键是“连续计数”。单帧显示有人或者无人都不足以作为报警依据只有连续一段时间出现某个特征才认为状态真的变了。这能过滤掉翻身、坐起来喝水、下床上厕所这类短暂事件。4.2 中值滤波与变化率限制R60ABD1输出的生命体征值在安静状态下是稳定的但偶尔也会出现毛刺尤其在翻身、揉眼睛这类小动作发生的瞬间。直接显示这个毛刺用户半夜瞄一眼屏幕会被吓一跳。我用两级处理中值滤波加变化率限制。中值滤波就是取最近5帧呼吸/心率的中位数作为显示值。相比平均值中值滤波对单个异常点的抑制效果更好而且不会把瞬时真实值拉偏。代码很简单#define VITALS_WIN 5 static uint8_t hr_buf[VITALS_WIN]; static uint8_t hr_idx 0; static uint8_t hr_cnt 0; uint8_t median_u8(uint8_t *buf, uint8_t n) { uint8_t tmp[VITALS_WIN]; for (uint8_t i 0; i n; i) tmp[i] buf[i]; for (uint8_t i 0; i n - 1; i) { for (uint8_t j 0; j n - 1 - i; j) { if (tmp[j] tmp[j 1]) { uint8_t t tmp[j]; tmp[j] tmp[j 1]; tmp[j 1] t; } } } return tmp[n / 2]; } void update_heart_rate(uint8_t raw, uint8_t conf) { static uint8_t last_valid 0; if (conf 40) return; if (last_valid (raw last_valid 50 || raw last_valid - 50)) { // raw单位是0.1bpm50代表5次/分超过这个范围认为是运动伪峰 return; } hr_buf[hr_idx] raw; hr_idx % VITALS_WIN; if (hr_cnt VITALS_WIN) hr_cnt; last_valid median_u8(hr_buf, hr_cnt); heart_rate_display last_valid; }变化率限制的原理是正常成年人的心率不会在1秒内突变超过5到8次/分呼吸频率更慢。如果一帧的raw值和上一帧有效值差距太大基本可以判断是动作干扰导致算法锁错了信号峰。这里直接把这一帧丢弃而不是硬把窗口里的数据抬上去能保持曲线平稳。4.3 防误报的报警策略报警是睡眠监护系统最敏感的部分。心率低于40、呼吸低于6或者睡觉中途连续长时间离床都应该提醒家人。但报警逻辑如果写得过于“聪明”反而容易造成半夜误报折腾老人也折腾自己。我的做法是报警条件连续满足一定次数才触发比如呼吸频率低于6次/分并且持续20秒才开始驱动蜂鸣器。报警触发后如果条件恢复必须延迟一段时间才能再次报警避免数值在阈值边缘抖动时蜂鸣器反复响。离床报警只在“已进入睡眠状态”之后才启用。如果老人的手环显示他本来就没睡着离床去上个厕所不算异常。从工程角度说报警逻辑要尽量参数化。比如阈值、持续时间、蜂鸣器鸣响时长都定义成宏或者配置结构体方便不同老人、不同季节单独调整。5. 显示、记录和上报的可选扩展5.1 本地OLED显示OLED用来显示实时心率、呼吸频率和当前睡眠状态。我的刷新策略是1秒刷新一次在main函数主循环里做不用Delay阻塞char line[16]; snprintf(line, sizeof(line), HR:%03d RR:%03d, heart_rate_display, resp_rate_display); OLED_ShowString(0, 0, line); snprintf(line, sizeof(line), ST:%s, state_str[system_state]); OLED_ShowString(0, 2, line);OLED刷新本身是个低速操作如果每次都在中断里调用会影响串口接收。保持“数据进中断显示在主循环”这个原则整个系统才不会出现画面卡顿或者丢帧。5.2 SD卡CSV记录睡眠数据落盘是很有价值的功能。之前我用过串口发到上位机但电脑一关数据就没了后来加了SD卡模块配合FatFS。记录格式建议做成CSV一行一条记录FIL log_file; f_open(log_file, 0:/SLEEP_LOG.CSV, FA_OPEN_ALWAYS | FA_WRITE); f_lseek(log_file, f_size(log_file)); f_printf(log_file, 2025-01-15 23:00:03,2,68,16,85,90\r\n); f_close(log_file);写入频率不要太高一分钟写一条就够了。SD卡频繁写入不仅磨损卡还会拖慢主循环。如果要做跨天记录文件名用日期动态生成比如LOG_20250115.CSV第二天自动新建文件省得后期整理数据时一个文件几十兆。5.3 通过ESP8266/ESP32上云上云的最大意义是让不在身边的子女能看到老人的睡眠趋势。我最初用ESP-01S模块通过AT指令连接WiFiSTM32定时通过串口发一份JSON给它。下面是一个典型的上报报文{dev:bed1,state:2,hr:68,rr:16,conf_hr:85,conf_rr:90,ts:1712345678}如果只是局域网内调试最省事的是用UDP往PC上位机丢数据不需要做TCP握手和重传如果要做远程访问就搞一个MQTT BrokerSTM32端把数据发布到一个主题里。我的经验是第一版先用串口打印数据确认解析稳定后再接ESP8266否则WiFi模块的各种失联问题会让你分不清是雷达数据的问题还是网络的问题。6. 调试实录我踩过的坑和排查链路6.1 雷达明明对着床却一直报无人这是我遇到的第一个大坑。装好之后发现人在床上躺了五分钟OLED上目标状态还是“无目标”。排查链路如下第一步把原始帧通过串口打印到上位机确认雷达到底有没有输出目标状态。第二步发现有人走动时目标状态能变成“有人活动”但躺下后反而变回无目标。第三步观察安装角度发现雷达波束主要照到的是床头和枕头区域胸口反而在波束边缘。第四步调整模块角度让天线面正对胸口并把距离从90厘米挪到60厘米左右问题解决。如果你手里的固件支持距离门设置一定要把检测范围限制在床铺附近比如0.5到3米。不然窗外来往的人、走廊里的目标都可能被雷达当成检测对象干扰睡眠判断。6.2 串口乱码和丢帧的完整排查R60ABD1的串口输出如果出现乱码排除顺序一般是波特率不对、接线接反、没有共地、电平不匹配、线材干扰。我一度以为是模块坏了换了一个还是一样最后发现是雷达的TX线从模块到STM32走了一段30厘米的杜邦线旁边就是蜂鸣器线一报警就丢帧。处理方法分几路信号线尽量缩短控制在10厘米以内雷达供电端加强滤波蜂鸣器这类感性负载用单独的电源轨如果还不行就在串口线上串联一个小电阻降低振铃。用逻辑分析仪对比模块TX引脚波形和STM32收到的数据很快就能定位问题是在物理层还是协议层。6.3 长时间运行后死机和数据卡死监护系统是要七天二十四小时跑的代码里任何一个隐患都会被时间放大。我调试时遇到过跑了两三天后雷达数据不再更新、OLED也不刷新的情况。原因有两个一是没有开看门狗主循环一旦被某个外设阻塞整个系统就瘫了二是DMA接收溢出后没有重新启动接收。解决方式分两步在CubeMX里使能IWDG喂狗操作放在主循环最后串口DMA接收回调里增加溢出标志判断一旦发生溢出就直接重新调用HAL_UARTEx_ReceiveToIdle_DMA。另外STM32F103没有硬件浮点单元我在生命体征处理里尽量避免float运算统一用整数和定点数主循环周期能稳定控制在几毫秒内。6.4 冬天厚被子的信号衰减问题60GHz毫米波对非金属遮挡仍然有衰减冬天盖厚被子时呼吸频率还可能出来心率会明显丢失。这不是模块坏了是信号穿不透棉被。我的处理思路是调整安装位置把雷达从床沿挡板改到床头支架缩短雷达和胸口之间的距离同时在代码里把“低置信度保持”做得更激进一点——连续几十帧低置信度就显示“信号弱充电/盖被过厚”而不是跳出一个明显偏低的心率值。实测下来薄被子和普通厚度棉被都能稳定检测厚羽绒被偶尔丢心率可以通过安装位置优化补偿一部分。把R60ABD1和STM32这套组合做完之后最大的感受是毫米波雷达把“非接触生命体征检测”这件事的门槛降到了单片机开发者能独立完成的水平难点反而变成了协议稳定性、数据质量控制和业务逻辑设计。调试时多打印原始帧、多用连续计数做状态判断、所有阈值尽量参数化这三个习惯能帮你省掉大量返工。如果后续想扩展可以在这个框架上增加体动记录、睡眠阶段粗略估计、多人检测等能力R60ABD1的接口基础已经搭好了剩下的就是产品层面的打磨。
