企业官网建设流程全解析

毫米波雷达感知链路总览：从 ADC 到目标列表

做雷达感知的朋友应该都有这种感觉：看了很多论文、啃了不少代码，但真到了要自研一套毫米波雷达感知算法，或者要把一颗雷达芯片用起来的时候，第一步就卡在“数据到底长什么样、中间到底经历了什么”这个问题上。我前阵子正好花了两周时间，把毫米波雷达的完整感知链路从ADC采样一路捋到目标列表输出，把代码、仿真、实测数据对着过了一遍，今天把这条链路拆开揉碎写出来，希望对正在入门毫米波雷达感知、或者想系统梳理信号处理流程的工程师、研究生有点帮助。

这个内容解决的核心问题很直接：ADC之后那一大坨数据，经过什么处理才变成我们看到的目标点云和目标列表。适合刚接触车载雷达、工业安防雷达、智能传感项目的人阅读，也适合那些做嵌入式但被雷达算法团队“喂数据”的工程师建立全局观。我会把每条链路环节的原理、参数选择逻辑、实测中容易踩的坑都讲清楚。

1. 一条链路的完整图景：从模拟世界到目标列表

雷达感知链路说起来就是一句话：把天线收到的微弱射频回波，变成一串带有距离、速度、角度信息的结构化目标列表。但这个过程中间跨了好几个学科，射频前端、模拟中频、高速ADC、数字信号处理、自适应检测、聚类跟踪，任何一环的参数不匹配，都会让最终结果面目全非。

我把这条链路拆成七个主要阶段，先给一个全貌，后面再逐段深入：

• 射频收发与混频：发射调频连续波，接收回波并与本振混频，产生中频信号；
• 中频调理与ADC采样：中频信号经过放大滤波后，被ADC以合适采样率数字化；
• 距离维FFT：对每一段chirp的ADC数据做快速傅里叶变换，把时域拍频信号变成距离维频谱；
• 速度维FFT：对同一距离单元上的多chirp数据再做一次FFT，得到距离-多普勒图；
• 目标检测：在距离-多普勒图上做CFAR检测，区分目标回波和噪声杂波；
• 角度估计：利用多通道天线相位差估计目标方位角；
• 目标聚类与跟踪：把符合条件的点云聚类成目标，再经滤波跟踪后输出稳定的目标列表。

为什么要强调全链路？因为我发现很多刚入行的同事，做算法的只关心FFT和CFAR，做硬件的只关心ADC和接口，两边对不上话。比如硬件按最高性能选了ADC，但算法端根本没用到那么高采样率；算法端以为自己拿到了高信噪比数据，结果前端增益留了余量导致ADC有效位数浪费。这些都是链路割裂导致的典型问题。

我在调试中也体会到，真正决定雷达系统上限的，恰恰是那些容易被忽略的最前端细节。ADC采样时刻的抖动、中频滤波器的相位纹波、chirp配置的线性度，每一个都会沿着链路放大，最后在目标列表上表现为虚假点、速度模糊或者角度偏差。所以搞毫米波雷达，必须先有全链路视角，再钻到具体环节里。

2. ADC采样：把电磁波变成数字世界的第一道门

2.1 混频之后，ADC到底在采什么

很多人第一次看雷达框图会困惑：ADC采的不就是天线收到的信号吗？其实不是。ADC采的是“拍频信号”。调频连续波雷达发射频率随时间线性变化的信号，回波经过目标反射后，与发射信号的本振混频，两个频率之差就是目标距离对应的中频频率。

这里我用个生活化类比：发射信号像一个不断升调的人声，回波是同一个声音的延迟版，两者同时进耳朵会产生一个“嗡嗡”的拍频音，音调高低对应距离远近。ADC采的就是这个拍频音，也就是中频信号，而不是几十GHz的载波本身。

中频信号频率一般落在几十kHz到几十MHz之间，取决于最大探测距离和chirp斜率。比如chirp斜率是S MHz/μs，目标距离对应的回波延迟是τ，那么拍频频率就是S×τ。一个距离100米的目标，如果斜率是30 MHz/μs，回波延迟约0.67μs，拍频就是20 MHz。ADC采的就是这个20MHz左右的正弦波。

这一步理解到位了，后面很多参数选择就顺了。ADC的采样率不取决于射频频率，而取决于中频带宽；ADC的量化噪声直接叠加到中频信号上，决定了整个链路的信噪比天花板。

