企业官网建设流程全解析

1. 项目缘起与整体设计思路

PLFM_RADAR 这个名字第一次出现在我视野里的时候，我正蹲在一堆相控阵天线测试数据里找问题。当时团队在做一个多通道收发验证平台，核心诉求很明确：要能同时驱动多路射频前端，完成相位控制、波束扫描、回波采集，还要把原始数据实时传回上位机做后续处理。找了一圈现成方案，要么太贵，要么太封闭，改不动底层。最后决定自己搭一套，这就是 PLFM_RADAR 的起点。

PLFM 是 Pulse Linear Frequency Modulation 的缩写，也就是脉冲线性调频。这个名字本身就点明了这套系统的信号体制——它发射的是脉冲式的线性调频信号，接收端通过匹配滤波或者去斜处理来获取目标的距离和速度信息。相控阵体制意味着天线不是机械转动的，而是通过控制每个阵元通道的相位来实现波束的电子扫描。这两者结合，就是 PLFM_RADAR 的核心技术底座。

这套系统能做什么？简单说，它可以完成从信号生成、功率放大、天线辐射、回波接收、下变频、ADC 采样到数字信号处理的全链路验证。适合谁参考？如果你正在做雷达相关的课题研究、毕设项目，或者想入门相控阵和 FPGA 信号处理，这套架构的思路和实现细节都能直接拿来用。它不是一个产品级的成品，而是一个验证平台，重点在于把原理跑通、把链路打通、把数据拿到手。

为什么选择 FPGA + STM32 这个组合？这是整个项目最核心的架构决策。FPGA 负责高速数据通路——ADC 采样、DDC（数字下变频）、脉冲压缩、FFT 这些运算量大、实时性要求高的活。STM32 负责系统控制——时序管理、人机交互、上位机通信、状态监控这些对实时性要求没那么苛刻但逻辑复杂的任务。两者分工明确，各干各擅长的事。如果全用 FPGA 做控制，开发效率低，改一个参数要重新综合布线，调试周期太长。如果全用 STM32 做信号处理，算力根本不够，采样率稍微高一点就卡死了。所以这个异构架构是经过权衡后的最优解。

在方案选型阶段，我重点考虑了以下几个维度：第一，ADC 的采样率和位宽要满足 LFM 信号的带宽需求，通常需要至少 2 倍于信号带宽的采样率；第二，FPGA 的 DSP 资源和 Block RAM 要能支撑多通道并行处理；第三，STM32 的外设接口要足够丰富，至少要有 USB、UART、SPI、CAN 这些常用接口；第四，整个系统的时钟同步方案要可靠，因为相控阵对通道间相位一致性要求极高。这些考量在后面每个模块的设计中都会具体展开。

2. 核心硬件架构与关键器件选型

2.1 射频前端与相控阵通道设计

相控阵的核心在于多通道的相位控制。PLFM_RADAR 设计的是 8 通道收发阵列，每个通道包含独立的 T/R 组件。T/R 组件内部集成了功率放大器、低噪声放大器、移相器和收发开关。移相器是关键器件，我选的是 6 位数字移相器，相位步进 5.625 度，这样波束扫描的精度可以控制在 1 度以内。为什么是 6 位而不是 4 位或 8 位？4 位步进 22.5 度太粗，波束指向误差大；8 位虽然精度高但成本翻倍，而且控制线太多，FPGA 的 IO 资源紧张。6 位是性价比和性能的平衡点。

每个通道的射频链路是这样的：发射时，LFM 信号从 DAC 输出，经过上变频到射频频率，再经过功放放大，最后通过天线辐射出去。接收时，天线收到的微弱回波先经过 LNA 放大，再下变频到中频，然后送 ADC 采样。这里有个关键细节：收发切换的时序必须严格控制，收发开关的切换时间要小于雷达的 minimum range 对应的时间。假设最小探测距离是 150 米，电磁波往返需要 1 微秒，那么收发切换必须在 1 微秒内完成，否则近距离目标的回波会被发射脉冲遮挡。

