企业官网建设流程全解析

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

PLFM_RADAR 这个名字第一次出现在我视野里的时候，我正蹲在一堆雷达信号处理的资料里翻来覆去。PLFM 是 Pulse Linear Frequency Modulation 的缩写，也就是脉冲线性调频，说白了就是让发射出去的脉冲信号频率随时间线性变化，接收回来之后通过脉冲压缩把能量聚拢，从而在保证作用距离的同时拿到足够高的距离分辨率。这套机制在气象观测、无人机高度表、汽车防撞雷达、工业液位计里都能见到，属于雷达体制里非常经典也非常实用的一条技术路线。

我之所以决定动手做一套 PLFM_RADAR 的完整验证平台，是因为市面上大部分开源雷达项目要么只给仿真代码，要么只给一块孤零零的射频板，中间从波形生成、收发控制、数据采集到上位机成像的链路是断的。对于想真正搞懂雷达信号处理全流程的人来说，这种断裂非常致命——你调了半天 Python 脚本，却不知道实际硬件采回来的数据长什么样；你焊好了板子，却不知道怎么验证发射波形对不对。所以这个项目的核心目标很明确：用 FPGA 做实时信号生成与采集，用 STM32 做系统控制与接口管理，用 Python 做上位机数据处理与可视化，射频前端选用 ADAR1000 这类集成收发芯片，把整条链路串起来。

方案选型上我考虑过几种组合。纯 FPGA 方案当然性能最强，但开发周期长，调试阶段改一个参数就要重新综合布线，迭代太慢。纯 STM32 方案灵活，但 STM32 的定时器精度和并行处理能力在纳秒级脉冲控制上会吃力，尤其是需要同时产生多路严格同步的时序信号时，中断响应抖动会直接毁掉波形质量。所以最终采用 FPGA + STM32 的异构架构：FPGA 负责所有对时序敏感的高速逻辑，包括 DDS 波形生成、ADC 采样控制、DDR 数据缓存；STM32 负责系统状态机、人机交互、USB 数据传输和上位机通信。这样分工的好处是，FPGA 侧的逻辑一旦验证通过就非常稳定，STM32 侧则可以快速迭代控制逻辑，两边通过 SPI 或并行总线交换命令和状态。

Python 在这个项目里的角色不是“随便写个脚本看看图”，而是承担了完整的信号处理链：从原始 ADC 数据的读取、脉冲压缩、加窗、FFT、CFAR 检测，到最终的距离-多普勒图显示。我选择 Python 而不是 MATLAB，主要是因为 Python 的生态更开放，numpy 和 scipy 的运算速度对于离线处理完全够用，matplotlib 的出图质量也足够发表级别的展示。更重要的是，Python 可以很方便地和硬件通过串口或 USB 通信，形成闭环调试。

这个项目适合谁呢？如果你正在做雷达相关的毕业设计，或者想从通信、嵌入式方向转到雷达信号处理，又或者你手头有 FPGA 和 STM32 的开发板但不知道做什么项目能把两者结合起来，那这套 PLFM_RADAR 的架构会是一个非常好的练手载体。它涉及的知识点覆盖了数字信号处理、射频基础、FPGA 时序设计、嵌入式 C 编程和 Python 数据分析，基本上把电子工程的核心技能都串了一遍。

2. 核心细节解析与实操要点

2.1 脉冲线性调频信号的数学本质与参数计算

PLFM 信号的数学表达式看起来简单，但里面每一个参数都直接决定了雷达的性能边界。一个典型的线性调频脉冲可以写成：

import numpy as np def lfm_pulse(B, T, fs): """ B: 调频带宽 (Hz) T: 脉冲宽度 (s) fs: 采样率 (Hz) """ t = np.arange(0, T, 1/fs) k = B / T # 调频斜率 phase = np.pi * k * t**2 return np.exp(1j * phase)

这段代码里，B是带宽，T是脉宽，k = B/T是调频斜率。距离分辨率ΔR = c / (2B)，其中c是光速。假设我要做一套用于近距离探测的雷达，希望距离分辨率达到 0.5 米，那么需要的带宽就是B = c / (2 * 0.5) = 3e8 / 1 = 300 MHz。这个带宽在 X 波段（比如 10 GHz 附近）是完全可行的，ADAR1000 的工作频率范围覆盖了 8 GHz 到 16 GHz，所以带宽资源足够。

