拿到“PLFM_RADAR”这个项目名，我第一反应是：这不是一个单纯的软件项目，也不是一台现成雷达设备，而是一个带“平台”属性的嵌入式雷达测控系统。PLFM 在嵌入式圈子里最常见的写法就是“Platform”，而 RADAR 指的就是雷达信号处理。两个词拼在一起，说明核心任务是在某种可编程平台上实现雷达数据的采集、处理、显示与交互。这个方向在工业测距、安防监控、智能交通、无人机避障里都很常见。
我在项目里做的是 24GHz LFMCW（线性调频连续波）雷达信号处理平台，硬件上用 FPGA 做数据采集和数字下变频，ARM 做算法运算和业务控制，上位机做实时显示和参数标定。整条链路从射频前端芯片的输出开始，一路处理到距离、速度、角度信息呈现在界面上。这篇文章把整个系统的设计思路、原理细节、工程实现和踩坑记录完整写出来，给正在做类似平台的同行一个可以直接参考的路线。
1. 系统整体设计与方案选型
1.1 为什么叫“PLFM_RADAR”，到底解决什么问题
平台型雷达项目和普通算法仿真最大的区别在于：你要面对的是真实硬件，不是回放一条离线数据。射频前端输出的模拟中频信号要先被 ADC 采集，采集后的数据要经过滤波、抽取、FFT 才能得到目标的差频信息，接着要做目标检测、参数解算、测量标定，最后通过显示界面或数据接口把结果交给用户。任何一个环节出问题，整个链路都跑不通。
所以 PLFM_RADAR 不是一个“雷达算法包”，而是一个软硬件结合的完整平台。它得同时具备数据采集能力、实时处理能力、交互控制能力。这就决定了方案选型时不能只盯着某一个环节的性能指标，而是要看整个系统的匹配度。选 FPGA 做前端处理还是纯 ARM 跑算法，选择什么接口和上位机通信，数据帧格式怎么定义，这些都要在设计初期就确定下来。
我当时的目标很明确：做一个可复用的雷达信号处理平台，既能跑通测距、测速、测角这些基础功能，又能留出扩展接口给后续的多目标跟踪、轨迹关联算法做验证。这意味着底层驱动、数据接口和算法模块都要解耦，不能把代码写死成“单一场景专用”。
1.2 硬件架构与数据流的走向
整个平台用一块板卡作为核心，板卡上集成了雷达前端、ADC、FPGA、ARM 和通信接口。雷达前端负责发射射频信号并接收回波，射频芯片输出的差频信号经过放大滤波后送到 ADC。ADC 的采样率不需要太高，因为差频信号的频率范围通常在几千赫兹到几百千赫兹之间，这样做能有效降低数据量和处理压力。
FPGA 在数据流里起“承上启下”的作用。它从 ADC 拿到原始采样数据后，先做数字下变频和抽取滤波，把中频信号搬到基带并降低采样率，再把处理后的 I/Q 数据通过总线送给 ARM。ARM 拿到的是干净的正交基带数据，跑 FFT、CFAR 检测、相位测速、角度解算这些算法时就轻松很多。
数据流大致是：天线 → 射频前端 → ADC → FPGA（DDC + 抽取） → ARM（FFT + 目标检测 + 参数解算） → 上位机显示。
为什么把算法放在 ARM 而不是全压在 FPGA？原因很简单：算法的迭代速度。用 FPGA 实现 FFT 和 CFAR 是能做，但每次调参都要重新综合布线，一次跑几分钟甚至几十分钟。放在 ARM 上，改个阈值改个窗函数，重新编译运行就是几秒钟的事。做平台型项目，开发效率往往比极限性能更关键。
2. 核心测距测速原理与工程实现细节
2.1 LFMCW 差频测距的数学底层逻辑
LFMCW 雷达发射的是频率线性变化的连续波，发射频率随时间呈锯齿波或三角波变化。回波信号经过目标反射后被接收天线捕获，因为传播延迟的关系，回波频率和发射频率在同一时刻存在一个差值，这个差值就叫差频。
如果目标是静止的，差频频率和目标的距离是线性关系。设扫频带宽为 B，扫频周期为 T，差频频率为 f_b，光速为 c，那么目标距离 R 的计算公式是：
R = f_b × c × T / (2 × B)
举一组实测参数：带宽 250MHz，扫频周期 5ms，差频频率 10kHz，距离就是 30 米。这个公式看着简单，但工程上有个特别容易踩的坑：如果目标距离很近，差频频率很低，直流偏置和 1/f 噪声就会把信号淹掉。所以射频前端必须有高通滤波环节，把直流和低频漂移去掉。我当时调试时发现近距离目标测不准，排查了一圈，最后就是被直流偏置坑的。
距离分辨率由带宽决定：δR = c / (2 × B)。带宽 250MHz 时分辨率是 0.6 米，想做到 0.1 米分辨率，带宽得拉到 1.5GHz。选型时要先定分辨率需求，再定射频芯片型号，顺序不能反。
2.2 速度测量：相位差比频率差灵敏得多
静止目标好测，运动目标就得多一步计算。因为运动目标的多普勒效应会叠加在差频上，导致测距时距离值混入速度因素。要同时解出距离和速度，常用的办法是发射两个不同斜率的调频段，或者用三角波调制，分别测出上扫频和下扫频的差频，再联立方程求解。
工程上更常用的是“帧间相位差测速”方法。对同一距离门的目标，比较相邻两帧回波信号在该距离门上的相位变化。设两帧之间的相位差为 Δφ，扫频周期为 T，雷达载波波长为 λ，目标径向速度为：
v = Δφ × λ / (4 × π × T)
实际调试时需要注意一个问题：相位差会缠绕在 [-π, π] 之间，当目标速度过快导致一帧内的相位变化超过 π 时，就会产生速度模糊，解算出来的速度方向和大小都是错的。解决方法是提高帧率，让帧间隔时间变短，但帧率提高会压缩每帧的采样点数，降低距离分辨率和处理增益，这里面得做一个平衡。
我项目里用的帧率是 100Hz，对应最大不模糊测速范围约 ±15m/s，对大多数室内和低速场景够用。如果你做的是车载场景，这个范围是不够的，需要想办法用多脉冲或多普勒处理来解模糊。
2.3 FFT 处理与目标检测的实操参数选择
ARM 端拿到基带 I/Q 数据后，第一件事是做加窗 FFT。为什么要加窗？因为雷达回波的 FFT 频谱有频谱泄漏，如果用矩形窗，目标的谱线会拖出长长的旁瓣，旁边的小目标响应就会被掩盖。我实际用的是汉宁窗，旁瓣衰减在 31dB 左右，主瓣展宽一点可以接受。
FFT 点数直接决定距离门的大小和频率分辨率。采样率 fs、FFT 点数 N、扫频周期 T 之间要满足 N / fs = T，这样一帧的数据正好做一次 FFT。距离门宽度对应频率分辨率 Δf = fs / N，再换算成距离就是：
ΔR_门 = Δf × c × T / (2 × B)
我当时的参数是采样率 10MHz，下变频后数据率降到 1.25MHz，每个扫频周期取 4096 点做 FFT，对应频率分辨率约 305Hz，折合距离门约 1.8 米。这里要注意，FFT 的频率分辨率和前面算的雷达距离分辨率是两个概念，系统的极限分辨率由带宽决定，但实际能分辨的最小距离间隔受 FFT 点数影响，点少了可能没法把两个理论可分辨的目标在频谱上分开。
目标检测可以先用固定门限跑通：把频谱幅度超过均值加 N 倍标准差的点判为目标。这套方案简单直观，但要小心强目标旁边的弱目标会被压制。要做得稳，推荐换成 CFAR（恒虚警检测），我常用 CA-CFAR 配上 12 个参考单元，左右各留 2 个保护单元，效果比固定门限耐用得多。
3. 数据链路设计、联调步骤与现场标定
3.1 板间数据接口定义：FPGA 与 ARM 的通信协议
FPGA 做完数字下变频后，输出的 I/Q 数据要送给 ARM。如果两边一拍脑袋各写各的，联调时就是灾难。我定义了一组简单可靠的总线协议：FPGA 作为主设备，ARM 作为从设备，用 AXI-Stream 接口配合 tlast 信号标记每帧结束。
帧格式包含帧头（2字节）、帧计数（2字节）、数据段（若干组 I/Q 数据，每组 4 字节）、CRC16 校验（2字节）。帧计数非常重要，连续丢帧时能立刻发现链路异常。CRC16 用常见的多项式 0x8005，代码量小，ARM 端开销完全可以忽略。
有个细节值得单独说：FPGA 和 ARM 之间的数据率如果超过总线带宽，就必须做降速处理。我一开始把抽取后的数据率定得太高，ARM 端 DMA 频繁中断，CPU 负载飙到 80%，算法帧率跑不满。后来把抽取倍数加大一倍，数据率降到原来的一半，中断频率立刻降下来，CPU 负载回到 20% 以下。这个参数据说大不大，但对整个系统的稳定性影响是决定性的。
3.2 上位机显示与交互：参数实时可调才叫平台
一个雷达平台如果没有可视化界面，开发调试的时候你会极度痛苦。我当时用 C# 写了一个简洁的上位机，界面分成几块：左边是频谱显示区，中间是距离-速度二维图，右边是目标列表和状态栏。
频谱显示区看起来是个“辅助窗口”，实际上它的作用比你想的大得多。调算法的时候，你必须能实时看到原始频谱长什么样，才能判断某个峰值到底是目标还是噪声毛刺。固定门限阈值、CFAR 保护单元个数这些参数，在上位机上直接能让用户改数值下发到设备，不用重新编译固件，这套交互流程是平台级别项目的必备能力。
上位机和 ARM 之间的通信协议也走帧格式，包含帧头、命令字、数据长度、数据和校验位。命令字单独定义一版，包括读设备状态、写参数、启动测量、停止测量、读取目标结果等。参数下发后 ARM 要回一帧 ACK，包含参数生效标志，上位机等 ACK 后才更新显示，避免界面显示值和设备实际值不一致。
3.3 现场静态标定的完整流程
雷达测距标定没有想象中那么复杂，但也不能跳过。标准做法是在空旷场地放置一个已知雷达散射截面的角反射器，放在多个已知距离点上，记录系统解算出的距离值，再做线性拟合补偿。
我当时选了 5 米、10 米、15 米、25 米 4 个点。角反射器是边长 30cm 的金属三角锥，面对雷达主轴方向放置。每个点停下来采 100 帧数据取平均，得到解算距离和真实距离的偏差表。
标定前先检查线性度。如果偏差随距离线性增长，说明是频率或时间基准的固定偏移；如果偏差是非线性的，比如近距离偏大、远距离偏小，那多半是射频端的幅相不一致没校准干净。我遇到过一种情况：同一距离下，解算距离会在不同日期出现 0.3 米左右的漂移，后来发现是环境温度影响了扫频斜率。解决方法是在设备启动时先跑一段自校准流程，用内部延迟线测出当前实际的扫频斜率和中心频率，再换算成补偿系数，效果立竿见影。
补偿公式可以写成：
R_true = a × R_raw + b
其中 a 是斜率补偿系数，b 是零点偏移补偿系数。标定点足够多时，用最小二乘法拟合出 a 和 b，把这两个参数存到 flash 里作为出厂参数。每次设备上电后自动加载，再配合温度传感器修正，系统稳定性会好很多。
4. 常见问题与现场排查记录
4.1 UART 收不到数据、偶发乱码这类“低级问题”
遇到设备连不上上位机、收不到数据的情况，新人很容易直接怀疑无线链路或者算法算错了。实际上，无线链路和算法大概率没问题，问题往往出在串口参数不一致或者共地处理不当上。
我排查这类问题的顺序很固定：第一步查协议配置，波特率、数据位、停止位、校验位必须和上位机完全一致，这一步别靠肉眼检查，用示波器或逻辑分析仪抓一下实际的波形最靠谱。第二步查电平，很多平台的串口是 3.3V 电平，如果连到 5V 电平的设备而没有做电平转换，时序会乱。第三步查共地，串口通信两端如果没有共地，信号参考电位不一致就会偶发乱码，尤其设备接开关电源供电时最容易出这种诡异问题。
我遇到过最隐蔽的一个问题：FPGA 和 ARM 的串口波特率都是 115200，但 FPGA 的时钟源用的 PLL 产生了 20ppm 的频偏，短帧通信没事，长帧传一半就错位了。后来把 FPGA 端波特率改成 114600 附近手动微调，数据链路立刻稳定。这类问题依赖代码调试根本看不出来，必须有逻辑分析仪辅助。
4.2 距离测量跳变、目标丢失与多径干扰
距离值在某一时刻突然跳变，是雷达调试里最常见的故障现象。排查思路是先区分干扰来源：看跳变时频谱上是不是同时出现了两个峰。
如果出现的第二个峰强度差不多，而且和目标峰保持一个固定间隔，通常是多径反射。地面反射是最大来源，雷达放在低处时，地面反射路径和直接路径的差值会在特定距离上产生叠加和抵消。解决方法是把雷达架高一点，或者使用带有抑制副瓣的天线。如果必须近距离探测，在信号处理里做目标形态学滤波，把相距很近的两个峰合并成单目标也能缓解。
目标丢失则经常和幅度波动有关。雷达散射截面本身存在起伏，目标运动时反射强度可能剧烈变化，CFAR 算法在目标信号落入噪声区域时会丢掉目标。我处理这个问题的手段是加时间维度的滑窗关联：连续 3 帧中至少有 2 帧检测到目标且距离变化不超过物理极限速度的门限，才确认目标存在并输出。这个机制能极大提升跟踪稳定性，代价是输出延迟增加一到两帧，对慢速场景完全可接受。
4.3 实测数据验证与算法有效性评估
系统跑通后，最重要的一步是用实测数据验证算法到底准不准。我在场地里做了三类测试：静态测距精度、匀速运动测速精度、多目标分辨能力。
静态测距精度测试：目标放在 10 米处，采集 500 帧解算结果，统计均值和标准差。正常情况均值误差应该小于 1 个距离门，标准差小于 0.2 米。如果标准差偏大，先看频谱峰值是否抖动，再查是不是 SNR 太低。SNR 低于 15dB 时测距抖动会明显增加。
匀速运动测速精度测试：用一个小车带着角反射器匀速直线运动，和平台解算的速度值对比。重点看速度方向是否稳定、有无跳变、平均误差是多少。我当时测试的结果是误差在 ±0.3m/s 以内，方向和真实运动方向一致。如果速度正负号经常跳变，检查目标是否落在零多普勒附近，此时相位变化非常微弱，测速结果对外界小幅扰动异常敏感，属于正常现象，不用修算法，过滤低速目标即可。
多目标分辨测试：放两个角反射器，间距从 3 米逐步拉近到 1 米以内，观察平台能否稳定输出两个独立目标。当间距接近一个距离门时，两个目标在频谱上会融合成一个宽峰，此时要么靠更宽的带宽提升理论分辨率，要么靠更高点数的 FFT 把频率网格细化。这里我要强调，FFT 点数增加并不能提升物理分辨率，只是让峰值定位更精细，两个真实目标靠得过于接近时仍然没法分开，这是原理限制，不是算法能解决的问题。
5. 调试工具清单与流程规范
5.1 逻辑分析仪和频谱仪是雷达调试的“眼睛”
做雷达平台开发，逻辑分析仪是必备工具。FPGA 与 ARM 之间的总线信号、串口时序、数据帧对齐，这些问题靠打印日志根本看不出来。逻辑分析仪采样率高、触发条件灵活，抓一遍就能确认时序是对的。
频谱仪用来检查射频前端的输出。调试初期我遇到过中频信号幅度明显偏低的问题，用万用表量不出来，频谱仪一测发现射频芯片的本振泄漏把动态范围吃掉了。另外，每次联调前先频谱仪看一眼输出频谱，确认载波和杂散没有异常再继续，能省下很多半夜排查的时间。
示波器也可以辅助看 ADC 输入的模拟波形，但真正实用的场景有限。差频信号是宽带、低幅值的信号，示波器分辨率不够，更多时候还是依赖数字域的表现。我的经验是：示波器用于电源上电时序检查，逻辑分析仪用于数字接口检查，频谱仪用于中频信号质量检查，三样各司其职，缺一不可。
5.2 版本管理与参数可追溯性
平台型项目迭代周期长，参数会反复调整。很多人会把参数写死在代码里，改来改去最后忘了当前设备里烧的是什么版本固件、哪一组参数，联调时出了问题根本回溯不回来。
我后来的做法是引入一套参数归档机制：设备端把当前参数版本号、生成时间、参数内容一起打包存储；上位机记录每次参数下发的操作日志；代码仓库里每个固件版本绑定一份参数文件。这样无论是现场调试还是问题回溯，都能快速定位到具体版本和参数组合。这个问题看着不起眼，但在多人协作或长时间跨度的项目里，价值会放大不少。
6. 项目扩展方向与我的体会
这套 PLFM_RADAR 平台做好了，往上叠加算法是很自然的事。多目标跟踪方面可以加卡尔曼滤波做航迹估计；多普勒处理受单帧相位差测速限制较大，可以改造为真正的慢时间维 FFT 测速；如果要测角度，得增加天线通道和干涉测角模块。平台接口在设计时留了这些口子：ADC 采样率可调、FFT 点数可调、数据输出帧率可调，底层驱动和上层算法解耦，加功能不需要动地基。
最后说点实在的体会。我做这个项目踩过最大的坑，不是算法推不出来，而是流程先于验证：一开始就埋头写 FFT 和 CFAR 代码，没先把数据链路打通，结果算法模块写完以后一接上去，发现数据时序是错的，所有算法结果全是垃圾。从那以后我换个做法：第一步先让 FPGA 输出已知的测试序列，ARM 端直接比对收到的数据对不对；第二步只做频谱显示，确认能看到静止金属板的尖峰；第三步才加测距算法；第四步才加测速和完整的界面交互。每个阶段的数据特征都验证扎实了再往前推进，同样是速测速、多目标识别这些最终功能，整体时间反而比“一步到位”少了一个星期。
如果你也在做类似的雷达处理平台，我的建议是：先把链路调到“闭着眼睛都能看懂”，再做任何高级算法；用固定的调试次序来推进项目，比凭着热情和直觉往前冲可靠得多。把细节抠扎实，这个问题就会变得很简单。