通道间的相位一致性是相控阵的命门。我在 PCB 布局时做了等长布线，每个通道的射频走线长度误差控制在 5 毫米以内，对应相位误差在 1 度左右（以 10GHz 为例，波长 30 毫米，5 毫米对应 60 度，这个误差太大了，所以实际上需要更严格的等长或者在后端做数字相位补偿）。实际做法是在每个通道的接收链路中加入可调衰减器和移相器，通过校准程序测量各通道的幅度和相位差异，然后在数字域做补偿。校准信号从发射通道耦合一部分到接收通道，形成一个闭环，FPGA 控制移相器扫描一圈，记录每个相位状态下的接收幅度，就能拟合出通道的初始相位。

2.2 FPGA 主控与高速数据通路

FPGA 选的是 Xilinx Artix-7 系列，具体型号 XC7A100T。为什么选这个？Artix-7 有 240 个 DSP48E1 切片，足够做 8 通道的复数乘法累加；Block RAM 有 4.8Mb，可以缓存多帧的 ADC 数据；最重要的是它支持 DDR3 接口，速率能到 800Mbps，满足高速数据缓存的需求。如果预算充足，Kintex-7 更好，但 Artix-7 对于这个规模的系统已经够用了。

ADC 选的是双通道 12 位 80MSPS 的芯片，每个通道负责 4 路接收信号的时分复用采样。80MSPS 的采样率对于 10MHz 带宽的 LFM 信号来说绰绰有余，过采样还能带来处理增益。ADC 和 FPGA 之间的接口是 LVDS，需要特别注意差分对的等长和阻抗匹配。我在 PCB 上把 LVDS 差分对的长度误差控制在 5mil 以内，差分阻抗控制在 100 欧姆。实测下来，如果等长没做好，采样数据会出现周期性误码，表现为频谱上出现杂散。

DDR3 的读写是 FPGA 部分的难点。PLFM_RADAR 需要缓存至少 1 秒的原始 ADC 数据，按 8 通道 80MSPS 12bit 计算，数据率是 8×80M×12bit = 7.68Gbps，1 秒就是 960MB。DDR3 的容量是 512MB，所以只能缓存半秒左右。为了高效利用 DDR3 带宽，我设计了一个多端口读写控制器，把 ADC 数据先写入 FIFO，然后由 DDR3 控制器仲裁后写入内存。读取时，信号处理模块通过另一个端口读取数据。这里的关键是仲裁策略，我采用的是优先级加轮询的方式：ADC 写入优先级最高，保证不丢数；信号处理读取次之；上位机读取优先级最低。实测下来，DDR3 的有效带宽利用率能到 70% 左右，满足系统需求。

2.3 STM32 控制单元与接口设计

STM32 选的是 STM32F407ZGT6，168MHz 主频，1MB Flash，192KB RAM。为什么不用 F103？F103 的算力和外设都不够用。F407 有 USB OTG HS、以太网 MAC、CAN、多个 SPI 和 UART，正好满足系统控制需求。STM32 在这里的角色是系统管家：上电后初始化各模块，配置 FPGA 的工作参数，管理收发时序，监控温度、电压、电流等状态量，通过 USB 或以太网上报给上位机。

STM32 和 FPGA 之间的通信接口用的是 FSMC（灵活静态存储控制器），把 FPGA 当作一个外部 SRAM 来访问。这样 STM32 可以像读写内存一样读写 FPGA 内部的寄存器，速度比 SPI 快得多。地址线用了 12 根，数据线 16 根，可以访问 4K 的寄存器空间。实际使用中，我把 FPGA 的寄存器分成了几个区：控制寄存器区、状态寄存器区、数据缓冲区。STM32 写控制寄存器启动一次采集，然后轮询状态寄存器等待完成，最后从数据缓冲区读取处理结果。