脉宽T的选择则要权衡作用距离和盲区。脉宽越大，发射能量越强，作用距离越远，但最小可分辨距离也越大。对于近距离应用，我通常选T = 10 us到50 us。假设T = 20 us，那么调频斜率k = 300e6 / 20e-6 = 1.5e13 Hz/s。这个斜率对 DDS 的相位累加器更新率提出了要求：FPGA 里的 DDS 时钟至少要在几百 MHz 量级，才能保证每个采样点的相位增量计算足够精确。

采样率fs的选择要满足奈奎斯特准则，对于 300 MHz 带宽，理论上fs ≥ 600 MHz。但实际中为了留余量，通常取fs = 1.2 * B到2 * B。我选的是fs = 800 MHz，这样每个脉冲的采样点数是T * fs = 20e-6 * 800e6 = 16000个点。这个数据量对 FPGA 的 Block RAM 来说有点大，所以需要外挂 DDR 来缓存。

注意：调频斜率的符号决定了后续脉冲压缩时匹配滤波器的共轭方向，如果符号搞反了，压缩后会得到散焦的结果，峰值幅度会大幅下降。我在第一次调试时就犯过这个错误，波形看起来完全正常，但压缩后信噪比只有理论值的一半，排查了很久才发现是k的符号在 FPGA 和 Python 里不一致。

2.2 FPGA 侧 DDS 波形生成的关键设计

FPGA 里生成 LFM 信号，最常用的方法是直接数字频率合成（DDS）。核心是一个相位累加器，每个时钟周期累加一个频率控制字，然后用累加器的值去查正弦表。对于 LFM，频率控制字本身是随时间线性变化的，所以需要第二个累加器来产生频率控制字的增量。

// 简化的 LFM DDS 核心逻辑 module lfm_dds ( input wire clk, input wire rst_n, input wire [31:0] freq_start, // 起始频率控制字 input wire [31:0] freq_step, // 每周期频率增量 input wire [15:0] pulse_len, // 脉冲长度（时钟周期数） output reg [13:0] dac_data ); reg [31:0] phase_acc; reg [31:0] freq_acc; reg [15:0] cnt; reg [13:0] sin_table [0:16383]; always @(posedge clk or negedge rst_n) begin if (!rst_n) begin phase_acc <= 0; freq_acc <= freq_start; cnt <= 0; end else if (cnt < pulse_len) begin freq_acc <= freq_acc + freq_step; phase_acc <= phase_acc + freq_acc[31:16]; cnt <= cnt + 1; end else begin phase_acc <= 0; freq_acc <= freq_start; cnt <= 0; end end always @(posedge clk) begin dac_data <= sin_table[phase_acc[31:18]]; end endmodule

这段代码里，freq_acc每个时钟周期增加freq_step，实现了频率的线性扫描。phase_acc则根据当前频率累加相位。正弦表用 16384 个点，地址取相位累加器的高 14 位。DAC 数据宽度 14 位，对应 ADAR1000 的基带输入要求。

这里有个关键点：freq_step的计算。假设 DDS 时钟是 200 MHz，脉冲宽度 20 us，那么脉冲持续20e-6 * 200e6 = 4000个时钟周期。带宽 300 MHz 对应频率控制字的变化范围是300e6 / 200e6 * 2^32 ≈ 6.44e9。所以freq_step = 6.44e9 / 4000 ≈ 1.61e6。这个值需要根据实际时钟频率和带宽需求重新计算，不能直接照搬。

实操心得：正弦表的量化位数直接影响输出信号的杂散水平。我用 14 位表长和 14 位数据宽度时，实测杂散在 -70 dBc 左右，对于大多数应用已经够用。如果要做高精度测量，建议把表长增加到 16 位，数据宽度保持 14 位，杂散可以改善到 -85 dBc 以下。但表长增加会消耗更多 Block RAM，需要权衡。

2.3 STM32 在系统中的角色与 USB 设备实现

