企业官网建设流程全解析

刚接触毫米波雷达的人，第一次打开24GHz雷达模块的datasheet时，看到FMCW三个字母大概率会愣一下。明明叫“连续波”雷达，却能同时测距离和速度，这跟教科书里那个只靠多普勒频偏测速的连续波雷达，到底差在哪？我最近在用24GHz FMCW模块给单片机小车做测速和避障，后面又顺手把一套77GHz雷达接到摄像头做目标融合，把这个链路从高频前端一路追到单片机里的FFT代码，才算把FMCW测速彻底捋顺。这篇文章就围绕FMCW毫米波雷达测速这一个主题，把原理、参数设计、硬件选型、C++实现和实测标定串起来讲，给想自己搭测速系统或者在研究雷达测速算法的朋友一个可以直接参考的版本。

1. 为什么FMCW能同时拿距离和速度：它跟多普勒雷达不是一回事

1.1 单频连续波雷达只能测速度，FMCW多了一个维度

在真正上手雷达模块之前，我曾经想当然地以为，所谓测速就是靠多普勒效应求相对速度，就像超市感应门、雷达测速枪那样，发一个固定频率的信号出去，等它弹回来，读频偏，速度就出来了。这个思路没错，但它只适用于单频连续波雷达，也就是CW雷达。CW雷达有个致命问题：它测不到距离。因为固定频率回波的相位随距离变化，但你没法仅凭一个频点判断目标在40米还是4米，只能知道它动了没有、动得多快。这种雷达用来做门禁感应、简单测速枪可以，但放到公路上就麻烦了——你不知道目标从哪来、在哪个距离，自然也就分不清正在测的到底是哪辆车。

FMCW的全称是Frequency Modulated Continuous Wave，线性调频连续波。它把发射频率做成随时间线性变化的斜坡，这个斜坡在行业里通常叫chirp。发射频率在扫，回波信号回来后会有一个时间延迟，把回波和本振信号一混频，就能得到一个差频，也就是常说的拍频。这个拍频的大小和目标距离直接相关。与此同时，目标还在动，每个chirp之间的回波相位在持续累积变化，而相位变化率就是多普勒频率。于是FMCW就在同一套微波前端里，同时完成了“用差频测距离”和“用相移测速度”两件事。

我见过不少刚入门的人把FMCW理解成“多普勒雷达的增强版”，其实更准确的说法是：FMCW把时间测量转换成了频率测量。光速太快，直接测电磁波往返时间在大多数场景下不现实，但把延时折算成差频之后，中频信号只有几百kHz甚至更低，ADC和单片机都很好处理。这也是FMCW能在车载雷达、工业液位计、周界安防里大面积普及的根本原因。

1.2 一次扫描能拿到什么：距离-速度二维矩阵

如果调制方式用的是锯齿波，也就是发射端反复发出线性上升的chirp信号，接收端每个chirp都会得到一个中频信号。对单个chirp内的采样点做一次FFT，得到的每个频点对应一个距离门，这叫快时间FFT，也叫距离FFT。连续发射N个chirp，对同一个距离门里的N个复数采样点再做一次FFT，就叫慢时间FFT，输出对应的是多普勒频率，也就是速度门。

两次FFT之后得到的是一个二维矩阵：横轴是距离，纵轴是速度，每个格子的能量代表该距离和该速度上是否有目标。不同雷达厂商对这个矩阵的叫法不太一样，TI的文档里叫Range-Doppler Map，简称RDM；有的SDK里叫Range-Doppler Heatmap。你在单片机上做测速，本质上就是维护并搜索这个矩阵。理解了这张二维地图，后面所有算法都顺了。

这里要特别提醒一点：距离FFT的输出一定是复数，不能只保留幅值。因为慢时间FFT需要用到同一个距离门上的相位信息。相位丢了，多普勒就没了。所以中间数据必须用 complex 类型存，这在单片机内存规划上是第一个要注意的地方。

2. FMCW测速的关键参数设计：先定参数，后面才不返工

2.1 距离分辨率由带宽决定，速度分辨率由帧时间决定

很多朋友拿到雷达模块，第一反应是找上位机把点云数据读出来，但真正自己写测速程序时，参数设计才是最容易被忽略的一步。chirp带宽、chirp周期、chirp数量、ADC采样率，这四个参数基本锁死了系统性能，后面改代码是救不回来的。

