最近圈子里有个挺典型的联合项目：几家不同赛道的公司凑在一起，要做一款电池供电的低功耗IoT人体检测设备。项目标题是“Firms Team for Low Power IoT Person Detection”，听起来不算多复杂，但真正跑起来你会发现，这个题目几乎把嵌入式低功耗、传感器融合、边缘AI、无线传输这几块硬骨头全踩了一遍。这篇文章想把这类项目背后的核心矛盾、技术路线、协作方式和容易踩的坑拆开聊聊。
不管你是做硬件选型、嵌入式软件、算法移植，还是负责产品定义，只要接触过“电池供电 + 人体感知”这类需求，这篇文章应该能帮你少走不少弯路。我按自己的实际经验，把从原理到选型再到部署的完整链路梳理一遍。
1. 为什么“人体检测”在IoT里是个功耗难题
1.1 电池容量与寿命的算账逻辑
先算一笔很基础的账。一颗CR2032纽扣电池标称容量大概220mAh，如果系统平均电流做到50uA，理论寿命大概是220mAh / 0.05mA = 4400小时，约等于183天。但这是理想值，实际还要算上电池自放电、低温容量衰减、天线匹配损耗、偶尔的无线重传，真实可用时间经常打个六折甚至更低。所以“低功耗”三个字，本质上不是省一个元器件的电，而是把整机的平均电流压到几十微安以内。
这类项目里有一个经常被忽略的公式：锂电池或碱性电池的“脉冲放电能力”和“平均放电能力”是两回事。人体检测设备平时在睡觉，一旦检测到事件会瞬间拉高电流去跑雷达、启动无线，这个脉冲峰值可能冲到100mA以上。选电池的时候如果只看平均电流，现场就会出现“电量显示正常，但一触发就掉压重启”的诡异故障。这一点后面我还会专门展开。
1.2 传统RGB视觉方案为什么顶不住
很多人一听到“Person Detection”，第一反应就是上摄像头做视觉识别。确实，深度学习目标检测在安防摄像头里已经非常成熟，YOLO系列、SSD、MobileNet这些模型随便一个都能框出人形。但问题在于，一颗普通RGB摄像头加上ISP和NPU，功耗通常在几百毫瓦级别。哪怕用最新的低功耗视觉芯片，把分辨率降到QVGA、帧率压到1fps，整机功耗也很难低于30mW。
对比一下，一颗PIR传感器（被动红外）的功耗是微安级别，一颗毫米波雷达的功耗是几十毫瓦级别，两者相差2到3个数量级。对电池供电的IoT设备来说，这中间的差距就是“一年换一次电池”和“一个月换三次电池”的区别。不是说视觉方案不能做，而是它不应该作为“全天候持续工作”的传感器，更适合放在检测链路的最后一环，等前置传感器已经确认“大概率有人”之后再唤醒抓拍，这样才能把平均功耗压下来。
1.3 先分清“存在感知”和“人员检测”
这里要澄清一个概念。标题里的Person Detection，在很多低功耗IoT场景里并不是“识别出这个人是谁”，而是“判断这个区域有没有人”。有朋友会说“这不就是人体存在传感器吗？”对，但要区分两种能力：
- 运动检测：人只要动就能感知，PIR就能干，算力需求为零。
- 静态存在检测：人坐在椅子上不动，甚至睡着了，只有呼吸带来的微小起伏，依然要能判断“有人”。这就不是普通PIR能解决的，需要毫米波雷达或者高灵敏度视觉。
这两种需求对应完全不同的硬件架构。如果产品定义只要求“有人走过就上报”，一颗PIR加上一颗低功耗MCU就够了。如果要求“检测到人静坐超过10分钟”，那就必须有雷达介入。很多项目失败，就是产品经理和硬件工程师在这一点上没有对齐，做出来的设备要么功耗超标，要么需求满足不了。
2. 主流检测技术路线的横向对比：功耗、精度、成本三方博弈
2.1 PIR被动红外：uA级功耗但只能“看个大概”
PIR传感器（被动红外）靠检测人体发出的红外辐射变化来触发信号。它的好处是功耗极低、价格便宜、结构简单，一个传感器加一个菲涅尔透镜，整套物料成本能控制在几块钱以内。待机电流大概1-10uA，触发时也不过几十微安，几乎是所有低功耗检测设备的第一道闸门。
但PIR的短板也很明显：它对“静止的人”无效。原理决定了它感应的不是红外线本身，而是红外线的变化。人坐在工位上不动，PIR输出就是平的，没有任何中断，系统以为房间空了。我见过一个办公座位占用检测项目，客户反馈“我明明坐在座位上，系统却说没人”，排查了几天，最后发现是PIR的固有特性，不是产品坏了。
这个问题的工程解法有很多：一是把PIR当成唤醒源而不是最终判决，PIR触发后启动雷达确认；二是设计“遮挡检测”逻辑，当PIR输出长时间没有变化时，主动发一个低功耗雷达探测；三是用两组PIR配合光学透镜分区，增加触发覆盖面。但无论如何，PIR只能是整套方案的起点，不可能是终点。
2.2 毫米波雷达：最平衡的候选者，但门槛在算法
毫米波雷达是最近几年低功耗人体检测领域最热的方向，尤其是60GHz频段。它的核心原理是发射FMCW或FSK调制的毫米波信号，通过反射波的多普勒频移和距离门分析，判断目标是否存在、距离多少、微动特征如何。60GHz频段的波长大约5mm，足够检测到人体呼吸时胸廓几毫米的起伏。
功耗层面，一颗集成了雷达收发机的SoC，工作电流大约在30mA到100mA量级（视输出功率和采样率而定），相比视觉方案低了一个数量级，但比PIR高了两三个数量级。所以雷达不适合一直开着，正确用法是“按需唤醒”：PIR先检测到粗粒度事件，MCU再给雷达上电，雷达用几百毫秒到几秒时间做一次确认，然后立即断电。
算法门槛是雷达方案最大的坑。很多人以为买了一颗雷达模组，串口直接输出“有人/无人”，接上就能用。实际上一颗雷达模组的原始数据需要经过FFT、CFAR检测、聚类、跟踪、微动特征提取这一整套流程，才能输出稳定的存在判断。如果只用模组厂家提供的默认阈值，在现场十有八九会出现“空调一吹就误报”“隔着玻璃人走过去没反应”之类的问题。后面我会专门讲怎么调试这些参数。
2.3 视觉、ToF、超声波等补充路线
除了PIR和毫米波雷达，还有一些在特定场景下值得关注的技术路线：
- 视觉方案：适合需要“人员数量统计”“人脸识别”或“行为分析”的场景。功耗高、成本高，但信息量最大。低功耗IoT里通常作为末端确认手段，比如雷达确认有人后，摄像头抓拍一张图，通过低功耗AI芯片做一次人形分类，再决定要不要上报。
- ToF（飞行时间）：适合近距离检测，比如智能门锁的人体接近唤醒。ToF传感器的功耗在几十毫瓦量级，距离通常不超过5米，室外强光下性能会明显变差。
- 超声波：成本低、功耗低，但容易被窗帘、衣物等软质材料吸收，检测距离短，且多个设备之间有干扰风险。
- Wi-Fi/Sub-GHz信号感知：利用现有无线模块检测环境中人体移动造成的RSSI（信号强度）变化，功耗可以非常低，但精度和稳定性受环境影响大，更适合做“区域占用粗判”而不是“精确存在检测”。
2.4 一张表看懂各方案的综合素质
我做一个比较实用的对比表，方便大家在做方案选型时快速排除选项。
| 方案 | 典型待机功耗 | 静态人体检测 | 误报率 | 物料成本（参考） | 算法复杂度 | 适用场景 |
|---|---|---|---|---|---|---|
| PIR + 菲涅尔透镜 | 1-10uA | 不支持 | 中高（热源/气流易触发） | 低（几元） | 极低 | 低成本人体运动感知、系统唤醒源 |
| 毫米波雷达（60GHz） | 30-100mA（工作态） | 支持（呼吸级微动） | 低（需调参） | 中高（数十到上百元） | 高 | 静态存在检测、房间占用、老人看护 |
| 低功耗视觉（QVGA@1fps） | 30-300mW | 支持 | 低（模型决定） | 中高 | 高 | 人员计数、身份识别、行为分析 |
| ToF | 十几到几十mW | 支持 | 中（强光/远距失效） | 中 | 中 | 近距离唤醒、手势识别 |
| 超声波 | 数十mW | 支持（近距离） | 中 | 低 | 低 | 短距离防遮挡检测 |
这里有一个特别重要的提醒：单独看任何一个方案都是不全面，实际产品几乎都是两种或三种方案叠加使用。最典型的架构是“PIR粗检 + 雷达确认”，既控制了平均功耗，又补上了静态检测能力。后面我展开讲这套配合逻辑。
3. 联合项目的协作架构：传感器、芯片与算法的分工
3.1 为什么“单打独斗”做不好这类产品
标题里“Firms Team”这个词很关键。一个完整的低功耗人体检测设备，需要传感器技术、低功耗芯片设计、边缘AI算法、无线通信、结构散热，甚至云平台接入。没有任何一家公司能在这所有环节都是专家，成熟的产品通常是多家企业分工协作：
- 传感器芯片原厂：负责把雷达前端或PIR传感器的功耗做低、封装做小，提供参考驱动。
- MCU/SoC厂商：提供低功耗处理器、睡眠唤醒机制、安全启动和FOTA能力，通常也给定点运算库。
- 算法团队：负责把person detection模型裁剪、量化、部署到MCU或轻量级NPU上，解决模型精度和存储空间的矛盾。
- 模组厂：把传感器、MCU、天线、电源管理集成到一块小板上，做一致性校准，输出标准化接口。
- 云平台：负责设备接入、数据下发、告警推送，让终端用户可以远程管理。
- 整机品牌：定义产品需求、做系统级集成测试、过认证、量产管控。
这种协作模式最考验的是“接口定义”。我在实际项目里遇到最多的冲突，是算法团队说“我要每帧原始雷达数据”，而硬件团队说“MCU的RAM只能装两帧”，两边没对齐就导致后期推倒重来。避免这个问题的办法，是在项目启动时就把数据流画清楚：传感器输出什么格式、算法在哪个阶段跑、需要多少内存、每阶段允许多少延迟，这些都要以书面协议定下来。
3.2 事件驱动三阶段流水线：PIR唤醒、雷达确认、无线发送
低功耗人体检测设备的核心设计思路，是把“检测”这个动作拆成多级流水线，每一级都比上一级更精确但更耗电。最实用的是三阶段模型：
- 深度睡眠阶段：MCU处于STOP或Standby模式，只留外部中断引脚监听PIR，整机电流控制在5-20uA。PIR一旦检测到红外变化，立刻通过GPIO中断唤醒MCU。
- 雷达确认阶段：MCU给雷达模组上电，加载配置，跑一次或多次检测，连续几帧输出“有人”才判定为有效事件。这个阶段根据算法复杂度需要0.5秒到2秒。判定完成后立即把雷达断电。
- 无线发送阶段：MCU把事件结果打包，通过BLE、LoRa、Wi-Fi或NB-IoT发送到网关或云端，然后再次进入深度睡眠。
这套流水线最关键的地方是“每一阶段都能独立失败并回退”。比如雷达确认发现是误报，就不需要启动无线，电流直接降回睡眠态。又比如无线发送失败，需要按退避算法重发，但重发次数要有限制，避免在信号差的时候把电池耗尽。
一个实际功耗估算的示例：假设待机电流10uA，每天有效触发30次，每次雷达工作2秒、工作电流50mA，那么雷达带来的日均消耗约为30×2×50mAs = 3000mAs = 0.83mAh，折算成平均电流约34.7uA。整机平均电流大约45uA。如果用两节AA碱性电池（2Ah，按70%可用容量算），理论寿命约为1400mAh / 0.045mA ≈ 31111小时，超过3.5年。这个账能让产品经理和客户都满意。
3.3 MCU侧的低功耗设计要点
在MCU选型和软件设计上，有几点经验值得专门提一下：
- 深度睡眠不等于一切：很多人觉得进入睡眠模式就万事大吉，实际上漏电流、外部上拉电阻、LDO的静态功耗、串口转接芯片的待机功耗，每一项都可能比MCU本身的sleep current还高。画原理图时就要排查每颗芯片的工作/关断状态。
- 时钟选择：低功耗设备建议外部接一颗32.768kHz的低速晶振，用于RTC和协议栈低频时钟。低频时钟功耗低，而且能让BLE等协议栈在sleep时保持时间基准。
- 任务调度要“集中处理”：不要在中断里做耗时的运算，中断里只置标志位，主循环在检测到标志后集中处理一次。否则MCU会因为频繁中断退出睡眠再进入睡眠，反而增加平均功耗。
- 协议栈也要省电：BLE广播间隔、连接事件间隔拉长，LoRa的发送功率和扩频因子调到能满足通信的最低档位，这些软件参数对功耗的影响往往比硬件选型还大。
4. 实测与踩坑：从原型到量产容易忽略的细节
4.1 实测功耗数据的典型套路
很多开发者在实验室里测功耗，习惯用万用表串联测平均电流，这样测出来的数据在“稳态”下还行，但无法反映设备真实工作的脉冲特征。推荐用电子负载或高精度电流探头的示波器，抓一条从深度睡眠到触发唤醒再到无线发送的完整电流波形，观察峰值电流、脉冲宽度和恢复时间。
我见过一个让人印象深刻的例子：某款设备明明标称待机电流8uA，实测平均电流却高达200uA。用示波器抓波形才发现，MCU每隔几百毫秒就会醒来一次，一次醒几十毫秒跑一段协议栈任务，然后再次睡去。虽然每次工作时间短，但次数太频繁，平均功耗被推高了几十倍。这种“频繁浅睡”的问题比“持续工作”更有迷惑性，因为它不会让温度明显升高，却悄无声息地吃电。
4.2 误报与漏检的工程权衡：调参就是一场心理战
毫米波雷达的“灵敏度”是一个让所有开发团队头疼的参数。阈值设得太低，空调出风、窗帘飘动、甚至电磁干扰都能触发误报；阈值设得太高，人坐在沙发上不动就漏报。
我在一个老人看护项目里踩过很深的坑。客户要求“老人跌倒了要报警”，但跌倒检测的触发逻辑不能只看雷达一帧数据，否则老人弯个腰捡东西就会被误报为跌倒。最终的做法是雷达输出多帧连续数据，算法综合“距离变化率、持续时间、姿态角变化”三个维度来打分，连续3帧得分超过阈值才触发报警。误报率从之前的每天十几次降到每周不到一次。
这里有一个普适经验：任何检测电路都不要用“单次触发”就下结论，至少要连续两个独立样本确认，且两个样本之间要有时间间隔。PIR也是这个道理，很多误报来自上电瞬间或者温度骤变，加一个“200ms稳定窗口”就能过滤掉大部分。
4.3 环境、结构与电池的隐性坑
原型机在研发台上一切正常，一到客户现场就各种灵异事件，多半是下面这几个环节出了问题：
- PIR透镜和外壳的距离：如果菲涅尔透镜贴外壳太近，外壳吸收日晒升温后辐射热量给传感器，会造成“晚上没人却不断误报”的闹鬼现象。设计方案时要在透镜和外壳之间留足空气隔热层。
- 雷达天线的净空区：毫米波雷达对天线前方的金属物体极度敏感。如果结构设计里雷达上方有金属支撑柱或者螺丝，波束会被扭曲，出现检测盲区。调试阶段最好对每一台样机做一次“多角度走动测试”，不要只看正前方效果。
- 电池低温特性：锂亚电池能量密度高，但脉冲放电能力差，低温下甚至无法支撑雷达启动时的瞬态电流。如果产品要出口到寒冷地区，建议在电池选型阶段直接把“低温脉冲电流”列进硬性指标。
- FOTA升级的功耗陷阱：无线固件升级需要在短时间内连续接收数据，平均功耗会是平时的几十倍。如果设备是几个月才换一次电池的场景，要设计“升级行为提示”甚至“升级时外接电源”的逻辑。
5. 我的选型建议与一次类似项目的复盘
5.1 如果现在让我从头做一个低功耗人体检测项目，我会怎么选
假设需求是“电池供电、能检测静态人体存在、事件上报到云端，要求在室内等效距离5米内可靠工作”，我的优先级排序是：
- 传感器方案：PIR + 60GHz毫米波雷达的组合，PIR负责唤醒，雷达负责确认。理由很简单，这是当前功耗和检测能力平衡最好的方案。如果预算紧张且需求只要求运动检测，可以砍掉雷达，纯PIR方案加一颗低功耗MCU搞定。
- MCU选型：优先考虑集成低功耗射频的SoC，比如nRF52系列、STM32U5系列、Silicon Labs的EFR32系列。理由是把无线通信和主控集成到一颗芯片上，省去外部射频匹配的功耗损耗。RAM和Flash要留足，因为雷达算法可能要跑FFT和浮点运算（如果MCU不带硬件浮点，算法团队会用定点化方案，两者对算力的要求差异很大）。
- 算法部署形式：优先用传感器原厂提供的“开箱即用”模组，哪怕贵一点，也要先把数据链路跑通。等整机逻辑稳定了，再考虑把算法往前移，甚至移到SoC内部做融合。不要一上来就追求深度学习模型，低功耗场景下多数“检测”问题用传统雷达信号处理就能解决，深度模型是最后一步锦上添花的工具。
5.2 一张可以抄作业的设计检查清单
每次做这类产品，我都会在评审会上留一页检查清单，包括但不限于：
- 平均电流是否按真实场景算过？有没有把无线重传、雷达确认、FOTA都算进去？
- 睡眠模式下每一颗芯片的漏电流是否逐个确认过？有没有不需要供电的外设还挂着LDO？
- 雷达天线区域有没有金属结构遮挡？结构图纸上是否画了净空区？
- PIR透镜和外壳之间是否留有隔热距离？菲涅尔透镜的安装方向是否按传感器厂家的推荐来了？
- 算法在MCU上的内存峰值是否算过？有没有给系统任务留出至少20%的余量？
- 无线发送失败后的重试策略是什么？能不能保证在极端信号环境下不会“忙到没时间睡觉”？
- 产品在低温环境下的启动电流是否验证过？电池型号的脉冲放电能力满足瞬态需求吗？
- 量产一致性怎么做？每台设备的雷达天线参数是否有出厂校准环节？
说实话，这几个问题里只要有一个没答上来，产品到了现场大概率会出事。技术方案能做到90分，剩下10分全靠这些“不起眼的检查项”兜底。
5.3 一点项目复盘
我参与过的一个项目，最初硬件团队为了赶进度，用了供应商提供的默认雷达配置，没有针对现场环境重新调参。结果在客户办公室测试时，中央空调一启动就疯狂报警，上线当天就被客户投诉。后来我们花了两周时间，把雷达的检测阈值、CFAR参考窗口、时间积累帧数全部重新标定，并在设备端加入“PIR先唤醒、雷达再确认”的联动逻辑，误报率才降到可接受范围。这个教训让我彻底明白，低功耗人体检测产品的技术难点根本不在于传感器灵敏度，而在于“误报与漏报的平衡”和“功耗与功能的平衡”，这两对矛盾从产品定义阶段就要想清楚。
如果以后再开类似的坑，我一定会把第一阶段的预算花在“带着雷达模组到真实场景里连续跑一周”上，而不是花在办公室里的Demo演示上。真实环境的数据，用它来训练阈值和模型参数，比任何实验室仿真都有价值。