STM32 在这个项目里不是打杂的，它承担了几个关键任务：系统上电时序控制、ADAR1000 的寄存器配置、FPGA 的复位与模式切换、以及通过 USB 把采集数据传给上位机。其中 USB 设备的实现是很多人的痛点，这里我详细说一下。

STM32 的 USB 外设支持全速（12 Mbps）和高速（480 Mbps，需要外接 PHY）两种模式。对于雷达数据回传，如果每帧数据量在几十 KB 量级，全速 USB 的 12 Mbps 理论带宽实际能跑到 8 Mbps 左右，传输一帧 64 KB 的数据需要约 65 ms，对于慢速成像够用，但要做实时显示就吃力了。所以我建议用 STM32F4 或 STM32F7 系列，它们自带高速 USB PHY，配合 DMA 可以实现接近 300 Mbps 的实际吞吐。

配置 USB 设备时，我选择的是 CDC 类（通信设备类），因为它不需要额外安装驱动，Windows 和 Linux 都能直接识别为串口。虽然 CDC 的理论带宽不如自定义类，但胜在通用性好，调试阶段非常方便。具体配置步骤：

1. 在 CubeMX 里使能 USB_OTG_FS 或 USB_OTG_HS，模式选 Device_Only。
2. 中间件里选 USB_DEVICE，类选 Communication Device Class。
3. 生成代码后，在usbd_cdc_if.c里实现CDC_Receive_FS回调，处理上位机发来的命令。
4. 发送数据用CDC_Transmit_FS，注意这个函数是非阻塞的，如果上一次传输还没完成就再次调用会返回 USBD_BUSY，需要加一个发送完成标志或者用环形缓冲区。

// USB CDC 发送环形缓冲区示例 #define TX_BUF_SIZE 8192 static uint8_t tx_buf[TX_BUF_SIZE]; static volatile uint32_t tx_head = 0, tx_tail = 0; void usb_send_data(uint8_t *data, uint32_t len) { for (uint32_t i = 0; i < len; i++) { uint32_t next = (tx_head + 1) % TX_BUF_SIZE; if (next != tx_tail) { tx_buf[tx_head] = data[i]; tx_head = next; } } // 在主循环里检查并发送 } void usb_tx_poll(void) { static uint8_t tmp[64]; if (tx_tail != tx_head) { uint32_t cnt = 0; while (tx_tail != tx_head && cnt < 64) { tmp[cnt++] = tx_buf[tx_tail]; tx_tail = (tx_tail + 1) % TX_BUF_SIZE; } CDC_Transmit_FS(tmp, cnt); } }

注意：STM32 的 USB 时钟必须精确配置为 48 MHz，否则枚举会失败。如果用的是外部晶振，CubeMX 会自动计算 PLL 参数，但有时候因为晶振精度不够，还是会出现枚举不稳定的情况。我遇到过一批 8 MHz 晶振实际频率偏差到 8.02 MHz，导致 USB 枚举时好时坏，换了晶振就解决了。所以晶振选型时尽量选 ±10 ppm 以内的。

2.4 ADAR1000 射频前端的配置要点

ADAR1000 是一颗 8 GHz 到 16 GHz 的四通道收发芯片，每个通道都有独立的增益和相位控制，非常适合做相控阵或者多通道雷达。它的配置通过 SPI 接口完成，STM32 可以直接驱动。配置流程大致是：上电复位、加载初始化寄存器序列、设置收发模式、调整增益和相位。

初始化序列一般从厂商提供的配置文件里生成，但有几个寄存器需要根据实际应用调整。比如0x010寄存器控制通道使能，0x011到0x014分别控制四个通道的增益，0x020到0x023控制发射增益。我一般会把接收增益设在中间值（比如 16 dB），然后根据实测信号幅度再微调。

SPI 时序方面，ADAR1000 最高支持 50 MHz 的 SCLK，但实际布线如果较长，建议降到 10 MHz 到 20 MHz 以保证可靠性。STM32 的 SPI 配置成 Mode 0（CPOL=0, CPHA=0），数据宽度 8 位，MSB First。每次配置一个寄存器需要发送 16 位：高 7 位是地址，第 8 位是读写标志，低 8 位是数据。