我把最核心的公式整理成下面这张表，做参数设计时直接对照它算。

距离分辨率这条最好理解：带宽越大，距离分辨率越高。24GHz频段在ISM应用里通常能拿到200到250MHz带宽，对应距离分辨率大约0.6到0.75米。77GHz车载雷达带宽更大，能做到更高分辨率。速度分辨率则取决于整个帧的时间长度，因为慢时间FFT的频率分辨力等于1除以总观测时间。N个chirp，每个chirp周期Tc，那总帧时间就是N·Tc，所以Δv = λ/(2·N·Tc)。

最大不模糊速度更关键。慢时间FFT的采样率等于1/Tc，根据奈奎斯特采样定理，能无模糊检测的多普勒频率上限是1/(2Tc)，换算成速度就是λ/(4Tc)。如果目标实际速度超过这个值，它的多普勒频率会折叠到低速区域，你会看到一辆明明开得很快的车，测出来却只有几km/h。这个问题在后面的代码实现里必须专门处理，不能只靠提高Tc来解决，因为Tc一变大，最大不模糊速度反而变小了，这是互相拉扯的两个指标。

2.2 一个24GHz模块做40米测速的设计实例

之前有个项目要用24GHz毫米波雷达模块给小车测速，指标是能测40米范围内的目标，径向速度范围要覆盖0到30m/s，也就是大约108km/h。这类需求在校园物流车、园区安防上非常典型。我们按上面的公式实际推一遍参数。

先定带宽B = 200MHz，那么距离分辨率就是：

ΔR = c/(2B) = 3×10^8 / (2×2×10^8) = 0.75米

这个分辨率在40米范围内够用，两个相距0.75米以上的目标能够从距离维分开。

再来定chirp周期Tc。Tc不能太长，否则最大不模糊速度不够；也不能太短，否则每个chirp里的采样点数太少，距离FFT效果差。我们取Tc = 100微秒，24GHz对应的波长λ约等于0.0125米，于是：

vmax = λ/(4Tc) = 0.0125 / (4×100×10^-6) = 31.25m/s

正好覆盖0到30m/s的需求，留了一点余量。接着取chirp数量N = 64，那么速度分辨率：

Δv = λ/(2·N·Tc) = 0.0125 / (2×64×100×10^-6) ≈ 0.98m/s

如果不做插值，两个速度相差1m/s以内的目标在速度维上很难区分。实际测速时我又加了一个抛物线插值，把速度峰值精度提升到0.2m/s左右。

ADC采样率也很好算。最大40米距离对应最大拍频：

f_IFmax = S × 2Rmax/c = (B/Tc) × 80/3×10^8 = 2×10^12 × 2.67×10^-7 ≈ 533kHz

模数转换器采样率至少要大于两倍的533kHz，也就是差不多1.07MHz。实际我选了2Msps，一个chirp内能采200个点，再做256点距离FFT。这套参数跑下来，一个帧的观测时间是64×100微秒 = 6.4毫秒，测速更新率能到150Hz，给小车控制用完全够。

3. 从天线到ADC：24GHz模块和单片机小车的硬件链路怎么搭

3.1 24GHz和77GHz到底怎么选

做测速项目，第一件事不是看算法，而是选频段。24GHz和77GHz是目前毫米波雷达最主流的两个频段，但它们的定位差距很大。

24GHz频段的好处是模块成本低，天线尺寸大，手工焊接和调试相对容易，很多国产模块还直接集成了MCU，串口输出目标的速度和距离。缺点是可用带宽有限，距离分辨率做不高，而且体积大，不适合对天线尺寸敏感的应用。77GHz频段的车载雷达已经非常成熟，4D毫米波雷达基本都是这个频段，带宽能做更大，距离分辨率能到几厘米级别，但射频前端和天线设计门槛高，很多模块要整板买，调试仪器也更贵。

如果你只是给单片机小车做40米以内的测速，或者做一个教学演示，24GHz的集成模块完全够用。但如果你要检测行人和车辆目标，并想把点云做得足够密，那还是老老实实用77GHz方案。我见过有人用24GHz模块做行人检测，距离分辨率0.75米，一个行人反射点本来就弱，再加多径干扰，结果就是虚警率居高不下。

3.2 天线通道数量对测速结果的影响