2.2 采样率、分辨率、有效位数怎么选

ADC选型这块，我设计雷达接收机时一般按下面几个思路来定：

• 采样率：至少满足中频信号最高频率的奈奎斯特条件，工程上通常留1.2到1.5倍裕量。比如最大探测距离设计为200米，对应最大拍频40MHz，那采样率至少要80MSps，我通常会用100MSps以上。
• 分辨率：理论上12位以上的ADC已经能满足大多数雷达应用，因为雷达处理的动态范围本质上由距离衰减和RCS差异决定，中频信号经过AGC后幅度被控制在ADC满量程附近。
• 有效位数ENOB：这是容易被忽略的指标。很多高速ADC标称12位，但在100MHz采样率下ENOB可能只有9到10位。有效位数不够时，量化噪声抬高噪声底，CFAR检测的虚警率会明显升高。
• 带宽和输入驱动：ADC前端的运放驱动电路、抗混叠滤波器带宽要够，否则信号还没进ADC就已经被衰减了。

我之前做过一个方案对比，同样一颗毫米波前端芯片，后端配了10位和14位两套ADC方案。实测下来，远距离目标的信噪比差异非常明显，14位方案可以多探测20%到30%的微弱目标，这不是算法能弥补的，因为量化噪声已经到了噪声底附近。

还有一个工程细节：多片ADC同步采样时钟。多通道雷达通常需要多个ADC通道同步采样，采样时钟的skew会导致通道间相位误差，这个误差会直接影响后面角度估计的精度。我见过一次角度偏差超过5度的问题，最后定位到就是两片ADC的采样时钟差了不到1纳秒。

2.3 采样数据格式与缓冲的常见坑

ADC送出来的数据通常是二进制补码格式，常见有16位或24位宽，多通道交织或者多片拼接。这里有两个坑特别提醒：

• 字节序和位宽对齐：不同厂家的ADC输出格式可能不同，有的高位在前，有的低位在前，需要在FPGA或DSP里统一处理。否则出来一条全零或者符号翻转的数据流。
• 缓冲机制：雷达是帧间隔工作的，ADC持续采样，但DSP只需要在有效chirp时间内处理。我习惯用双缓冲加DMA搬运，一帧在采集时另一帧在计算，避免丢数或者覆盖。

网络热词里提到的“C语言ADC值滤波函数”，我在嵌入式处理时也常用。特别是ADC输出偶尔有尖峰毛刺，我会在FPGA里做一阶滑窗滤波或者中值滤波，把毛刺消掉再写入DDR。注意滤波会引入群延迟，对距离维FFT影响不大，但对要求极低延迟的闭环应用要权衡。

3. 距离维处理：第一维FFT背后的事

3.1 Range FFT的物理含义

ADC数据经过重排后，会按照chirp组织成矩阵：一列是一个chirp内采样得到的时域序列，行数等于ADC采样点数。对这一列数据做FFT，频谱峰值对应的频率就是目标的拍频，换算成距离就是目标距离。

这一步有两个容易混淆的点：

• FFT峰值频率和距离的换算依赖chirp斜率S。同样的频率，如果斜率翻倍，对应距离减半。所以配置chirp时斜率必须精确已知，否则距离会有系统性偏差。
• FFT点数N决定距离维的频率分辨率Δf = Fs/N，对应的距离分辨率ΔR = c/(2B)，其中B是chirp带宽。这句话的意思是：距离分辨率不由采样点数直接决定，而是由发射信号带宽决定。很多人误解为“采样点数越多距离分辨率越高”，实际上增加FFT点数只能让频谱更细腻，但两个目标能不能分开依然取决于带宽。

我实测过一次：用4GHz带宽的chirp，距离分辨率理论上是3.75厘米，但我用256点FFT去画频谱，看到的目标峰值宽度确实远大于理论分辨率，这是因为加窗效应。正因如此，工程上一般会用补零FFT来让峰值更好找，但不要误以为补零能提高真实分辨率。

3.2 加窗、补零和幅度标定

Range FFT前加窗是标准操作，目的是压低旁瓣。矩形窗的主瓣最窄，但第一旁瓣只比主瓣低13dB左右，这对雷达来说太差了——一个强目标的旁瓣可能盖过另一个弱目标。我在工程中常用汉明窗或者布莱克曼窗，把旁瓣压到40dB以下，代价是主瓣变宽一点。