USB 设备的设计是另一个重点。STM32F407 的 USB OTG HS 支持高速模式，理论速率 480Mbps。我把它配置成 CDC 设备，虚拟成一个串口，上位机不需要装驱动就能识别。为什么用 CDC 而不是自定义 HID 或 Bulk？CDC 的兼容性最好，Windows、Linux、macOS 都能直接识别，开发调试最方便。在实现上，我用 ST 的 USB 库，配置成 Device 模式，端点 1 用于批量传输。实测下来，持续传输速率能到 20MB/s 左右，对于上报状态和少量数据足够了。如果要传原始 ADC 数据，还是得走以太网或者 FPGA 的 PCIe。

3. 信号处理链路与 FPGA 实现细节

3.1 LFM 信号生成与脉冲压缩原理

LFM 信号的数学表达式是 s(t) = rect(t/T) × exp(jπKt²)，其中 T 是脉冲宽度，K 是调频斜率，B = K×T 是信号带宽。PLFM_RADAR 用的参数是 T = 10μs，B = 10MHz，所以 K = 1MHz/μs。这个参数下，距离分辨率是 c/(2B) = 15 米，对于近程探测够用了。如果要提高分辨率，就得加大带宽，但 ADC 采样率和 FPGA 处理能力都要跟着涨。

脉冲压缩的本质是匹配滤波，在频域实现就是乘以匹配滤波器的频率响应，然后做 IFFT。匹配滤波器的频率响应是发射信号频谱的共轭。在 FPGA 里实现时，我先把发射的 LFM 信号做 FFT，取共轭后存到 ROM 里作为参考。接收信号做 FFT 后与参考频谱复数相乘，再做 IFFT，就得到了压缩后的脉冲。这个过程在 FPGA 里用流水线实现，每个时钟周期处理一个采样点。

具体实现时，FFT 用的是 Xilinx 的 FFT IP 核，配置成 1024 点、16 位数据宽度、流水线模式。为什么是 1024 点？因为 10MHz 带宽、10μs 脉宽，在 80MSPS 采样率下，一个脉冲有 800 个采样点，取 1024 点 FFT 正好覆盖。FFT 的输出是复数，实部和虚部各 16 位。复数乘法用 DSP48 实现，每个 DSP 做一个 16×16 的乘法，四个 DSP 组合完成一次复数乘法。1024 点需要 1024 次复数乘法，用 4 个 DSP 并行，256 个时钟周期完成。

脉冲压缩后的数据会出现在距离维上，每个距离单元对应一个采样点。目标的距离就是峰值所在的距离单元乘以距离分辨率。如果目标在移动，相邻脉冲的峰值位置会变化，通过多个脉冲的相位差可以测速。这就是 MTD（动目标检测）的基础。

3.2 数字下变频与多通道相位补偿

数字下变频（DDC）是把中频信号搬到基带的过程。ADC 采样得到的是实信号，经过数字混频后变成 I/Q 两路。混频的本振信号是 NCO（数控振荡器）产生的，频率等于中频频率。NCO 用相位累加器实现，相位累加器的位宽决定了频率分辨率。我用的是 32 位相位累加器，系统时钟 80MHz，频率分辨率是 80M/2³² ≈ 0.0186Hz，完全够用。

混频后的信号需要经过低通滤波，滤除混频产生的高频分量。低通滤波器用 FIR 实现，阶数 64，截止频率等于信号带宽的一半。FIR 滤波器在 FPGA 里用移位寄存器加乘法累加实现，64 阶需要 64 个乘法器。为了节省资源，我用了对称系数优化，实际只需要 32 个乘法器。滤波后的 I/Q 数据速率降低到 20MSPS，因为信号带宽只有 10MHz，根据奈奎斯特采样定理，20MSPS 足够了。这就是抽取滤波，抽取因子是 4。