硬件上最容易忽略的是天线通道数。很多低端24GHz模块只有一发一收，也就是1T1R。这种配置只能测距离和速度，完全测不了角度。为什么？因为单根接收天线只能拿到目标的距离和速度信息，但目标从哪个方向来，需要多根天线之间接收信号的相位差来求解方向。

要做目标检测，至少需要1T2R，也就是一个发射天线加两个接收天线，这样可以通过两组回波的相位差解出方位角。这也是很多车规雷达入门配置是1T3R或2T4R的原因。通道数越多，雷达等效的虚拟孔径越大，角度分辨率也就越高。4D毫米波雷达之所以能测高度，本质上就是用了MIMO技术，通过多发多收形成更大的虚拟阵列，仰角维才被“撑”出来。

对纯测速来说，单通道也不是不能用。速度信息藏在相位变化里，一根天线就够了。但测速系统一旦遇到多目标，比如公路上同时有车和行人，单通道就没有足够信息去区分它们的角度位置，只能靠距离和速度两个维度去筛。实际做下来，1T2R是底线。

3.3 单片机端的数据通路和内存规划

毫米波雷达模块和单片机之间最常见的数据接口是SPI、LVDS和串口。24GHz模块很多已经把中频处理和FFT做在了内部，直接输出目标列表，这种对单片机最友好，MCU只需要做应用层逻辑。但如果你要自己写FFT算法，或者模块输出的只是ADC原始数据，那数据量就要仔细算了。

按前面2.2节那个例子，一个chirp有200个采样点，64个chirp就是12800个复数采样点。复数分I/Q两路，各占2字节，原始一帧就是12800×2×2 = 51.2KB。这个量级对STM32H7这类单片机来说还能承受，但对普通STM32F103就非常紧张。所以实际项目里我一般不会把全部原始数据都存下来，而是采用流式处理：每个chirp到达后立刻做距离FFT，只保留距离FFT谱，丢掉时域原始点。这样内存占用能从51.2KB降到256×64×2字节，也就是32KB左右，而很多单片机都能轻松容纳。

如果你在选单片机，建议关注三点：一是ADC采样率和位数，至少2Msps、12位以上；二是RAM大小，至少要有32KB以上给雷达数据用；三是浮点运算能力。带FPU的Cortex-M4和Cortex-M7跑FFT会快很多，否则就得把数据转成定点数，用Q格式运算，代码复杂度会上一个台阶。

4. 单片机上的C++测速代码：从原始数据到速度值的完整流程

4.1 距离FFT和多普勒FFT的数据组织方式

把原始ADC数据变成距离-多普勒矩阵，是测速算法的第一个关键步骤。很多教程里讲二维FFT，画起来很简单，但落到单片机上要特别注意数据搬移和内存复用。下面这段代码展示的是我常用的处理流程：先对每个chirp做距离FFT，再把距离谱按距离门重新组织，最后对每个距离门做多普勒FFT。

// 参数定义：每个chirp采样点数N_RANGE，chirp数量N_DOPPLER const int N_RANGE = 256; const int N_DOPPLER = 64; // 输入：rawData[chirpIndex][sampleIndex] // 输出：dopplerMap[rangeBin][dopplerBin]，幅度谱 // 第一步：每个chirp做距离FFT Complex rangeData[N_RANGE]; for (int chirpIdx = 0; chirpIdx < N_DOPPLER; chirpIdx++) { for (int i = 0; i < N_RANGE; i++) { rangeData[i].real = rawData[chirpIdx][i]; rangeData[i].imag = 0.0f; } applyWindow(rangeData, N_RANGE, HANNING); // 加窗，抑制距离维旁瓣 fft(rangeData, N_RANGE); // 基2 FFT，需要自己实现或移植 // 把距离FFT结果暂存到距离多普勒缓冲区 for (int rangeBin = 0; rangeBin < N_RANGE; rangeBin++) { rangeDopplerBuffer[rangeBin][chirpIdx] = rangeData[rangeBin]; } } // 第二步：对每个距离门做多普勒FFT Complex dopplerData[N_DOPPLER]; for (int rangeBin = 0; rangeBin < N_RANGE; rangeBin++) { for (int dopplerIdx = 0; dopplerIdx < N_DOPPLER; dopplerIdx++) { dopplerData[dopplerIdx] = rangeDopplerBuffer[rangeBin][dopplerIdx]; } applyWindow(dopplerData, N_DOPPLER, HANNING); fft(dopplerData, N_DOPPLER); // 计算幅度谱，存到dopplerMap for (int dopplerIdx = 0; dopplerIdx < N_DOPPLER; dopplerIdx++) { dopplerMap[rangeBin][dopplerIdx] = mag(dopplerData[dopplerIdx]); } }

