GNURadio Companion单图OFDM收发模块运行异常求助

问题现象 #

• 单独运行ofdm_tx（64/512 FFT点数）完全正常，可观测到正常频谱
• 将收发模块整合到同一流程图后，仅能看到ofdm_tx的频谱，ofdm_rx无输出或显示直线波形
• 关闭输出频谱窗口时工具卡顿，单独运行ofdm_rx也会出现相同卡顿情况
• 控制台输出错误信息：

  packet_headerparser_b :info: Detected an invalid packet at item 1448.
  header_payload_demux :info :parser returned #f

排查与解决建议 #

1. 收发同步与参数匹配 #

• 强制使用统一时钟源：同一流程图内的收发模块必须共享同一个时钟，避免独立时钟导致的采样率偏移
• 严格对齐核心参数：确保ofdm_rx的FFT点数、循环前缀长度、调制方式与ofdm_tx完全一致，参数不匹配会直接导致帧头解析失败
• 校准频率同步：添加或调整Frequency Offset Correction模块，OFDM对微小频率偏移极度敏感，需确保接收端能跟踪发送端频率

2. 信号链路优化 #

• 检查信号幅度：收发直接连线时，可添加增益模块提升信号幅度，避免因信号过弱导致接收端无法检测有效符号
• 添加延迟补偿：在接收端路径中插入适当的延迟模块，确保接收端能捕获到完整的OFDM符号序列

3. 帧头解析配置调整 #

• 匹配头格式：检查packet_headerparser_b的头长度、校验算法配置，必须与发送端的头生成器参数完全一致
• 调整检测阈值：降低header_payload_demux的检测阈值，避免因微小噪声干扰导致帧头判定为无效

4. 频谱窗口卡顿处理 #

• 减少实时观测窗口：关闭不必要的频谱分析模块，仅保留核心观测窗口
• 降低频谱计算负载：下调频谱窗口的更新频率或FFT点数，减少实时计算对CPU的占用
• 清理系统资源：关闭后台占用CPU、内存的程序，确保GNURadio Companion有足够运行资源

内容的提问来源于stack exchange，提问作者user3743908