多通道相位补偿是相控阵特有的环节。8 个通道的接收链路不可能完全一致，每个通道的初始相位和幅度都有差异。补偿的方法是在 DDC 之后，对每个通道的 I/Q 数据乘以一个复数补偿系数。这个系数是通过校准得到的。校准流程是这样的：在暗室或者微波暗室里，用一个标准信号源从远场发射单频信号，系统接收后测量各通道的 I/Q 值，计算出幅度比和相位差，然后取反得到补偿系数。补偿系数存在 FPGA 的 ROM 里，上电时加载到寄存器中。

实测中我发现，温度变化会导致相位漂移。夏天和冬天测出来的补偿系数能差 10 度以上。所以后来加了一个温度传感器，根据温度查表动态调整补偿系数。这个表是在温箱里标定的，每 10 度一个点，从 -40 度到 85 度，一共 13 个点。虽然麻烦，但效果很明显，波束指向的稳定性从 ±3 度提高到了 ±0.5 度。

3.3 波束形成与扫描控制逻辑

波束形成的原理是调整各通道的相位，使特定方向的回波同相叠加，其他方向的相互抵消。对于均匀线阵，相邻阵元的相位差是 Δφ = 2πd sinθ / λ，其中 d 是阵元间距，θ 是波束指向角，λ 是波长。PLFM_RADAR 的阵元间距是半波长，所以 Δφ = π sinθ。如果 θ = 30 度，Δφ = π/2，也就是 90 度。

在 FPGA 里实现波束形成，就是给每个通道的 I/Q 数据乘以对应的相位因子，然后求和。相位因子用 CORDIC 算法计算，输入是角度，输出是 sin 和 cos。CORDIC 是迭代算法，每次迭代做一次移位和加法，16 次迭代可以达到 16 位精度。8 个通道需要 8 个 CORDIC 核，每个核 16 级流水线，资源消耗可以接受。

波束扫描的控制逻辑在 STM32 里实现。STM32 根据上位机下发的扫描范围、步进、驻留时间，计算出每个波束指向对应的相位码，然后写入 FPGA 的相位控制寄存器。FPGA 在每个脉冲重复周期开始时读取相位码，更新各通道的移相器。扫描一圈 360 度，步进 1 度，需要 360 个脉冲重复周期。如果脉冲重复频率是 1kHz，扫描一圈需要 0.36 秒，对于大多数应用足够了。

这里有个时序细节要注意：移相器的切换需要时间，典型值是 100ns 到 1μs。如果在发射脉冲期间切换移相器，会导致波束畸变。所以切换必须在收发间隙完成。我在 FPGA 里设计了一个状态机，在发射结束后、接收开始前插入一个切换窗口，确保移相器稳定后再开始接收。这个窗口的时间根据移相器的规格设定，我用的移相器切换时间是 500ns，所以窗口设了 1μs 的余量。

4. 系统联调与实测问题排查

4.1 时钟同步与触发链路调试

相控阵系统对时钟同步的要求极高。PLFM_RADAR 的时钟方案是这样的：一个 100MHz 的温补晶振作为主时钟源，经过时钟分配芯片产生多路同源时钟，分别送给 FPGA、ADC、DAC 和 STM32。FPGA 内部用 MMCM 产生 80MHz 的采样时钟和 200MHz 的处理时钟。ADC 的采样时钟由 FPGA 提供，保证采样和处理的时钟同源。

触发链路是另一个关键。系统需要一个统一的触发信号来同步发射和接收。我用的是 FPGA 内部产生的触发脉冲，周期 1ms，脉宽 10μs。触发信号同时送给 DAC 和 ADC，DAC 在触发上升沿开始输出 LFM 波形，ADC 在触发下降沿开始采样。这样收发之间的延迟是固定的，可以在数据处理时补偿掉。

调试时遇到的第一个问题是 ADC 采样数据有周期性尖峰。用示波器看 ADC 的时钟输入，发现时钟上有过冲和振铃。原因是时钟走线的阻抗不匹配，末端没有端接。在时钟线末端加了一个 50 欧姆的端接电阻后，过冲消失了，采样数据也干净了。这个坑很典型，高速时钟线一定要做阻抗匹配和端接。