这里有两个细节值得说。

第一是FFT输入顺序。雷达数据到达的顺序是chirp优先，也就是一个chirp的采样点连续存放，但第二步需要的是“同一个距离门、不同chirp”的数据，所以你必须做一次矩阵转置。这个转置在内存里必然导致反复读写，我在STM32上测试时发现，直接按内存顺序访问比随机访问快了将近一倍。如果有条件，可以把第一个循环和第二个循环的存储布局提前设计好，减少转置开销。

第二是加窗。距离FFT和多普勒FFT我都加了汉宁窗。每个chirp的时间有限，信号被截断，FFT一定会产生频谱泄漏。如果不加窗，强目标的旁瓣会把附近弱目标淹没。汉宁窗对测速场景足够，它把主瓣宽度略微展宽了一点，但换来的是旁瓣降低约30dB，这个代价非常值得。

4.2 从距离-多普勒矩阵里找目标：峰值搜索和CFAR门限

二维FFT做完，接下来就是从距离-多普勒矩阵中提取速度。最简单的方法是全局峰值搜索：把幅度谱里最大的点找出来，然后由它的距离门和多普勒门反算出距离和速度。但这只适合单目标、高信噪比的场景，一旦有两个目标，或者有异常噪声尖峰，直接取最大值就错了。

更可靠的做法是CFAR检测。CFAR全称恒虚警率检测，它的核心思想是给每个检测单元动态计算一个门限：被检测单元周围有一圈参考单元，根据参考单元的平均噪声水平乘一个系数，得到当前单元的门限。这样强目标旁边的弱目标不会被强目标旁瓣压掉，噪声高的区域和噪声低的区域也能用统一虚警率来检测。

CA-CFAR的实现逻辑并不复杂，关键是滑窗范围怎么取。距离维和多普勒维我一般各取6到8个保护单元和12到16个参考单元。保护单元紧挨着待检测单元，不进平均值，否则强目标会把自己的能量带入门限，导致检测不到相邻的目标。参考单元则代表周围的噪声背景。这个滑动窗口的尺寸没有统一标准，我建议用仿真数据或实测数据先扫一遍，把虚警率和漏检率调到一个可接受的平衡。

峰值搜索和CFAR可以先配合使用：先用CFAR找出所有超过门限的单元，再用局部峰值搜索确定每个目标的精确位置。这样既避免了全局最大值丢失弱目标，又不会把杂波边缘误判为目标。

4.3 速度解算、速度折叠和输出滤波

CFAR检测到目标单元后，由多普勒门的索引换算多普勒频率：

f_d = (dopplerBin - N_DOPPLER/2) / (N_DOPPLER × Tc)

注意，FFT输出通常把零频放在中间，所以负频率对应的是索引小于N/2的区域。多普勒频率换算成径向速度：

v = f_d × λ / 2

这里出来了实际测速值。但前面说过，速度有模糊问题。如果目标实际速度超过vmax，多普勒谱上会折叠到低速区。破解方法包括：使用两个不同的chirp周期Tc1和Tc2分别测速，再利用中国剩余定理解模糊；或者让chirp周期在帧间交替变化。此外还可以跟踪目标帧间的位置变化，用位置差分速度去解速度模糊，这是个笨但有效的办法，因为在连续跟踪场景下，距离变化量是连续可信的。

速度解算完之后，建议加一个滑动平均或者一阶低通滤波，因为单帧FFT受噪声影响会有抖动。我习惯用一阶IIR滤波器，系数取0.6到0.8之间的新帧权重，这样测速输出既平滑又不会滞后太多。千万别一开始就上卡尔曼滤波，很多场景一阶滤波已经够了，卡尔曼的调参成本明显更高。

在实际小车测速里还有个细节：当目标静止时，速度输出会不断在0附近跳变，看起来非常不稳定。这是因为强静止杂波和干扰导致第0个多普勒门有很高的能量，而旁边几个门也有泄漏。我一般会检测多普勒中心附近的能量，如果最大值和第0个多普勒门的距离小于两三个bin，就直接把速度置0。这个小技巧看着简单，但能让整个测速系统的观感提升非常多。