这个取舍在近距离多目标场景特别明显。比如停车场里两辆并排停的车，距离接近，不加窗可能分辨不出来；加了窗后分辨能力稍有下降，但能稳稳地检测到两个目标各自的位置。

幅度标定也值得说。Range FFT谱线上的幅值受天线增益、前端增益、传播损耗、ADC转换系数影响。我一般在校准阶段用一个已知RCS的角反射器放在已知距离，反推出一套幅度标定系数。后面所有目标幅度都经过这个系数归一化，这样点云质量评估才有意义。

3.3 距离维处理中的实操陷阱

补零操作虽然好用，但有一个副作用：会让频谱看起来更光滑，有时会掩盖一些真实细节。我在调试时遇到过一次，两个间距刚好在半分辨率附近的目标，补零后波形看上去像一个宽峰，如果只找局部最大值就会漏检第二个目标。后来我在代码里加了一个“峰分裂检测”逻辑，检测主峰两侧是否存在接近峰值的次级峰，才解决这个问题。

另外，Range FFT最好使用浮点计算。如果嵌入式平台性能受限必须用定点，至少要把输入数据做合适的Q格式转换，保留足够的分数位，不然FFT输出噪声底抬高，CFAR阈值会被迫上调，灵敏度和虚警同时恶化。

4. 速度维处理与多普勒解模糊

4.1 2D FFT与相参积累

一个chirp做完Range FFT后，我们得到的是距离维频谱。要得到速度，需要把多个chirp（通常一个帧内发几十到几百个chirp）在同一个距离单元上的复数信号再做一次FFT。因为目标运动导致相邻chirp之间的相位差与径向速度成正比，第二次FFT的峰值位置就是速度。

这里有个重要的概念：相参积累增益。第二次FFT本质上是一个相参积累器，它把N个chirp的信号能量相干叠加，信噪比提升约10log10(N)dB。这个增益是雷达能检测微弱目标的关键。

我举个实际数字：单个chirp回波的信噪比可能只有8dB，做一个128次相参积累，信噪比可以提升到29dB左右，CFAR检测的可靠性就完全不同了。所以增大帧内chirp数不仅能提高速度分辨率，还能提高检测灵敏度，缺点是帧时间变长，对运动目标会导致距离走动。

4.2 速度模糊与解模糊策略

速度维FFT有一个最大不模糊速度限制，这是由chirp周期决定的。两条相邻chirp的相位差如果超过π，速度就会出现混叠，目标被映射到错误的速度单元上。最大不模糊速度Vm = λ/(4×Tchirp)，其中λ是波长，Tchirp是chirp重复周期。

要扩大Vm，必须缩短chirp周期，但chirp周期又受限于最大探测距离和中频带宽。这是一个硬约束下的折中，也是多普勒雷达设计最核心的取舍之一。

工程上常见的办法是采用变间隔chirp序列。我在一个项目中用了“双速率”chirp设计：每帧里交替使用T1和T2两种chirp周期，它们的最大不模糊速度不同，通过比较两次FFT得到的多普勒频率，就能解出真实速度。这个方法实现简单、运算量增加不多，在我做过的车载方案里效果很稳定。

另一个思路是使用多帧数据在跟踪层做速度解模糊，也就是航迹关联时利用位置差分估计的真实速度来修正多普勒模糊。这个方法对跟踪器要求较高，但适合已经有了稳定跟踪的应用。

4.3 相位噪声和多雷达互扰

速度维处理对相位噪声非常敏感。如果发射源的相位噪声差，相邻chirp之间的相位抖动会直接抬高多普勒频谱的噪声底，低速目标会淹没在噪声中。我在实测中发现，高相位噪声场景下，静止目标的杂波谱会显著展宽，甚至会“污染”相邻几个速度单元。

毫米波雷达大规模部署后，互扰问题也会在速度维上暴露出来。别的雷达的信号进入你的接收机，如果调频斜率接近，就会出现交叉干扰，在多普勒谱上显示为随机分布的亮线或者假目标。目前比较实用的做法有：利用扰码随机化chirp起始时刻、在检测端使用基于密度的干扰剔除算法，再配合波形参数的随机跳变。