第二个问题是多通道之间的同步误差。用同一个信号源给所有通道输入相同的信号，采集后比较各通道的相位，发现通道 3 和通道 7 的相位比其他通道差了 15 度左右。检查 PCB 发现，这两个通道的射频走线比其他通道长了约 8 毫米。在 10GHz 下，8 毫米对应约 96 度的相位差，但实测只有 15 度，说明还有其他因素在补偿。后来在数字域对这两个通道做了额外的相位补偿，问题解决。这个案例说明，射频走线的等长设计非常重要，但即使不等长，也可以通过数字补偿来修正。

4.2 DDR3 读写稳定性优化

DDR3 的调试是 FPGA 部分最耗时的环节。最初的设计中，ADC 数据写入 DDR3 时偶尔会丢数，表现为频谱上出现随机的杂散。用 ChipScope 抓取 DDR3 的写使能和写数据，发现写使能有间断。原因是 DDR3 控制器的仲裁器在 ADC 写入和信号处理读取之间切换时，没有及时响应 ADC 的写请求。

解决方法是优化仲裁策略。我把 ADC 的写请求设为最高优先级，并且增加了写 FIFO 的深度，从 512 增加到 2048。这样即使仲裁器暂时忙不过来，FIFO 也能缓冲足够的数据，不会丢数。另外，我把 DDR3 的突发长度从 8 增加到 16，提高了单次传输的效率。优化后，连续采集 10 分钟没有出现丢数。

还有一个问题是 DDR3 的读写带宽不够。理论带宽是 800Mbps × 16bit = 12.8Gbps，但实测只有 5Gbps 左右。用 Vivado 的 DDR3 性能分析工具看，发现行激活和预充电的开销太大。原因是读写地址跳变太频繁，没有利用好 DDR3 的页命中特性。后来我把数据按页对齐，连续读写同一页内的数据，带宽提升到了 8Gbps 左右。这个经验说明，DDR3 的带宽优化不能只看理论值，要结合实际访问模式来调。

4.3 常见问题速查与避坑经验

在实际调试中，我整理了一份常见问题速查表，这里分享几个最有代表性的：

除了表格里的问题，还有几个避坑经验值得单独说。第一，FPGA 的复位信号一定要做同步处理，异步复位同步释放，否则容易出现亚稳态。我最初没注意这个，导致系统偶尔上电后不工作，后来加了复位同步器就再没出现过。第二，STM32 和 FPGA 的 FSMC 接口，地址线和数据线之间会有串扰，最好在 PCB 上拉开距离或者加地线隔离。第三，ADC 的模拟输入前端一定要加抗混叠滤波器，否则高频噪声会混叠到信号带内，影响信噪比。

5. 上位机交互与数据可视化

5.1 通信协议设计与数据帧格式

上位机和 STM32 之间的通信协议是我自己定义的，基于串口或者 USB CDC。协议格式很简单：帧头 2 字节（0xAA 0x55），帧长度 2 字节，命令字 1 字节，数据区 N 字节，校验和 1 字节。校验和用的是累加和取低 8 位，虽然简单但够用了。为什么不用 CRC？因为 STM32 的算力有限，累加和的计算速度快，而且在实际使用中没出现过校验错误。

数据帧分两种：控制帧和数据帧。控制帧是上位机下发的，用来设置工作模式、扫描参数、增益等。数据帧是 STM32 上报的，包含状态信息和处理后的目标信息。目标信息的格式是：距离 2 字节，速度 2 字节，幅度 2 字节，角度 2 字节，一共 8 字节一个目标。一帧最多上报 32 个目标，加上帧头帧尾，一帧最多 300 字节左右。在 20MB/s 的 USB 速率下，每秒可以传几万帧，完全够用。