5. 实测中的标定与误差处理：安装角、栅瓣、多径这些坑

5.1 安装角度带来的速度比例误差

测速算法的前提是雷达波束方向与目标运动方向一致，但实际安装时几乎不可能完全做到。雷达测到的速度其实是目标实际速度在雷达视线方向上的投影，用公式表示就是：

v_radar = v_actual × cos(θ)

θ是目标运动方向与雷达视线方向的夹角。如果这个夹角是30度，那么实际速度100km/h的目标，雷达只能测到86.6km/h，误差超过13%。这是系统性的比例误差，不是随机噪声，靠滤波完全滤不掉。

处理办法有两种。第一种是机械标定，安装时用激光测距仪或水平仪把雷达波束方向校准到与运动方向一致。第二种是算法补偿，在标定阶段让已知速度的目标通过，反推出安装角θ，然后在测速公式里除以cos(θ)。第二种方法在现场更实用，但要注意θ会随目标位置变化，目标从雷达正前方偏离到侧面时，角度就变了。所以严格来说，固定一个补偿系数只能改善中心区域，真正要全覆盖，必须用测角功能先算出目标方位角，再做径向速度补偿。

这是我在公路测速项目里踩过最大的坑之一。刚装好时测出来的车速整体偏慢，一开始还以为是天线有问题，排查了很久才发现是安装支架有大约18度的偏转角。那台设备后来校正安装后，数据立刻恢复正常。所以大家拿到任何测速设备，都别急着相信出厂标定，先找一个速度可控的校准目标验证一遍。

5.2 天线栅瓣、旁瓣和距离维“鬼影”

雷达天线都有自己的方向图，存在主瓣和旁瓣。如果天线阵元间距过大，方向图上还会出现栅瓣。栅瓣的指向角度和主瓣不同，但增益接近，所以一条真实目标可能同时出现在两三个不同角度上。对纯测速来说，栅瓣不一定直接造成速度错报，但它会把能量分散，导致目标幅度降低，进入CFAR检测时可能漏检。

距离维的旁瓣则会在距离-多普勒图上造成“鬼影”。强目标旁边的旁瓣单元能量很高，一旦超过CFAR门限，就会被当成一个虚假目标。我在调24GHz模块时就遇到过这种情况：明明只有一辆车，距离维上却出现了两个相距1.5米的目标。后来查下来，问题出在两个地方，一是chirp带宽内的线性度不够好，导致距离维旁瓣偏高；二是没有加窗，旁瓣直接抬到了-13dB，比加了汉宁窗以后高得多。解决办法就是加窗，或者在CFAR门限里对旁瓣区域做额外的抑制。这也解释了为什么前面代码里我没有省略加窗步骤。

5.3 多径、静止杂波和雨雾天气的干扰

实测环境中，地面、护栏、桥墩和车辆侧面都会产生多径反射。最典型的现象是，近距离处出现一个拖尾的虚假目标，沿着距离维一直延伸。因为多径回波比直达波多走了一段路程，测出来的距离会偏大，而且它和真实目标的多普勒速度往往一致，所以在速度维上很难分辨。

对付多径，我用的方法是在距离维上做“最大值回溯”：当多个距离门在同一个多普勒频率上连续出现高能量时，只取能量最大的那一个作为真实目标，其余当作多径丢弃。这个方法简单，但在车辆侧翻、金属护栏密集的立交桥下，误删真实目标的情况也时有发生。更稳妥的做法是利用雷达的微多普勒特征，结合目标历史轨迹判断连续性，但这就已经超出基础测速范畴了。

雨雾天气对毫米波雷达的影响相对较小，但大雨时水膜会让近距离目标的回波发生衰减。另外来车大灯、对向车道的强雷达干扰也会在距离-多普勒图上产生随机尖峰。针对随机干扰，我在CFAR检测前加了一个简单的背景归一化：先把每一列多普勒门上的能量求均值，再用原始幅度除以均值。这个操作能明显压低均匀分布的干扰，而对局部目标影响很小。

6. 从“测速”扩展到“目标检测”：4D雷达、摄像头同步与融合

6.1 距离-速度-角度同时测量，才是真正的目标检测

纯测速只用了距离-多普勒图，它回答的是“这个距离上有没有目标以这个速度在运动”。但目标检测通常还要回答“目标在哪个方位、是不是真的车辆、会不会撞上”。这时候就需要角度维信息。