我自己的调试经验是：拿到一颗新雷达芯片，先不做任何算法，直接采集一段无目标的ADC原始数据，看看距离-多普勒图的静态噪声底是什么水平。如果噪声底有周期性抬升，多半是电源引入的共模噪声；如果噪声底呈宽带平坦抬升，多半是ADC有效位数不够或者中频增益不足。这个“体检”习惯能帮你在算法开发前排除大量硬件隐患。

5. 目标检测：从能量图到点云

5.1 CFAR检测原理与参数标定

距离-多普勒图本质是一张二维能量谱，但噪声底不是均匀的。近距强反射体旁的噪声底高，远区的噪声底低，如果用一个固定阈值，要么近距虚警多，要么远距漏检多。所以需要有恒虚警率检测（CFAR），利用被检测单元周围参考单元的平均功率自适应计算阈值。

工程上常用CA-CFAR（单元平均恒虚警）和OS-CFAR（有序统计恒虚警）。CA-CFAR在均匀噪声场景下损失最小，但在多目标邻近场景下可能出现“遮蔽”效应：两个邻近目标互相抬高参考单元均值，导致彼此都检测不到。OS-CFAR对多目标更稳健，但运算量大，需要排序。

我在目标稀疏场景（比如工业测距）会直接用CA-CFAR，参数好调；在车载或者交通场景，则用OS-CFAR或者CA-CFAR加保护单元的混合方案。保护单元的数量也很关键：目标能量会泄漏到邻近几个距离单元和多普勒单元，这些泄漏单元不能统计到参考均值里，否则目标自身会被当成噪声，阈值抬过头就检测不到了。

这里给出一组我常用的初始参数，作为调参起点：

• 距离维参考单元：左右各8个
• 距离维保护单元：左右各2个
• 多普勒维参考单元：上下各8个
• 多普勒维保护单元：上下各2个
• 虚警概率Pfa：1e-4到1e-5
• 检测阈值修正系数：由Pfa和参考单元数查表得出

这批参数可以先用蒙特卡洛仿真验证，再拿到实测数据上微调。注意CFAR参数的调整一定要结合点云输出一起看，只看检测矩阵有时候感觉良好，但输出的点全部是杂波，这种问题在实测中很常见。

5.2 静态杂波抑制

对于大多数场景，墙体、地面、护栏这些静态物体的回波强度远大于运动目标，它们会占据固定的距离-多普勒单元。如果不做处理，CFAR检测出的目标列表里就会充满静止杂波点。

最常用的方法是MTI（动目标指示）——把相邻chirp的Range FFT结果相减，静态目标的相位不变、相减后抵消，运动目标的相位变化、相减后保留。这个方法简单高效，代价是损失多普勒频谱的低频部分，也就是低速目标的检测能力。

如果系统需要保留静止目标（比如探测静态入侵者），就不能用MTI，而要用空间杂波图。做法是长时间累积每个距离-多普勒单元的功率均值，写成一张“背景杂波图”，检测时用实时数据除以背景图得到对比度再做CFAR。这个方案我在地面安防雷达中用过，效果比MTI好很多，但对场景变化适应慢，大树被风吹动之类的场景要谨慎使用。

5.3 从检测单元到点云的坐标转换

CFAR检测得到的是（距离索引、多普勒索引）二元组，它不是最终的目标位置。要把索引换成真实的距离和速度，需要乘以对应的标度系数：

• 距离 = 索引频率 × c / (2S)，这里S是chirp斜率；
• 径向速度 = 多普勒频率 × λ / 2，注意正负号要跟多普勒维FFT的符号约定一致；
• 角度 = 由多通道相位差估计得出（下一章细说）。

然后调用坐标转换，把极坐标（距离、角度）或球坐标（距离、方位、俯仰）下的位置转换到直角坐标系，就得到点云中的每个点。这部分工作看起来不起眼，但单位不一致、坐标偏移没校准、坐标系正方向定义错了，后面做跟踪全是白做。我建议在项目一开始就写一个统一的坐标定义文档，所有人按同一套约定来。

6. 角度估计：多通道相位差解密方位

6.1 从单通道到阵列测角的基本原理

单通道雷达只有距离和速度信息，没有角度信息。要测角，必须用多个接收天线。目标回波到不同天线的传播路径长度不同，导致接收信号的相位差与目标角度相关。这个相位差是角度估计的核心观测量。

最简单的测角是数字波束成形（DBF）：对多通道的复数据，通过一组指向不同角度方向的加权系数进行扫描。在每个假设角度上计算该方向的信号能量，峰值所在角度就是目标方向。这个方法稳健、实现简单，是工程上应用最广的方案。

