一、雷达工作原理：从发射到接收的完整链路
雷达这东西，说白了就是「先喊一嗓子，再听回声」。我在军工所那会儿，带我的老工程师总爱说这句话。嗯，道理确实简单，但实现起来门道可不少。
雷达发射电磁波，打到目标后反射回来。我们通过测量发射和接收的时间差，就能算出目标距离。这就是最基础的脉冲雷达原理。
核心公式：R = c × Δt / 2
其中 R 是目标距离，c 是光速（3×10⁸ m/s），Δt 是发射到接收的时间差。
你想想看，如果目标在 15 公里外，电磁波来回就是 30 公里。光速跑完这段距离需要 100 微秒。嗯，100 微秒，这就是我们嵌入式系统要处理的时基。
除了距离，雷达还能测速度和角度。测速靠多普勒效应——目标靠近时回波频率变高，远离时变低。测角度则靠天线波束指向，或者更高级的相控阵技术。
我记得第一次调试某型火控雷达时，目标明明在正前方，显示出来的角度却偏了 3 度。查了两天才发现，是天线相位中心标定出了问题。从那以后，我养成了一个习惯：任何角度测量前，先做一次系统标定。
二、雷达信号处理流程：从模拟到数字的蜕变
现代雷达信号处理，本质上是个「从噪声里扒信号」的过程。我把它拆成几个关键步骤，你跟着走一遍就明白了。
2.1 接收与下变频
天线收到的信号是 GHz 级别的射频信号。嵌入式系统处理不了这么高的频率，得先下变频到中频，再通过 ADC 采样变成数字信号。
实战经验：ADC 的采样率选择很讲究。根据奈奎斯特定理，采样率至少是信号带宽的两倍。但我建议你留 20% 的余量。我曾经为了省成本，卡着 2 倍带宽选采样率，结果带外噪声混叠进来，脉冲压缩后的旁瓣高得离谱。
2.2 脉冲压缩
发射信号通常是线性调频信号（LFM），带宽大、脉宽长。脉冲压缩就是通过匹配滤波，把长脉冲「压」成短脉冲，从而获得高距离分辨率。
数学上，脉冲压缩就是做卷积。但在嵌入式系统里，我们通常用 FFT 实现快速卷积。流程是这样的：
// 快速卷积实现脉冲压缩
// 输入：回波信号 x[n]，匹配滤波器系数 h[n]
// 输出：压缩后的信号 y[n]
1. 对 x[n] 做 N 点 FFT → X[k]
2. 对 h[n] 做 N 点 FFT → H[k]
3. 频域相乘：Y[k] = X[k] * conj(H[k])
4. 对 Y[k] 做 IFFT → y[n]这里有个坑：FFT 点数 N 必须大于等于 x[n] 和 h[n] 的长度之和减 1，否则会发生循环卷积混叠。我曾经在这个问题上栽过跟头，调试了整整一个通宵。
2.3 动目标检测（MTD）
脉冲压缩之后，我们得到的是距离-脉冲二维数据。MTD 就是在慢时间维（脉冲维）上做 FFT，把多普勒频率提取出来。
说白了，MTD 就是「沿着脉冲方向再做一次 FFT」。这样每个距离单元都能得到一张多普勒谱，目标的速度信息就出来了。
| 处理阶段 | 数据维度 | 典型计算量 |
|---|---|---|
| 脉冲压缩 | 距离维 FFT | N×log₂(N) 复数乘法 |
| MTD | 脉冲维 FFT | M×log₂(M) 复数乘法 |
| CFAR检测 | 二维滑窗 | O(N×M) 比较运算 |
N 是距离单元数，M 是相参积累脉冲数。我见过很多新手把这两个维度搞混，结果程序跑出来的数据全是乱的。
2.4 恒虚警检测（CFAR）
CFAR 的作用是自适应地设置检测门限。背景噪声强的地方门限抬高，噪声弱的地方门限降低，从而保持恒定的虚警概率。
常用的有 CA-CFAR（单元平均）和 OS-CFAR（有序统计）。我个人偏爱 OS-CFAR，因为它对多目标环境更鲁棒。有一次在强杂波环境下测试，CA-CFAR 虚警率飙到了 30%，换成 OS-CFAR 后直接降到了 1% 以下。
注意：CFAR 的保护单元数量要仔细选择。保护单元太少，目标能量会泄漏到参考窗里，导致检测门限被抬高，弱目标就漏掉了。保护单元太多，又会浪费计算资源。一般取目标尺寸的 1.5 倍左右比较合适。
三、嵌入式系统在雷达中的应用：为什么非它不可
你可能要问：雷达信号处理为什么非得用嵌入式系统？用 PC 或者服务器不行吗？
答案是：实时性。雷达是实时系统，从天线接收到信号到输出目标点迹，延迟必须控制在毫秒级。PC 的操作系统调度延迟不可控，而嵌入式系统可以做到硬实时。
3.1 嵌入式系统的典型架构
我参与过的雷达项目，嵌入式处理平台通常是这样的：
- 前端：FPGA 做高速数据采集和预处理（DDC、脉冲压缩）
- 中端：DSP 做 MTD、CFAR 等算法处理
- 后端：ARM 做目标跟踪、数据融合和通信
这种「FPGA + DSP + ARM」的异构架构，在雷达领域已经用了十几年。FPGA 负责吞吐量大的流水线处理，DSP 负责复杂的数学运算，ARM 负责控制和管理。
3.2 实时性要求有多苛刻？
拿脉冲多普勒雷达来说，脉冲重复频率（PRF）通常是几千赫兹。每个脉冲重复周期内，必须完成：
- ADC 数据采集（几微秒）
- 数字下变频（几十微秒）
- 脉冲压缩（几百微秒）
- MTD 更新（取决于积累脉冲数）
整个处理链必须在下一个脉冲到来之前完成。否则就会出现数据覆盖，这在雷达领域叫「距离模糊」。我见过一个项目，因为 FPGA 的流水线没设计好，导致每 10 个脉冲就丢一个，目标航迹断断续续的。
3.3 嵌入式优化的核心思路
做雷达信号处理的嵌入式优化，说白了就是跟时间和资源赛跑。我总结了几条原则：
- 计算换存储：能查表就不计算。比如三角函数、窗函数，提前算好存起来
- 定点化：浮点运算慢，能转定点就转定点。但要注意动态范围，我吃过亏
- 流水线：让 FPGA 的每个时钟周期都在干活，别闲着
- 乒乓缓冲：用双缓冲避免数据搬移和处理的等待
我的习惯：每次做优化之前，先画一张数据流图。把每个处理节点的输入输出、延迟、吞吐量都标清楚。这样哪里是瓶颈，一眼就能看出来。比对着代码瞎调效率高多了。
四、本章小结
这一章我们聊了雷达的工作原理、信号处理的基本流程，以及嵌入式系统为什么是雷达信号处理的最佳选择。你可能会觉得内容有点多，但这些都是后续章节的基础。
下一章，我们会深入 FPGA 的优化细节。到时候我会拿一个真实的脉冲压缩案例，手把手带你做优化。嗯，那个案例里有个坑，我当年踩得特别惨，到时候跟你好好讲讲。
记住一句话：雷达信号处理，七分算法，三分优化。算法搞明白了，优化才有方向。否则就是在错误的方向上越跑越远。
课后思考：如果让你在 FPGA 上实现 1024 点的 FFT，你会怎么设计流水线？考虑一下资源占用和吞吐量的平衡。