void adar1000_write_reg(uint8_t addr, uint8_t data) { uint8_t tx[2]; tx[0] = (addr << 1) | 0x00; // 写操作 tx[1] = data; HAL_GPIO_WritePin(CS_GPIO_Port, CS_Pin, GPIO_PIN_RESET); HAL_SPI_Transmit(&hspi1, tx, 2, 100); HAL_GPIO_WritePin(CS_GPIO_Port, CS_Pin, GPIO_PIN_SET); }

实操心得：ADAR1000 的 SPI 接口对时序比较敏感，尤其是 CS 拉低到第一个 SCLK 上升沿之间需要至少 10 ns 的建立时间。STM32 的硬件 SPI 在 CS 控制上如果用的是软件 GPIO，要确保在HAL_SPI_Transmit之前 CS 已经稳定拉低。我一开始用硬件 NSS 模式，发现 CS 和 SCLK 的相位关系不太对，后来改成软件控制 CS 就正常了。

3. 实操过程与核心环节实现

3.1 硬件平台搭建与上电时序

整套硬件由四块板子组成：FPGA 核心板（我用的 Xilinx Artix-7 系列）、STM32 控制板、ADAR1000 射频板和电源板。板间通过 FMC 连接器或者排针互连。上电时序非常关键，如果顺序不对，ADAR1000 可能会因为基带输入悬空而自激。

正确的上电顺序是：先给 FPGA 和 STM32 供 3.3V 数字电，等两者配置完成、IO 状态确定后，再给 ADAR1000 供 1.8V 和 3.3V 模拟电，最后打开射频电源。断电时反过来，先关射频，再关模拟，最后关数字。这个顺序我用一个简单的电源管理芯片配合 STM32 的 GPIO 控制使能脚来实现。

FPGA 的配置模式我选的是 Master SPI，配置文件存在板载的 QSPI Flash 里。上电后 FPGA 自动从 Flash 加载比特流，大约 200 ms 后完成初始化，拉高 DONE 信号。STM32 检测到 DONE 为高后，才开始配置 ADAR1000 和启动数据采集。

时钟方案上，我用了一颗 100 MHz 的差分晶振给 FPGA 提供系统时钟，FPGA 内部通过 MMCM 倍频到 200 MHz 作为 DDS 主时钟，再分频出 800 MHz 给 ADC 采样时钟（实际用的是 ADC 的 LVDS 接口，时钟由 FPGA 的 SelectIO 资源生成）。STM32 则用独立的 8 MHz 晶振，通过 PLL 倍频到 168 MHz 作为系统时钟，48 MHz 给 USB。

注意：FPGA 和 STM32 之间的通信如果用电平不匹配，比如 FPGA 的 Bank 电压是 1.8V 而 STM32 是 3.3V，直接连会烧 IO。我一般会在中间加一片电平转换芯片，或者把 FPGA 的 Bank 电压也设成 3.3V（如果该 Bank 的 IO 标准支持的话）。Artix-7 的 HR Bank 支持 3.3V，但 HP Bank 只支持到 1.8V，选引脚的时候要看清楚。

3.2 FPGA 逻辑设计与 DDR 数据缓存

FPGA 内部逻辑分为几个模块：DDS 波形生成、ADC 接口、DDR 控制器、SPI 从机（与 STM32 通信）和顶层状态机。DDR 缓存是这里面的难点，因为 ADC 采样率 800 MHz，数据位宽 14 位，持续采集 20 us 就是 16000 个点，需要至少 16000 × 14 bit ≈ 224 kbit 的存储深度。FPGA 内部的 Block RAM 总共也就几 Mbit，还要分给其他模块，所以必须用外挂 DDR。

DDR3 的控制器我直接用 Xilinx 的 MIG（Memory Interface Generator）生成，配置成 32 位数据宽度，时钟 400 MHz（DDR 双沿传输等效 800 Mbps）。MIG 会生成一个用户接口，包括命令、地址、写数据、读数据等信号。我写了一个简单的读写状态机：

// DDR 写控制状态机（简化） localparam IDLE = 0, WRITE = 1, WAIT = 2; reg [1:0] state; reg [27:0] addr; reg [31:0] wr_data; always @(posedge clk) begin case (state) IDLE: if (start_write) begin addr <= BASE_ADDR; state <= WRITE; end WRITE: if (wr_ready) begin wr_data <= {adc_data, 18'b0}; // 14位ADC数据左对齐到32位 addr <= addr + 4; if (addr >= BASE_ADDR + DATA_LEN) state <= WAIT; end WAIT: if (wr_done) state <= IDLE; endcase end

读的时候类似，从 DDR 里按顺序读出数据，通过 SPI 或者并行接口传给 STM32。这里有个带宽匹配的问题：DDR 的读写带宽远大于 SPI，所以如果 STM32 用 SPI 读数据，会成为瓶颈。我的做法是 FPGA 先把 DDR 里的数据搬到一个较小的 FIFO 里，STM32 再从 FIFO 里读，这样两边解耦，不会因为 STM32 处理慢而丢数据。

实操心得：MIG 生成的 DDR 控制器对时序约束要求很严，尤其是 PCB 走线长度匹配。如果自己画板子，DDR 的地址线和数据线要尽量等长，差分时钟对要包地处理。我第一版板子因为 DDR 走线没做好，跑到 300 MHz 就开始出错，后来降到 250 MHz 才稳定。所以如果对速度要求不是极致，可以适当降低 DDR 时钟，换取稳定性。

3.3 Python 上位机信号处理链

Python 这边的任务是把 STM32 传上来的原始 ADC 数据变成有物理意义的雷达图像。整个处理链包括：数据解析、脉冲压缩、加窗、FFT、CFAR 检测和显示。

数据解析部分，STM32 传上来的数据是二进制格式，每个采样点 16 位（高 14 位有效）。我用 numpy 的frombuffer直接解析：

import numpy as np import serial def read_radar_frame(ser, num_samples): raw = ser.read(num_samples * 2) # 每个点2字节 data = np.frombuffer(raw, dtype=np.uint16) data = (data >> 2).astype(np.float32) # 右移2位，取高14位 data = data - np.mean(data) # 去直流 return data

脉冲压缩是核心步骤。匹配滤波器的参考信号就是发射的 LFM 波形，在频域做共轭相乘再 IFFT 即可：

def pulse_compress(rx_data, ref_lfm): n = len(rx_data) + len(ref_lfm) - 1 nfft = 2 ** int(np.ceil(np.log2(n))) RX = np.fft.fft(rx_data, nfft) REF = np.fft.fft(ref_lfm, nfft) compressed = np.fft.ifft(RX * np.conj(REF)) return compressed[:len(rx_data)]

加窗是为了抑制距离旁瓣。常用的窗有汉明窗、汉宁窗、泰勒窗等。汉明窗可以把旁瓣压到 -42 dB 左右，但主瓣会展宽约 1.3 倍。如果对分辨率要求高，可以用泰勒窗，旁瓣 -30 dB 左右，主瓣展宽只有 1.1 倍。

window = np.hamming(len(ref_lfm)) ref_lfm_windowed = ref_lfm * window

CFAR 检测我用的是单元平均 CFAR（CA-CFAR），原理是滑动一个参考窗，计算窗内噪声的平均功率，然后乘以一个门限因子作为检测门限。门限因子由虚警概率决定：

def ca_cfar(signal, guard_cells, ref_cells, pfa): n = len(signal) threshold = np.zeros(n) alpha = ref_cells * (pfa ** (-1/ref_cells) - 1) for i in range(ref_cells + guard_cells, n - ref_cells - guard_cells): left = signal[i - guard_cells - ref_cells : i - guard_cells] right = signal[i + guard_cells + 1 : i + guard_cells + ref_cells + 1] noise = np.mean(np.concatenate([left, right])) threshold[i] = noise * alpha return threshold

注意：CFAR 的参考窗长度和保护单元数要根据实际目标尺寸来调。如果目标在距离维上占据多个单元，保护单元数要大于目标展宽，否则目标能量会泄漏到参考窗里，导致门限抬高、漏检。我一般设保护单元 4 个，参考单元 16 个，虚警概率 1e-6。

3.4 系统联调与闭环验证

联调阶段我采用“先内后外、先静后动”的策略。先把 FPGA 的 DDS 输出接到示波器上，确认波形频率和脉宽符合设计。然后用信号源模拟回波信号，注入 ADC，看 Python 端能不能正确压缩出峰值。最后才接上 ADAR1000 做实际收发。

闭环验证的一个关键手段是“环回测试”：把发射信号经过衰减器直接接到接收通道，不经过天线。这样接收到的就是发射信号的延迟副本，脉冲压缩后应该得到一个单一峰值，峰值位置对应延迟线的长度。我用不同长度的电缆做延迟，验证了距离测量的线性度，误差在 1% 以内。

另一个验证是“双目标测试”：用两个延迟线并联，模拟两个不同距离的目标。压缩后应该看到两个峰值，峰值的间隔对应距离差。这个测试可以验证距离分辨率是否达到理论值。我实测下来，300 MHz 带宽下两个相距 0.6 米的目标可以清晰分开，和理论值 0.5 米基本吻合。

4. 常见问题与排查技巧实录

4.1 FPGA 时序不收敛与亚稳态问题

FPGA 设计里最常见的问题就是时序不收敛，尤其是跨时钟域的信号。DDS 的 200 MHz 时钟和 ADC 的 800 MHz 时钟是两个完全不同的域，如果直接采样，必然出现亚稳态。我的做法是用异步 FIFO 做跨时钟域传输，写端用 ADC 时钟，读端用 DDS 时钟，FIFO 的深度至少 16 个元素，保证不会溢出。

另一个容易忽略的是复位信号的同步。FPGA 的全局复位如果直接来自外部引脚，释放时刻和时钟沿的关系不确定，可能导致状态机进入非法状态。正确做法是用两级触发器做同步释放：

reg [1:0] rst_sync; always @(posedge clk) begin rst_sync <= {rst_sync[0], ext_rst_n}; end wire rst_n = rst_sync[1];

排查技巧：如果时序报告里出现 setup violation，先看是不是跨时钟域路径没有加约束。在 Xilinx 的 XDC 文件里用set_clock_groups把异步时钟分组，工具就不会去分析它们之间的时序，但前提是你已经用同步器处理过了。如果 violation 出现在同频同相时钟之间，那多半是逻辑级数太深，需要插入流水线寄存器。

4.2 STM32 USB 枚举失败与数据丢包

USB 枚举失败通常有三个原因：时钟不准、描述符错误、供电不足。时钟问题前面说过了，这里说描述符。CDC 类的描述符包括设备描述符、配置描述符、接口描述符和端点描述符，任何一个字段错了都会导致枚举失败。我建议直接用 CubeMX 生成的默认描述符，只改 VID 和 PID，不要手动改其他字段。

数据丢包的问题更隐蔽。STM32 的 USB 发送如果不用 DMA，在高速传输时 CPU 会被中断频繁打断，导致主循环里的其他任务得不到执行。我的解决方案是：发送用 DMA，接收用中断加环形缓冲区。DMA 传输完成中断里置一个标志，主循环检测到标志后启动下一次传输。

void HAL_SPI_TxCpltCallback(SPI_HandleTypeDef *hspi) { if (hspi == &hspi1) { usb_tx_busy = 0; } }

实操心得：如果数据量很大，比如每帧 100 KB 以上，建议在 STM32 端做数据压缩或者抽取。比如只传 CFAR 检测后的峰值点，而不是原始 ADC 数据。这样可以把数据量降低两个数量级，USB 传输就轻松了。我在实际项目中就是 FPGA 先做一次粗检测，只把超过门限的点传给 STM32，STM32 再打包上传。

4.3 Python 处理速度慢与内存溢出

Python 做 FFT 如果数据量太大，会非常吃内存。比如 16000 个点的复数 FFT，numpy 的默认精度是 complex128，一个数组就是 256 KB，如果做多帧累积，很快就上 GB 了。解决办法是用np.complex64单精度，内存直接减半，速度也快不少。

RX = np.fft.fft(rx_data.astype(np.complex64), nfft)

另一个提速手段是用scipy.fft代替numpy.fft，scipy 的 FFT 实现通常更快，尤其是多线程版本scipy.fft.rfft对于实数输入可以省一半计算量。

如果还是慢，可以考虑用 numba 做 JIT 编译，把 CFAR 这种循环密集型的函数加速几十倍。不过 numba 对 numpy 的支持有限，有些写法会退化到 Python 解释执行，需要看文档。

排查技巧：用python -m cProfile跑一下你的处理脚本，看看时间花在哪个函数上。我一开始以为是 FFT 慢，profile 之后发现 80% 的时间花在 CFAR 的 Python 循环上，改成 numpy 向量化实现后，整体速度提升了 20 倍。

4.4 常见问题速查表

5. 性能优化与扩展方向

5.1 提升距离分辨率与作用距离的权衡

距离分辨率和作用距离是一对矛盾。分辨率靠带宽，作用距离靠能量。如果带宽从 300 MHz 提到 600 MHz，分辨率从 0.5 米提升到 0.25 米，但同样的脉宽下，调频斜率翻倍，DDS 的相位累加器精度要求也翻倍。而且带宽越大，ADC 采样率越高，数据量越大，DDR 和 USB 的压力都上去了。

我的经验是，先明确应用场景。如果是近距离高精度测量，比如液位计，带宽可以做到 1 GHz 以上，脉宽短一点没关系。如果是远距离探测，比如无人机高度表，带宽 100 MHz 到 200 MHz 就够了，重点是把发射功率做上去，脉宽做长，用脉冲压缩来补分辨率。

5.2 多通道扩展与相控阵雏形

ADAR1000 本身是四通道的，如果要用多片级联，可以做成 8 通道、16 通道的相控阵。每个通道的相位独立可调，通过控制相位差来实现波束扫描。这部分的难点在于通道间的幅相一致性校准。我一般会在出厂前做一次校准：用一个已知方向的信号源，测量各通道的幅度和相位，然后计算补偿系数，写入 STM32 的 Flash 里。

校准的数学原理很简单：假设第 i 个通道的复响应是A_i * exp(j * phi_i)，理想响应是A_0 * exp(j * phi_0)，那么补偿系数就是(A_0/A_i) * exp(j * (phi_0 - phi_i))。实际校准时，把补偿系数转成 ADAR1000 的增益和相位寄存器值即可。

5.3 实时处理与边缘计算

目前 Python 处理是离线的，如果要做实时显示，需要把部分处理放到 FPGA 里。比如脉冲压缩可以用 FPGA 的 DSP 资源做频域乘法，CFAR 可以用流水线结构实现。这样 FPGA 直接输出检测结果，STM32 只负责显示和上报，延迟可以做到毫秒级。

不过 FPGA 做信号处理的开发周期很长，我的建议是先用 Python 验证算法，确认无误后再移植到 FPGA。移植的时候注意数据位宽和定点化带来的精度损失，一般用 16 位定点数就够了，和浮点的差异在 0.1 dB 以内。

6. 个人实操体会与避坑建议

这个项目我从立项到跑通完整链路，前后花了大约三个月，其中大部分时间不是在写代码，而是在调试硬件和排查各种奇怪的现象。如果让我给后来者几条建议，我会说：

第一，不要一上来就追求高性能指标。先把最简单的单脉冲收发跑通，哪怕带宽只有 10 MHz，脉宽只有 1 us，只要能看到压缩峰值，就说明整条链路是通的。然后再逐步提高指标，每改一个参数就验证一次，这样出问题的时候容易定位。

第二，示波器和频谱仪是必备的。没有这两个工具，你根本不知道信号长什么样。我见过有人用 ADC 采回来的数据反推发射波形，结果因为接收链路饱和，看到的全是失真波形，白白浪费了一周时间。

第三，Python 脚本要模块化。把数据读取、脉冲压缩、CFAR、显示分成独立的函数，每个函数都可以单独测试。我一开始写了一个大脚本，改一个参数就要重跑整个流程，后来拆成模块后，调试效率至少提高了三倍。

第四，PCB 设计要留测试点。尤其是电源和关键信号，一定要引出测试点，方便用万用表和示波器测量。我第一版板子因为没留测试点，排查一个电源问题时不得不飞线，非常麻烦。

最后再分享一个小技巧：FPGA 的 ILA（集成逻辑分析仪）是调试利器，但会消耗大量 Block RAM。如果资源紧张，可以用一个简单的计数器加 FIFO 的方案，把关键信号存到 DDR 里，事后读出来分析。这样虽然不如 ILA 直观，但胜在资源占用小，适合长时间监测。