如果要传原始 ADC 数据，协议就不一样了。原始数据量大，需要分包传输。我把原始数据分成 1024 字节的包，每包前面加 8 字节的包头，包含包序号和时间戳。上位机收到后按包序号重组。这种方式下，USB 的持续传输速率能到 15MB/s 左右，传 1 秒的 8 通道原始数据需要约 60 秒，有点慢。所以实际使用中，原始数据一般存在 DDR3 里，需要的时候再通过以太网批量导出。

5.2 上位机软件架构与实时显示

上位机软件我用的是 Python + PyQt5，为什么不用 C++？因为 Python 开发快，调试方便，而且 PyQt5 的绘图功能足够强大。软件架构分三层：通信层、处理层、显示层。通信层负责和 STM32 收发数据，用的是 pyserial 库。处理层负责解析数据帧、提取目标信息、做坐标转换。显示层用 PyQtGraph 实时绘制 PPI 显示和 A 显。

PPI 显示是雷达的经典显示方式，把目标的位置按极坐标画出来。我用 PyQtGraph 的 ScatterPlotItem 实现，每个目标一个点，点的亮度表示幅度。刷新率是 20Hz，也就是每 50ms 更新一次。实测下来，如果目标数量少于 100 个，刷新很流畅；超过 500 个目标时，界面会卡顿。优化方法是只绘制视野内的目标，视野外的目标不画。这样即使有几千个目标，界面也能保持流畅。

A 显是距离-幅度显示，把每个距离单元的幅度画成曲线。这个用 PlotDataItem 实现，X 轴是距离，Y 轴是幅度。A 显的刷新率可以更高，50Hz 都没问题。在实际使用中，A 显用来观察信号质量，PPI 用来观察目标分布，两个配合使用很方便。

5.3 数据记录与回放功能实现

数据记录功能是调试和事后分析的关键。我在上位机里加了一个记录按钮，点击后把收到的所有数据帧写入文件。文件格式是二进制，每帧前面加 8 字节的时间戳。记录的文件可以用回放功能重新加载，模拟实时数据流，方便反复分析。这个功能在调试信号处理算法时特别有用，因为实际场景很难复现，但录下来的数据可以反复回放。

回放功能的实现很简单：打开文件，按时间戳的顺序读取数据帧，然后像收到实时数据一样送给处理层。可以设置回放速度，1 倍速就是按原始时间间隔发送，10 倍速就是快速回放。我一般用 1 倍速来观察实时性，用 10 倍速来快速浏览长时间的数据。

数据文件的体积是个问题。1 小时的数据大约 1GB，如果记录原始 ADC 数据，1 小时能到 100GB。所以实际使用中，我只记录处理后的目标信息，原始数据只在需要时记录短时间。另外，我加了一个自动清理功能，超过 30 天的文件自动删除，避免硬盘被撑满。

6. 系统扩展与后续优化方向

6.1 从 8 通道扩展到 16 通道的可行性分析

8 通道的相控阵，波束宽度大约是 12 度（对于半波长间距的均匀线阵，波束宽度约 102/8 = 12.75 度）。如果要提高角度分辨率，就得增加通道数。16 通道能把波束宽度压缩到 6 度左右，分辨率翻倍。但扩展不是简单地把通道数翻倍，有几个瓶颈要解决。

首先是 FPGA 的资源。8 通道时，DSP 切片用了约 60%，Block RAM 用了 50%。16 通道时，如果还是同样的处理架构，DSP 和 RAM 都不够用。解决方案有两个：一是换更大的 FPGA，比如 Kintex-7 或者 Zynq UltraScale+；二是优化处理架构，比如用时分复用的方式，让多个通道共享 DSP 资源。时分复用会降低处理速度，但如果脉冲重复频率不高，还是可行的。

其次是数据带宽。16 通道 80MSPS 12bit 的数据率是 15.36Gbps，DDR3 的带宽不够了。需要换成 DDR4 或者用多片 DDR3 并行。另外，STM32 和 FPGA 之间的 FSMC 带宽也不够，需要换成 PCIe 或者千兆以太网。这些改动都比较大，不是简单堆通道就能解决的。