还有一个实现要点：角度估计通常在距离-多普勒检测点的邻近单元上做，而不是在全图上做。也就是先用CFAR找“在哪”，再用多通道数据测“从哪个方向来”。这样可以大幅降低运算量，也便于把角度估计和检测解耦。

6.2 天线阵列设计与MIMO虚拟孔径

单根天线对角度分辨能力有限，波束宽度由天线口径决定，口径越大分辨率越高。物理上增大口径意味着天线数量变多、雷达尺寸变大，成本也高。MIMO技术是破局的关键：发射端用多个天线分时或编码发射，接收端用M个天线接收，可以等效成一个M×N的虚拟接收阵列，在不大幅增加硬件的情况下把孔径做大。

我在做阵列设计时，最关心的指标是角度视场和角度分辨率。虚拟阵列的阵元间距一般设计为半波长，以保证不出现栅瓣；视场则由波束宽度决定，通常是正负60度到正负90度。分辨率由等效孔径决定，相同阵元数下，均匀阵列分辨率有限，所以业界也会用稀疏阵列或者超分辨算法来提升。

注意：虚拟阵列的正确性依赖MIMO波形编码的正交性。如果发射信号之间互相关不够低，角度估计会出现“假瓣”。TDMA（时分复用）是最简单的正交方式，代价是相参时间变长、最大不模糊速度变小；多普勒分多址则在高速目标场景下会引入额外相位。选哪种，要看你的速度测量要求。

6.3 超分辨测角的工程取舍

高精度测角场景可以使用MUSIC、ESPRIT这类子空间类超分辨算法。它们能把角度分辨率做到瑞利限以下，但计算量大、对通道幅相一致性非常敏感，尤其是通道间幅度误差和相位误差，误差大了这些算法的性能会急剧恶化。

我建议的取舍策略是：先做通道校正，再做DBF或FFT测角，只有多目标在同一个距离-多普勒单元内、传统方法无法有效分辨时，才考虑上子空间算法。而且上超分辨算法前，一定先测一遍各通道的幅度-相位一致性，用角反射器在视场中心校准，把剩余相位误差控制在5度以内。

之前在一个项目里，我为了追求角度分辨率，直接上了MUSIC算法，结果实测数据角度抖动非常大。后来发现是通道间相位误差到了15度以上。校正之后，同样的算法输出就稳定了。所以通道校准这件事，怎么强调都不过分，优先解决它再谈算法选型。

7. 目标聚类与目标列表生成

7.1 点云聚类的常用策略

经过检测和测角之后，一个目标可能会产生多个点：车尾、车身、路边的行人都可能各自贡献多个反射点。如果直接把所有点输出到上层，数据量太大、不直观。目标列表生成前，需要先做聚类——把空间上相邻、多普勒速度一致的点归成一个目标。

工程上常用基于密度的聚类算法（DBSCAN），它对形状不敏感，不需要预先指定目标个数，适合雷达点云的任意形状聚类。DBSCAN有两个关键参数：邻域半径eps和最小点数minPts。eps设大了近距离目标容易粘连，设小了车尾的两个点可能会被拆成两个目标。我的调参经验是先用一段典型场景数据离线聚类，人工核对分类结果后，再反过来定参数，不要一上来就套默认值。

另外，聚类后的目标中心可以用加权重心法计算。权值可以是点云幅度，幅度越高的点在目标中心估计中权重越大，这样目标位置更贴近雷达反射最强的部位。实际效果比简单平均更能反映目标真实位置。

7.2 目标跟踪与航迹管理

单帧聚类输出的目标列表还有噪声和随机跳变，直接把列表交给上层应用，用户体验往往不好。更稳妥的做法是加一个轻量级跟踪器，比如卡尔曼滤波：对每个目标维护状态（位置、速度、加速度），每帧用新点云做关联和更新。

我到这一步最常用的是最近邻关联加匀速或匀加速模型。目标少时这样够用；目标多、交叉频繁时，需要JPDA或多假设跟踪算法。但算法的复杂度是逐步增加的，我在工程里一定先试最简单的方案，确认瓶颈确实在关联后才换复杂算法。

