4. IFFT/FFT在OFDM中的实现：为什么用IFFT生成OFDM信号、FFT解调、IFFT/FFT的工程参数选择
好，咱们今天聊一个核心话题——IFFT/FFT在OFDM里到底怎么用。
说实话，我刚入行那会儿，看到OFDM的框图，第一反应是：“为什么发端要用IFFT？收端又用FFT？这不是反着来吗？” 后来自己动手搭了一个仿真链路，才真正明白——IFFT不是“逆变换”，而是“调制器”。这个认知转变，我觉得是理解OFDM的关键。
核心一句话：IFFT把频域数据“翻译”成时域波形发出去，FFT再把时域波形“翻译”回频域数据解出来。
4.1 为什么用IFFT生成OFDM信号？
咱们先想想OFDM的本质：多个子载波并行传输数据。每个子载波承载一个调制符号（比如QPSK、16QAM）。
传统做法是什么？每个子载波配一个振荡器，生成不同频率的正弦波，然后叠加。N个子载波就要N个振荡器——这显然不现实。
IFFT的出现，完美解决了这个问题。
我举个例子。假设你有4个子载波，频域数据是 [d0, d1, d2, d3]。你把这4个点送进4点IFFT，输出的4个时域样点 [s0, s1, s2, s3] 就是这4个子载波叠加后的波形采样值。
说白了，IFFT就是“多载波调制器”的数学实现。它把频域符号映射到时域，而且计算效率极高——N点IFFT只需要 O(N log N) 次复数乘法，而传统方法需要 O(N²)。
我个人习惯：在仿真时，我会先验证IFFT的“正交性”。具体做法是：把单位脉冲送进IFFT，观察输出波形是否对应单一子载波。如果波形干净，说明子载波间没有干扰。
4.2 为什么用FFT解调？
收端正好反过来。时域信号进来，我们要把每个子载波上的符号提取出来。
FFT就是“多载波解调器”。它把时域采样值变换回频域，每个频点对应一个子载波的符号。
我记得有一次调试一个OFDM接收机，发现解调出来的星座图总是旋转。排查了半天，发现是FFT的窗起始位置没对准——FFT的定时同步至关重要。如果起始点偏移，子载波间的正交性就会被破坏，产生ICI（子载波间干扰）。
避坑指南：我曾经在项目中遇到过FFT点数选错的问题。系统设计时用了1024点FFT，但实际信道带宽只支持600个子载波。结果剩下的424个频点全是噪声，严重拉低了信噪比。后来我养成了一个习惯：FFT点数一定要大于实际使用的子载波数，且留出保护频带。
4.3 IFFT/FFT的工程参数选择
这部分是实战中的硬骨头。参数选不好，系统性能直接打折。我总结几个关键参数：
4.3.1 FFT点数（N）
| 参数 | 影响 | 工程建议 |
|---|---|---|
| FFT点数N | 决定子载波总数和频率分辨率 | 通常取2的幂次（64、128、256、512、1024、2048） |
| 子载波间隔Δf | Δf = 采样率 / N | LTE常用15kHz，5G NR支持15/30/60kHz |
| 有效子载波数 | 实际承载数据的子载波数量 | 通常为N的60%~80%，留出保护频带 |
选N的时候，你想想看：N越大，频率分辨率越高，但OFDM符号周期也越长，对多普勒频移越敏感。LTE选1024点，5G NR选2048点，都是权衡后的结果。
4.3.2 循环前缀（CP）长度
CP是OFDM的“护身符”。它把IFFT输出的最后一段复制到开头，用来对抗多径时延。
- CP太短：多径时延超过CP长度，产生ISI（符号间干扰）
- CP太长：浪费频谱效率
我在做LTE基站接收机时，遇到过山区场景，多径时延长达5μs。标准CP（4.7μs）扛不住，必须用扩展CP（16.7μs）。嗯，这里要注意：扩展CP虽然抗多径好，但频谱效率降低了约7%。
4.3.3 窗函数与加窗
IFFT输出的时域信号，如果不加窗，频谱旁瓣会很高，造成带外泄漏。工程上常用升余弦窗或汉宁窗来平滑。
% 一个简单的加窗示例（MATLAB风格）
N = 1024; % FFT点数
alpha = 0.25; % 滚降因子
window = raised_cosine_window(N, alpha);
tx_signal = ifft(freq_data) .* window;
我建议：在工程实现中，加窗操作可以放在IFFT之后，也可以与CP结合。有些芯片厂商会把加窗和CP合并成一个操作，减少计算量。
4.4 知识体系图
下面这张图，我把IFFT/FFT在OFDM中的角色画出来了。你看一眼就明白：
4.5 实战中的几个坑
- IFFT/FFT的缩放因子：不同库的实现不一样。MATLAB的ifft默认除以N，而C语言的FFT库可能不除。收发两端必须统一，否则信号幅度会错。
- 定点化精度：FPGA实现时，IFFT内部乘法器的位宽要留够。我见过一个项目，因为位宽不够，导致EVM（误差矢量幅度）恶化了3dB。
- 流水线延迟：FFT IP核的延迟通常为N/2个时钟周期。在实时系统中，这个延迟会影响AGC（自动增益控制）的响应速度。
我曾经踩过的坑：有一次做5G NR的PUSCH解调，发现FFT输出总是有直流分量。查了三天，最后发现是ADC的直流偏置没校准。从那以后，我每次做OFDM接收机，第一件事就是检查直流分量是否为零。
好了，关于IFFT/FFT在OFDM中的实现，核心就是这些。你记住一句话：IFFT是发端的“画笔”，FFT是收端的“翻译官”。参数选对了，系统就成功了一半。