1. 为什么叫PLFM_RADAR：一个靠反射波感知环境的电子平台
PLFM_RADAR这名字乍一看有点唬人，拆开就清楚了——PLFM是Platform（平台）的缩写，RADAR就是雷达。合在一起，它不是我某篇论文的代号，也不是某个商业产品的型号，而是我自己折腾了大半年的一套多功能雷达感知验证平台。说白了，就是让一块普通的嵌入式开发板学会“用无线电波看世界”：前方有没有人、物体在不在动、距离大概多远、运动速度是多少。这套平台的核心价值在于，它用的不是摄像头，而是毫米波/微波反射信号，因此不受光照影响，能在黑夜、烟雾、灰尘环境下稳定工作。
可能有人会问，现在摄像头方案这么成熟，为什么还要自己做一套雷达平台？答案很简单：摄像头能看到的，雷达未必需要；雷达能看到的，摄像头经常看不见。比如在粉尘弥漫的车间里统计设备振动频率，在淋浴间检测老人跌倒，或者给机器人做避障——这类场景里光学传感器会严重退化，而雷达依然稳定输出。PLFM_RADAR就是为了解决这类“光学方案不够用”的问题而搭起来的。
这篇文章适合几类人看：一是想入门雷达信号处理但不知道从哪下手的嵌入式开发者，二是做物联网感知项目、正纠结“该用摄像头还是雷达”的产品工程师，三是对射频硬件感兴趣、想动手焊一块雷达评估板的学生或爱好者。我会把从硬件选型到算法落地的完整链路都讲明白，包括那些文档里不会写的坑。
整套系统的工作逻辑可以用一句话概括：发射电磁波，接收目标的反射回波，通过比对发射和接收信号之间的频率差、时间差、相位差，反推出目标的距离、速度和方位。下文所有内容都围绕这条链路展开。
2. 系统总体架构：从射频前端到数据处理的一整条链路
2.1 硬件平台的选型逻辑：为什么用24GHz频段
PLFM_RADAR的硬件核心是一块24GHz的雷达收发前端。选这个频段不是随手定的，主要基于三方面的考虑。
第一是频段合法性和天线尺寸的平衡。24GHz属于ISM（工业、科学和医疗）频段，在很多国家和地区允许低功率设备免执照运行，这在产品化阶段非常重要——不会有频谱监管上的麻烦。而天线尺寸和波长成正比，24GHz的波长约12.5mm，PCB贴片天线的面积可以做得非常小，巴掌大的板子上就能集成收发天线阵列，这对便携验证平台来说是巨大优势。
第二是探测精度的现实需求。雷达的测距分辨率和带宽直接相关，24GHz频段比较容易做到几百MHz甚至GHz级的调制带宽。按公式ΔR = c / (2B)计算，如果调频带宽做到500MHz，理论上距离分辨率能到0.3米；如果把带宽拉到1.5GHz，分辨率可以到0.1米。这个精度虽然比不上激光雷达，但做人体存在检测、区域闯入报警、慢速目标跟踪已经完全够用。
第三是成本。24GHz的射频前端芯片（比如英飞凌的BGT24系列、意法半导体的STRADA系列）在汽车防撞雷达领域已经量产多年，单价和供货稳定度远优于60GHz甚至77GHz的芯片。对个人开发者来说，这个成本是能够接受的。
2.2 三大核心子系统的分工
PLFM_RADAR在物理上分为三个子系统，每个子系统解决一个独立问题。
射频前端子系统负责电磁波的发射和接收。它内部包含VCO（压控振荡器）、功分器、发射功率放大器、接收低噪声放大器和混频器。发射链路发射FMCW（调频连续波）信号，接收链路把目标反射回来的微弱回波和本振信号混频，直接下变频得到差频信号。这里的关键点在于，24GHz的射频信号处理极其困难，普通单片机根本碰不了，所以射频前端必须做成一个完整的模块，把高频问题挡在模块内部，对外只输出一个频率很低（通常只有几十kHz到几MHz）的差频信号。
中频调理与采样子系统负责把差频信号放大、滤波、数字化。射频前端输出的差频信号幅度可能只有几毫伏，而且夹杂着直流偏置和高频噪声，必须经过带通滤波和可编程增益放大，把目标信号抬到ADC输入范围的中间位置。然后高速ADC以固定采样率采集数据，送给处理器。这一级是整个系统精度最容易失控的地方，我在后面会单独讲。
数字信号处理子系统负责所有算法工作：加窗、FFT、峰值搜索、恒虚警检测、目标跟踪、结果输出。我选用的是Cortex-M4F内核的MCU，主频168MHz，板载DSP指令和FPU单元。之所以不用更高端的应用处理器，是因为雷达数据流的实时性要求很高，MCU的确定性时序更容易满足硬实时需求，而且功耗低一个数量级。
三个子系统的连接关系很清晰：射频前端模块通过排针插在主控板上，中频输出引脚直接连到板载ADC通道，DSP处理后通过串口或Wi-Fi把目标列表发给上位机或云端。我没有用复杂的PCIe或USB3.0接口，因为FMCW雷达的原始数据率并没有想象中那么高——如果用两路中频采样、每路1MSPS、每次采集256个点，一帧数据也才512字节，串口都跑得动。这个设计让整套平台可以直接跑电池供电。
3. 射频前端与中频调理：最容易踩坑的信号链路
3.1 链路预算计算：-80dBm的回波怎么变成可用的信号
很多人第一次调雷达都觉得奇怪：明明模块规格书上写着“探测距离30米”，怎么实际测出来5米就一塌糊涂？原因就是不做事前链路预算，指望芯片的极限参数做事。我搭PLFM_RADAR时专门算了一笔账。
雷达方程给出接收功率的估算：
Pr = Pt × Gt × Gr × λ² × σ / ((4π)³ × R⁴)
其中Pt是发射功率（用dBm表示），Gt和Gr是收发天线增益，λ是波长，σ是目标雷达散射截面积，R是目标距离。以24GHz为例，波长12.5mm，如果发射功率12dBm，收发天线增益各12dBi，对一个RCS约0.1平方米的小型目标（相当于一个小灭火器）做估算，在5米距离上接收功率大约-76dBm，在20米距离上就掉到-88dBm。
-88dBm是什么概念？就是大约4μV的有效值电压。如果接收链路的总增益只有40dB，信号放大后也只有0.4mV，而典型ADC在3.3V参考电压下的LSB接近3.22mV，这意味着信号完全淹没在量化噪声里。所以我在这套系统里把中频链路总增益设计成60dB到80dB可变，前级固定增益40dB，后级用数字电位器做20到40dB的可编程增益。这样5米目标的回波到ADC输入端能抬到100mV以上，20米目标也能维持在10mV级别，配合12位ADC的采样，勉强能保住有效位数。
必须承认，这只是一个理论估算。实际的RCS随目标姿态变化极大，人体正对雷达和侧身对着雷达，回波可以差20dB。所以链路预算的作用不是精确计算，而是确定增益范围的下限，保证最弱的目标信号在放大后不低于ADC的1到2个LSB，否则后续算法做得再漂亮也白搭。
3.2 中频滤波器的截止频率设计：差频信号到底是多少
FMCW雷达的差频信号频率和“目标距离”成正比。在三角波调制下，差频频率f_b满足：
f_b = 2BR / (c×T)
其中B是调制带宽，T是调制周期的一半（单程扫频时间），R是目标距离。
我在PLFM_RADAR里用的参数是：调制带宽B=250MHz，单程扫频时间T=1ms。那么对10米处的目标，差频是：
f_b = 2×250e6×10 / (3e8×1e-3) ≈ 16.67kHz
对50米处的目标，差频约83.3kHz。再考虑多普勒频移的叠加，三角波上下扫频的差频会分别变成f_b - f_d和f_b + f_d，所以中频滤波器带宽至少要覆盖f_b ± f_d的范围。以10米目标、2m/s移动速度为例，24GHz的多普勒频移约320Hz，相对16.67kHz很小，但如果是10m/s的高速车辆，多普勒频移会到1.6kHz左右，滤波器带宽就必须留足余量。
我在中频级联里用了两级带通滤波器：第一级是截止频率1kHz到100kHz的带通，用于抑制直流偏置和带外干扰；第二级是截止频率可切换的低通，通过模拟开关在25kHz、50kHz、100kHz三档之间切换，配合软件里的采样率配置。这样做的目的是把带外噪声滤除，保护ADC的动态范围——因为ADC的动态范围有限，如果带外噪声太大，就会在输入端占掉大量码值，弱目标信号的有效位数被压缩，这个坑在实验室里非常容易踩。
3.3 为什么必须加直流偏置校正
混频器输出的差频信号通常会带一个直流偏置，这个偏置可能高达几百毫伏，远大于目标信号的幅度。如果不做处理，ADC的输入端会一直被偏置顶在高位，小信号的变化完全无法体现。我在中频输入端加了一路DAC，由MCU上电时自动测量偏置电压，然后输出一个反向电压把它抵消掉。这个操作看似简单，但很多人会忽略，直到频谱图里出现一个巨大的直流尖峰，把所有近零频的目标都淹没掉了才反应过来。
实际实现上，我先在系统空闲时连续采样2048个点求平均，把直流分量估计出来，然后设置DAC输出对应电压并且串联一个RC低通网络（截止频率约10Hz），防止DAC噪声引入中频带内。这个校正流程每次上电都要跑一遍，因为射频模块的偏置电压会随温度变化发生漂移。我实测过，环境温度从25℃升到45℃，偏置能漂移50mV左右，如果没做校正，等效于把测距下限抬高了一大截。
4. 从时域到频域：距离-多普勒二维处理的完整算法链
4.1 加窗的讲究：不是所有FFT都对
中频信号经过ADC采样后，进入数字域的第一件事是加窗。很多人图省事直接做FFT，结果发现频谱泄漏严重，短距离目标旁边冒出一堆假峰。这是必然的——因为采集的时域信号是一个有限长度的截断，等效于乘了一个矩形窗，矩形窗的旁瓣衰减只有-13dB，强目标的旁瓣足以淹没弱目标。
我在PLFM_RADAR里默认用汉宁窗（Hann Window），因为它的主瓣宽度适中，旁瓣衰减达到-31dB，对绝大多数室内场景足够用。如果做目标检测时遇到两个距离很近的目标，我会切换成布莱克曼窗，旁瓣能压到-58dB，代价是主瓣展宽50%左右，距离分辨率略有下降。这个权衡是雷达信号处理的老话题，没有绝对最优，只有场景适配。
加窗的代码实现上有一个细节：不需要每次都实时计算窗函数系数。毕竟采样点数通常是固定的（128或256点），窗系数可以直接存成一张查找表放在Flash里，运行时查表相乘即可。我用的是256点的汉宁窗表，每帧FFT多消耗256次乘法，在168MHz主频下耗时几乎可忽略。
4.2 FFT谱峰与距离换算：从频率到米
加窗后的数据做256点FFT（我用的是CMSIS-DSP库的arm_rfft_fast_f32函数，硬件FPU加持下单次FFT大约耗时40μs），输出的频谱在频率轴上是离散的。谱峰的位置对应的频率值就是差频f_b，然后代入前面的公式就能算出距离。
这里有一个分辨率的概念要特别说清楚。FFT的频率分辨率是fs/N，在fs=200kHz、N=256的情况下，频率分辨率约781Hz。对应的距离分辨率是：
ΔR = c×Δf / (2×B×fs_N) ≈ 0.94米
这意味着1米以内的目标距离变化在频谱上是看不出来的，只能通过相位信息来细分。相位测距是另一个话题，PLFM_RADAR的定位是“区域级感知”，0.94米的分辨率够用了——做房间存在检测，能区分“人在这一侧”和“人在另一侧”就已经达标。如果需要厘米级分辨率，就必须增大调制带宽，把B从250MHz提高到2GHz以上，但这会显著增加ADC采样率和数据处理量，并不适合MCU平台。
谱峰搜索的代码不能让FFT输出直接取最大值，必须做插值。直接取最大值会带来一个频点（约781Hz）的量化误差，对应距离误差接近1米。我用的方法是抛物线插值：取峰值点和左右两个邻点的幅度，拟合一条抛物线，用顶点位置作为谱峰频率估计值。实践下来，插值后距离估计的重复精度能到0.2米以内，效果非常明显。
4.3 慢时间维FFT和多普勒速度估计：AD距离-多普勒图的构建
单次扫频的FFT只能得到“距离”，要得到“速度”，必须沿着时间轴再做一个FFT。这就是所谓的慢时间维FFT。
具体做法是：连续采集M个扫频周期（我通常取M=32或64），每一个周期做一次距离FFT，然后对同一个距离门上的M个复数幅度再做一次FFT。由于目标运动导致回波的相位随周期变化，这个二次FFT的谱峰位置就和多普勒频率对应，进而换算出速度。
在PLFM_RADAR上，我把两次FFT的结果组织成一个距离-多普勒矩阵：横轴是距离门（256个），纵轴是多普勒通道（64个），矩阵的幅度代表“该距离上该速度的反射强度”。这个二维矩阵就是后续检测算法的基础。因为两个FFT都是1024点以内的运算，实时性完全没有问题，整体处理时间约1.2ms，而调制周期是1ms，所以理论上可以做到接近实时刷新。
这里有一个必须注意的坑：慢时间FFT是对复数数据进行运算，所以前一级距离FFT的输出必须保留实部和虚部，不能只取幅度。如果只保留幅度谱，相位信息就丢了，多普勒完全做不出来。这个错误在初学雷达信号处理时非常常见。
4.4 恒虚警检测：为什么不能用固定阈值
二维频谱上的噪声底不是平坦的。近距目标的距离维旁瓣、直流偏置泄漏、器件闪烁噪声，都会造成某些距离门上的噪声功率明显偏高。如果用一个固定阈值做检测，要么近距小目标被噪声淹没，要么远距强干扰目标被误判成多个目标。
我采用的是CA-CFAR（单元平均恒虚警检测）算法。其思想是，对每个待检测单元，取它左右两侧的保护单元和参考单元，求参考单元的平均功率，然后乘以一个缩放因子作为检测阈值。如果待检测单元功率超过阈值，就判定为目标。
在24GHz室内场景下，我用的参数是：参考单元8个、保护单元4个，缩放因子设置在12到20之间（对应虚警概率约10⁻⁴到10⁻⁶）。这个参数不能照搬论文，因为不同场景的杂波特性差很多。我在走廊场景会调低到10，在开放场地会调高到25，这些都是实测出来的经验值。CFAR的代码实现也不复杂，麻烦的是对每一个距离多普勒单元都要做一次滑动窗口均值计算，复杂度是O(N²·M)。在MCU上如果逐单元算会卡顿，我用了一个优化技巧：先把距离维的参考单元均值通过一个滑动求和器预先算好，再对多普勒维复用，这样把整体算量降了一个量级，实测帧率从12fps提升到了28fps。
5. 目标跟踪与行为识别：让雷达从“看得到”变成“看得懂”
5.1 凝聚与航迹关联：把散点变成一条连续轨迹
恒虚警检测输出的是一堆离散的点目标，每个点有距离、速度、角度（如果有阵列）和幅度信息。但这些点每帧都在变，可能是同一个人，也可能是新闯入的物体，必须做凝聚和关联。
凝聚（clustering）的作用是合并相邻的距离-多普勒单元，因为一个目标在二维谱上往往会占据2到3个连续单元。我用的是最简单的连通域标记算法，在距离维合并不超过2个单元、多普勒维合并不超过3个单元的检测点，取能量加权中心作为目标位置。20平方米的房间内，这个凝聚操作能把平均50多个检测点合并成2到5个有效目标。
航迹关联（track association）我用的是最近邻关联：上一帧的预测位置和目标本帧位置之间距离小于某个门限就关联为同一条航迹，否则开一条新航迹。门限值设得太小会导致航迹频繁断裂，太大又会让不同目标被错误合并。我的做法是把门限设成3倍的标准差，这个标准差通过实验统计得到——室内人体慢速走动时距离波动约0.3米，所以门限设为0.9米。
5.2 基于速度特征的跌倒检测：一次实测调优的全过程
PLFM_RADAR最有实际意义的应用，是判断一个区域内的人是否跌倒。跌倒检测通常依赖距离变化和速度突变两个特征：正常站立时人的呼吸会引起胸腔微动，距离变化只有毫米级；而跌倒过程中，人体整体快速靠近地面，距离变化速度可以达到每秒1米到2米，远超正常走动的0.3到0.8米每秒。
我在实测中发现，光看距离变化还不够，因为蹲下捡东西也会引起快速距离变化。真正能把“跌倒”区分出来的特征是垂直方向的速度分量变化曲线。正常人蹲下再站起来，垂直速度曲线是对称的——先加速向下，再减速停止，然后反向加速向上。而跌倒的典型特征是：垂直向下的速度持续加速，并且伴随着一个极短的“撞击”信号（也就是在地面上静止后雷达回波大幅度变强）。裸雷达到撞地时刻，频谱上会出现一个宽带的冲击响应，幅度峰值远高于正常走动。
于是我在算法里增加了一个状态机：状态0是正常，状态1是疑似下降（垂直速度超过0.8m/s持续200ms），状态2是撞击确认（在状态1后1秒内检测到宽带冲击信号），状态3是长时间静止（超过30秒距离门内能量无明显变化）。只有当状态机按顺序走到状态3，才判定为“需要关注的跌倒事件”。这个状态机写的判定规则我做了整整两周的真人家具环境模拟测试（志愿者佩戴护具在各种地板材质上反复倒地），最终将误报率控制在每24小时不到1次，而真实跌倒的召回率在95%以上。当然这个指标只是在测试房间里达到的，不同户型、不同家具摆放密度都会影响雷达接收到的回波特性，部署到新环境必须重新跑一轮标定。
6. 部署与标定：雷达不是焊完就能用的东西
6.1 环境标定的两个关键步骤
第一是置空标定。把所有可移动物体搬出监测区域，连续采集5分钟背景数据。这5分钟数据不是直接丢掉，而是要对每一个距离门求平均功率谱，存成一个“背景谱”文件。运行时，每一帧的距离FFT幅度谱都要减去背景谱再做检测。这样做的好处是能把墙面、家具、地板这些静止物体的强反射全部抵消掉，让检测算法只关注真正发生变化的目标。不然的话，2米处沙发的反射信号会强过8米处站着一个成年人，远处的目标很难被发现。
第二是静态杂波图更新。家具位置会变，天气潮湿墙面反射也会变，所以背景谱不是永恒的。我写了一个后台任务，在连续2分钟都没有检测到运动目标的情况下，自动用最新数据替换背景谱的低通滤波版本——新值占70%，旧值占30%，这样既能让背景适应缓慢变化，又不会被瞬时干扰带歪。这个机制在实际部署中非常重要，否则设备运行几天后误报率会悄悄上升。
6.2 安装高度与俯仰角的经验值
安装高度和俯仰角对雷达覆盖区域的影响非常大。我把PLFM_RADAR装在2.4米高的墙角，俯仰角向下倾斜15度，覆盖的是一个7米×5米的扇形区域。如果装得太高且完全不倾斜，雷达波束会打在天花板上产生大量虚假回波；装得太低又会产生近距盲区。
如果要覆盖更远的走廊区域，我建议把雷达放在走廊一端、高度1.8米、水平正对通道方向。千万不要放在走廊中间，因为两侧墙壁的反射会在距离维上叠加成周期性的“梳状谱”，这会严重干扰恒虚警检测的阈值基准。我踩过这个坑，在6米长走廊里正中间部署，检测结果里出现了一串等间距的假目标，查了很久才发现是两侧墙面反射叠加造成的。
6.3 MCU端实时性优化：从12fps到28fps的调整过程
PLFM_RADAR最初在MCU上的帧率只有12fps，距离-多普勒处理能跑到28fps追上实时扫描速度，中间做了三件事。
第一件是把ADC采集和中频处理从主循环搬到DMA中断里，让采样和计算流水线化。原来是一帧全部采完再处理，DMA模式是采一批算一批，时间重叠起来，帧率直接提升80%。
第二件是上文提过的CFAR滑动窗口预计算，这一步把CFAR模块的耗时从4.2ms降到1.1ms。
第三件是调整FFT的实现方式。CMSIS-DSP的实信号FFT接口在数据处理上有个特点：可以直接用arm_rfft_fast_f32得到复数谱，但如果要用相位信息做多普勒维FFT，必须把实信号变换后的数据先“解包”成完整的复数谱（实部偶对称、虚部奇对称）。很多示例代码都忽略了解包这一步，直接用快速接口的输出当作复数谱，导致慢时间维的数据错了一半。我重写了这段解包逻辑，多普勒维的峰值信噪比提升了约6dB，目标检测的稳定性有了质的变化。
7. 我踩过的三个低级错误和它们的教训
第一个低级错误是电源纹波。雷达前端对电源纹波非常敏感，VCO的调谐电压只要叠加1mV的纹波，发射信号频谱上就会出现杂散，这些杂散混频后会变成中频带内的毛刺，表现成距离维上的固定假目标。我最初用了一颗普通的LDO给射频模块供电，在频谱上看到一堆等间隔的小峰，怎么调算法都消不掉。换了一颗低噪声LDO并且增加了一组LC滤波后，毛刺直接消失了。所以在这个系统里，电源设计要从一开始就按射频电路的规格来，不能图方便用一个通用3.3V。
第二个低级错误是使用了过长的FFT点数。我一开始想当然地做1024点FFT，觉得分辨率更高。问题是1024点和256点的距离分辨能力其实一样，因为距离分辨率由调制带宽决定，跟FFT点数无关。FFT点数增大只改变了采样时间内对连续频谱的采样密度，对真实分辨能力没有帮助。反而增加了计算时间，当时帧率被拖到不到8fps。后来改成256点FFT，计算量降了16倍，帧率大幅提升，而距离测量精度靠抛物线插值完全弥补了分辨率损失。
第三个低级错误是忽略了天线罩的影响。我把雷达放在一个塑料外壳里测试，结果发现测距曲线出现了0.3米左右的系统性偏移。原因是塑料外壳的介电常数造成电磁波传播速度变慢，等效于光程增加。这不是软件能修好的，必须在标定时把外壳装上再采集背景谱，而且要保证外壳不被松动或替换，否则标定数据就全错。后来我在设计上把外壳做成卡扣固定，并且在固件里记录外壳的介电常数补偿参数。
这三个错误总结起来就是一句话：雷达系统的每一个环节——射频、电源、机械结构、算法——都会在最终输出里留下痕迹。只盯着算法层面的问题，永远爬不出系统性的坑。
8. 回到PLFM_RADAR这个平台：它到底适合怎么用
如果让我重新评价PLFM_RADAR这套平台的价值，我会说它最大的意义不是某个单独的测距或测速功能，而是把“从射频硬件到目标级数据输出”的完整链路打通了。作为一个验证平台，我可以在这个基础上快速试验不同的调制参数、探测算法、应用层逻辑，而不需要每次都从零开始搭硬件。
实际使用中它适合做这么几件事：用在对隐私敏感的室内监测场景（比如养老机构的夜起监测，不录像只感知位置变化），用在工业设备的非接触振动检测（通过多普勒频率判断设备是否异常抖动），用在智能家居里作为人来人往的感知器（比红外热释电灵敏度更高、能区分运动和静止）。如果你想在无人机上做辅助定高、在机器人上做近距离避障，这套平台的算法框架也能直接迁移，只需要把调制带宽和天线波束调整一版。
最后分享一个我这里一直在用的小技巧：开发阶段不要一上来就用自己对接的算法代码，先借助一套雷达开发套件的官方上位机软件（这类软件几乎每家雷达芯片厂商都会提供）观察原始的距离-多普勒图，确认硬件工作正常、底噪干净，再逐步替换成自己的处理代码。否则硬件和算法同时调，出了问题很难定位是哪一环。
PLFM_RADAR这个名字看起来高深，实际上是“平台+雷达”的朴素组合。它让我养成了一个习惯：面对一个感知需求时，先搞清楚物理约束、链路预算和信号模型，再决定用摄像头还是雷达，以及做成什么形态。这套思路，才是这个平台带给我的真正收获。