还有一个实操细节：跟踪器里的时间戳非常重要。雷达帧率抖动、上位机处理延迟都会影响量测时间，如果时间戳不准，速度估计会出现明显偏差。我建议在雷达数据结构里带上硬件时间戳，跟踪运算全部基于时间差而不是帧序号。

7.3 目标列表的数据结构设计

目标列表最终交给上位机或者ADAS应用时，数据结构要清晰、稳定、可扩展。我的习惯是定义如下核心字段：

• 目标ID：用于长时间关联，应该稳定复用而不是每次重新分配；
• 位置：目标在直角坐标系下的x、y、z，单位米；
• 速度：径向速度或者二维速度，单位米每秒；
• RCS估计值：用于目标分类和置信度评估；
• 置信度：由检测信噪比、关联质量、跟踪残差综合得出；
• 生命周期状态：新航迹、确认航迹、丢失航迹等状态。

这里特别提醒目标ID管理：我遇到过因为ID频繁切换，上位机动画显示的目标轨迹总是跳变，视觉上看起来就像目标在瞬移。排查下来是聚类中心不连贯导致的ID抖动。在聚类中心输出前加一个低速平滑，或者让跟踪器接管ID稳定性，都能改善这个问题。

到这里，从ADC采样原始数据，到输出带ID、位置、速度的目标列表，整条毫米波雷达感知链路就闭合了。

8. 实测问题与排查技巧实录

8.1 实测常见问题速查表

我把过去实际调试中遇到的高频问题整理成一张速查表，方便大家在现场快速排查：

这张表并不覆盖所有情况，但覆盖了我在实际项目中踩过的八成坑。现场排查时，关键是先把链路各环节的“中间输出”都可视化出来：时域ADC波形、距离谱、距离-多普勒图、点云图、目标列表，只要你能看到每一级的输出，问题定位就成功了一半。

8.2 常用调试工具与流程

我自己的调试流程一般是这样的：先用TI的mmWave Studio或者同类芯片厂商的调试工具，确认前端配置和ADC数据正常，把raw data保存下来；然后用Python加载raw data，先画出单chirp时域波形，再单步执行距离FFT、多普勒FFT、CFAR、测角，每一步都对照预期结果。

这个流程特别适合定位问题边界：如果raw data时域波形都不对，那就是射频或采集端问题；如果时域波形正常但距离FFT后看不见目标峰，那就是增益或幅度标定问题；如果距离OK但多普勒不对，那就是chirp配置或符号约定问题。逐级验证，就能避免拿着一个“看起来没问题”的点云图去怀疑算法，最后发现前端早就挂了。

Python做算法原型验证非常方便，numpy的FFT函数和scipy的信号处理工具足够完成绝大部分工作。我还会配合matplotlib画出完整的“链路调试九宫格”，一张图里放时域、距离谱、距离-多普勒图、CFAR检测结果、角度谱、点云图，一眼就能看出链路哪里断了。

8.3 几个特别值得说的经验

最后分享三个我交了不少学费才换来的经验：

第一，ADC原始数据的质量决定一切。我后来做雷达算法开发，拿到新板子的第一件事永远是采集最短的一帧raw data，直接在频域看噪声底和杂散。如果这关不过，后面加再多算法都是浪费精力。记住一句话：算法不生产信息，只提取信息。

第二，雷达的点云图好看不等于目标列表可靠。点云可以很密集，看起来目标很清晰，但CFAR的虚警率可能高得离谱。我在验证系统性能时，一定会统计长时段的虚警数量和时间抖动，而不是只看一两帧的效果。

第三，全链路参数要有“联动思维”。改ADC采样率会影响距离分辨率；改chirp周期会影响最大不模糊速度；改虚拟阵列配置会影响角度视场；改CFAR参数会影响点云密度，进而影响聚类效果。你必须把这些参数放在一起权衡，而不是孤立地调某一个环节。

我自己的习惯是维护一张“全链路参数总表”，把所有关键参数集中管理，每次改动都另存版本并标注改动原因。这个习惯帮我节省了大量回头排查配置的时间。在雷达感知这类牵一发动全身的项目里，这种笨功夫特别值得下。

毫米波雷达感知链路说长不长，说短不短，但每个环节都藏着让调参工程师熬夜的细节。希望这篇文章能帮你在入坑之前先把全貌看清楚。如果你正在做类似的项目，建议先从接收一帧raw data开始，亲手走一遍从ADC到目标列表的全过程。只有把这条链路走通了，后面加算法、换硬件，才有判断力。