角度测量依赖多根接收天线之间的相位差。目标从不同方向回来，波程差不同，各天线的接收相位也就不同。对同一距离-速度单元的天线维数据再做一次FFT，就叫角度FFT。此时数据的维度变成距离-速度-角度三个维度，这就是常说的3D点云。基于FMCW的毫米波雷达测速，本质上是3D点云处理的第一步，速度维反而是最容易做的一维。

我在做摄像头与雷达融合时，速度信息是关联匹配的关键。摄像头能在像素平面上框出目标，但单目相机无法直接获得精确距离和速度；雷达能给出准确的距离、速度，却缺少纹理信息，无法判断目标是车还是人。用雷达的速度和距离去约束摄像头产生的检测框，能大幅减少误匹配。比如摄像头在一帧里检测到多个目标，我先把雷达点云映射到图像坐标系，再用速度一致性和距离一致性做最近邻匹配，准确率比纯IoU匹配高很多。

6.2 摄像头和毫米波雷达的时空同步

摄像头和雷达融合，绕不开“时空间步”四个字。时间同步的核心问题是两种传感器帧率不同，雷达一帧通常在10到50毫秒，摄像头一帧通常是20到40毫秒。如果直接用各自最新帧做匹配，最坏情况下会有半个帧周期的时间偏差，换算到高速运动目标上，位置误差可能达到数米。

工程上常用的做法是用硬件同步信号把两种传感器的采样时刻拉齐。雷达和摄像头分别接收PPS脉冲或帧同步信号，把曝光开始时间和chirp起始时刻对齐，这样每对数据的时间偏差能控制在毫秒级。如果没有硬件同步线，也可以通过插值法在软件里补偿：记录每帧雷达和图像的时间戳，把雷达点云插值到图像时间戳上。这个方法我用过，精度不如硬件同步，但对大多数非实时应用够用。

空间同步就是标定外参，把雷达坐标系和相机坐标系关联起来。最简单的标定方法是找一个棋盘格，同时在雷达和相机中检测，用一组对应点求解旋转和平移矩阵。但雷达点云对棋盘格这种弱反射目标并不友好，所以我一般用角反射器，也就是三个互相垂直的金属板组成三面角，在雷达图像中会产生明显亮斑。把角反射器摆在几十个不同位置，采集对应的雷达坐标和像素坐标，就能解出外参。注意：角反射器的尺寸要覆盖雷达波长，24GHz对应波长12.5mm，反射器边长做五到十倍波长就够了。

6.3 什么时候该升级到4D毫米波雷达

4D毫米波雷达是这两年的热门词，它多了“高度维”的输出，所以被称为4D，也就是距离、速度、水平角、俯仰角四个维度。传统毫米波雷达在处理立交桥、高架下目标时很容易把桥上目标和桥下目标混淆，因为只有一个水平角，无法区分目标是在路面上还是在桥面上。4D雷达通过MIMO虚拟孔径和俯仰维测角，能把这些不同高度的目标分开。

但4D雷达不是万能的。它的点云比传统雷达密得多，对后端的处理和存储要求随之暴增。一颗4D雷达的点云数据每秒可能达到几万个点，普通单片机已经很难实时处理，通常要上带GPU的域控制器。如果你的应用只是小车测速、防撞预警或液位计，2D雷达加基础测速算法就够了。升级到4D雷达，主要看两个指标：目标是否分布在不同高度层，以及系统是否有足够算力消化密集点云。

从我实际测试看，4D雷达对行人的检测改善最明显。行人高度低，回波体散射面积小，在传统雷达里经常和栏杆、路沿混在一起；4D雷达多了俯仰角后，同一个距离-速度单元上的人和栏杆能在高度维拉开，虚警率能降一半以上。如果你正在做的项目要在城市道路或者园区里做目标检测，而不是简单测速，那4D雷达值得重点关注。

我在几轮实测里的体会是：FMCW毫米波雷达测速的原理并不复杂，真正拉开差距的是参数设计、FPGA或单片机上的工程实现，以及实际安装环境里的标定和调试。这些环节没有哪一步能靠“调大某个参数”一劳永逸，每一版代码和每一套硬件都要按实际场景反复迭代。如果你打算从零搭建一套测速系统，建议先按第二部分的公式把整个参数表算一遍，再决定芯片型号和天线配置，最后才动手写FFT和CFAR。顺序反了，后面大概率要返工。