最后是功耗和散热。16 通道的射频前端功耗大约是 8 通道的两倍，如果还是同样的散热设计，温度会超标。需要加大散热片或者加风扇。我在 8 通道系统上实测，满功率工作时功放温度能到 70 度，16 通道的话估计要 90 度以上，必须加强散热。

6.2 基于 Zynq 的软硬协同优化思路

Zynq 系列把 ARM 和 FPGA 集成在一颗芯片里，对于 PLFM_RADAR 这种需要软硬协同的系统来说，是天然的升级方向。用 Zynq 的话，STM32 的角色可以由 Zynq 的 ARM 核来承担，FPGA 部分不变。这样好处很多：ARM 和 FPGA 之间的通信走 AXI 总线，带宽比 FSMC 高得多；省掉了 STM32 芯片，PCB 面积和功耗都降低；ARM 上可以跑 Linux，开发上位机软件更方便。

但 Zynq 的开发难度比 STM32 + FPGA 高。首先是启动流程复杂，需要配置 FSBL、设备树、内核。其次是 AXI 总线的调试比 FSMC 麻烦，需要用到 Vivado 的 ILA 和 SDK 的调试器。我试过用 Zynq 做一个小项目，光是把 Linux 跑起来就花了两天。所以如果团队没有 Zynq 经验，升级到 Zynq 的学习成本不低。

从性能角度看，Zynq 的优势很明显。AXI 总线的带宽能到几 Gbps，比 FSMC 的几百 Mbps 高一个数量级。ARM 核的主频能到 1GHz 以上，比 STM32 的 168MHz 快得多。如果要做复杂的信号处理算法，比如自适应波束形成，Zynq 的算力优势就体现出来了。但如果是简单的控制任务，STM32 其实够用了，没必要为了升级而升级。

6.3 实测性能总结与改进建议

PLFM_RADAR 目前的实测性能是这样的：最大探测距离 3 公里（对 1 平方米 RCS 的目标），距离分辨率 15 米，角度分辨率 12 度，扫描速度 360 度/秒，数据率 20MB/s。这个性能对于近程警戒、区域监视、无人机探测等应用是够用的。但如果要探测更小的目标或者更远的距离，就需要提高发射功率、加大天线增益、降低接收噪声。

改进的方向有几个：第一，提高发射功率。目前功放的输出是 10W，如果换成 50W，探测距离能增加一倍多。但功耗和散热问题要解决。第二，增加脉冲积累数。目前是 64 个脉冲积累，如果增加到 256 个，信噪比能提高 6dB，等效探测距离增加 40%。但数据率和处理时间都会增加。第三，优化波形设计。目前用的是固定参数的 LFM，如果换成相位编码或者频率捷变，抗干扰能力会更强。

从工程实现的角度，我建议后来者注意几点：第一，PCB 设计一定要找有射频经验的人做，高速数字和射频混合的板子很容易出问题。第二，FPGA 的时序约束要写全，不要依赖工具自动推断，否则综合出来的电路可能不稳定。第三，系统联调要分模块进行，先调通 ADC 和 DAC，再调 DDR3，再调信号处理，最后联调。不要一上来就全系统跑，出了问题很难定位。第四，多准备一些测试点，用示波器和逻辑分析仪抓波形，比看代码猜问题快得多。

这个项目从立项到跑通花了大约 6 个月，其中硬件设计 2 个月，FPGA 开发 2 个月，STM32 和上位机 1 个月，联调 1 个月。踩过的坑不少，但收获也很大。最大的体会是，相控阵雷达的门槛不在单个模块，而在系统集成。每个模块单独测都正常，连在一起就可能出问题。时钟、电源、地线、屏蔽，任何一个细节没做好，都可能导致系统性能下降。所以做这类项目，耐心和细致比技术能力更重要。