雷达信号处理链：从天线到点云的关键模块

从天线接收到可供融合的点云，毫米波雷达要经过一连串信号变换。本文梳理这条处理链路：chirp 发射、ADC 采样、距离/速度 FFT、CFAR 检测到聚类，说明每个模块在做什么、对性能有何影响。

1. 收发与 chirp

雷达以调频连续波（FMCW）方式工作，发射端按设定斜率扫频形成 chirp，接收端混频得到中频信号，其频率携带目标距离与速度信息。chirp 的斜率、时长与帧结构决定距离分辨率、速度分辨率与刷新率，是信号处理链的源头参数。

2. ADC 与 FFT

中频信号经模数转换进入数字域，先对单个 chirp 做距离维 FFT，得到距离谱；再跨多个 chirp 做多普勒维 FFT，得到速度谱，两者构成距离—多普勒图。FFT 的点数、窗函数与采样率共同决定谱分辨率与旁瓣水平，参数需在分辨率与计算量之间平衡。

3. CFAR 检测

在距离—多普勒图上，用恒虚警率（CFAR）算法自适应设定门限，从噪声与杂波中挑出真实峰。CFAR 的窗口大小与保护单元设置影响虚警与漏检的权衡：窗口过大易漏弱目标，过小则在杂波边缘误报。不同路面需做参数适配。

4. 聚类与点云

检测到的峰值经角度估计（如 FFT 或超分辨算法）得到方位，再按帧间关联聚合成稳定目标，输出距离、速度、角度与置信度构成的点云或目标列表。聚类参数决定目标分裂与合并行为，直接影响下游融合的质量。整条链路的每个环节都会向上游传递误差，需端到端联调。

5. 算力与算法边界

更高通道数带来更密的谱计算与更大的点云，对处理器算力与带宽提出要求。算法上，超分辨测角可突破孔径限制但更依赖信噪比与校准质量。选型时应把"算法能发挥多少硬件潜力"纳入评估，而非只看硬件规格。

6. 标定参数的作用

通道间相位与增益失配若未校准，会直接污染角度估计与 CFAR 表现。产线标定给出的补偿参数，是信号处理链正常工作前提。理解这一点，有助于在出现异常时区分是硬件失配还是算法参数问题。

7. 角度估计的两种路线

角度可由 FFT 直接得到（受孔径限制），也可由超分辨算法（如 MUSIC、Capon）突破瑞利限，在密集目标下分辨更细。超分辨更依赖信噪比与通道校准质量，低信噪比时反而不稳。实际系统常混合使用：先用 FFT 粗估，再在感兴趣区做超分辨，兼顾效率与精度。

8. 点云质量与下游

点云的密度、噪声与漏点直接决定融合效果。稀疏或抖动点云会让跟踪困难、虚警上升。应在算法层评估点云的稳定度指标，而非只看探测距离。把点云质量纳入验收，能倒逼前段信号处理与校准到位。

9. 资源与实时性

高阶处理对算力与带宽要求高，需在成本与实时性间平衡。帧周期决定刷新率，算法复杂度决定能否在规定时间内完成。选型时应要求供应商给出典型负载与坏情况时延，并在域控端做端到端时延验证，避免理论很快、实车卡顿。

10. 算法与硬件的协同优化

信号处理的效果上限由硬件决定，下限由算法决定。同样的射频前端，校准质量与算法参数不同，输出点云可能天差地别。优化时应软硬件协同：硬件保证通道一致性与低噪声，算法负责在噪声中稳定提取目标。验收时不应只看硬件规格，而要看端到端的点云质量指标，这样才能真实反映系统水平，也倒逼前段把基础打牢。

11. 典型性能误区

评估信号处理常陷入几个误区：其一是把分辨率公式当作实际可区分能力，忽略信噪比影响；其二是只看探测距离，不考查点云稳定度；其三是用理想环境数据代表真实路况。规避这些误区的方法是建立贴近场景的验收用例，在噪声、杂波与密集目标下测试，并记录虚警、漏检与抖动指标。用场景化评估代替参数表比对，结论才可靠。

12. 算力与定点实现的细节

信号处理在芯片上多以定点运算实现，字长与舍入策略会影响动态范围与精度，进而作用于弱目标检测与角度估计。评估时不能只看算法理论，还要看其在目标硬件上的实际表现：定点误差是否导致近距强目标掩盖远距弱目标，是否引入可察觉的测距抖动。工程上常做仿真与实板比对，把算法指标与硬件实现指标分开报告。对高通道成像雷达，数据率与算力需求陡增，需在架构上做流水线与时分复用。把定点与资源约束纳入验收，才能确知算法在真实产品上的水位，避免实验室浮点结果误导量产预期，也帮助划分算法与硬件的责任边界，使问题定位更高效。

算法指标的工程验收

信号处理能力的验收，应落到可量化指标：点云密度与噪声、漏点与虚警率、角分辨稳定度、端到端时延。只看探测距离会掩盖点云质量问题，而稀疏或抖动点云会让下游跟踪困难。把点云质量纳入验收，能倒逼前段信号处理与校准到位。

高阶处理对算力与带宽要求高，需在成本与实时性间平衡。选型时要求供应商给出典型负载与较差情况时延，并在域控端做端到端时延验证，避免理论很快、实车卡顿。算法能力终归要在整车节拍内闭环才有意义。

13. 算法可解释性与验收

随算法复杂化，黑箱问题凸显：当探测异常，难以定位是数据还是模型。可解释性要求算法输出不仅有点云，还要有关键中间量可供排查，例如信噪比、检测置信度与跟踪状态。验收时把这些中间量纳入报告，便于供应商与整车端协同诊断。对高阶雷达，还应约定算法版本管理与回滚机制，避免一次升级引入新问题无法恢复。把可解释性作为验收维度，能提升长期可维护性，也降低联合调试的沟通成本，是算法成熟度的隐性指标，建议在技术协议中明确相关字段与接口，为后续运维留好抓手。