修改方法：减小发送端的乘数因子。
但是本着知其然还要知其所以然的学习态度，下面就解释下出现这种现象的原因：
2021.10.28 更新：
在实际的测试中发现，引起该问题的原因还有可能是接收信号解调失败，导致头信息（header_data）解析失败，进而无法知道帧长度等信息。这时就要考虑信道环境、解调算法等因素的影响了。
最近在尝试运行并修改 GNU Radio 中的 OFDM 例程，先尝试做一个文本传输的demo。
（位置 gnuradio/gr-digital/examples/ofdm）。
首先将官方例程 ofdm_tx 中的 OFDM_Receiver 用 UHD:USRP Sink 来替代。将 ofdm_rx 中的 OFDM_Transmitter 用 UHD:USRP Source 来替代。并修改数据来源为一个 txt 文件。USRP一些参数设置如下：
由于是在做水声通信的测试前准备，因此频率都为khz级别的，这时就无法使用天线进行传输，所以使用SMA线直连的方式进行测试。使用两台 X310+LFTX/LFRX 来做测试。刚开始，发射端数据发送一切正常，但是在接收端却出现了以下错误信息：
gr::log :INFO: packet_headerparser_b0 - Detected an invalid packet at item 0
gr::log :INFO: header_payload_demux0 - Parser returned #f
gr::log :INFO: packet_headerparser_b0 - Detected an invalid packet at item 48
gr::log :INFO: header_payload_demux0 - Parser returned #f
gr::log :INFO: packet_headerparser_b0 - Detected an invalid packet at item 96
gr::log :INFO: header_payload_demux0 - Parser returned #f
gr::log :INFO: packet_headerparser_b0 - Detected an invalid packet at item 144
gr::log :INFO: header_payload_demux0 - Parser returned #f
gr::log :INFO: packet_headerparser_b0 - Detected an invalid packet at item 192
gr::log :INFO: header_payload_demux0 - Parser returned #f
gr::log :INFO: packet_headerparser_b0 - Detected an invalid packet at item 240
gr::log :INFO: header_payload_demux0 - Parser returned #f
......仔细看下报错信息，应该是在 OFDM 代码中 header 数据的解析出现了问题，即以下模块：
这问题看起来像是源代码中的断言代码输出的 log，因此查看一下 Packet Header Parser 块的源码，发现其出错地如下：
。。。。。。if (!d_header_formatter->header_parser(in, tags)) {GR_LOG_INFO(d_logger,boost::format("Detected an invalid packet at item %1%") %nitems_read(0));message_port_pub(d_port, pmt::PMT_F);} else {pmt::pmt_t dict(pmt::make_dict());for (unsigned i = 0; i < tags.size(); i++) {dict = pmt::dict_add(dict, tags[i].key, tags[i].value);}message_port_pub(d_port, dict);}
。。。。。。代码中 d_header_formatter->header_parser(in, tags) 的作用是解析输入端口 in 中的数据并作为 tag 写入到 tags 中，解析成功就返回 ture，否则返回 false。看到这里，显然表明了上面报错是由于 header 数据的解析出现了问题。因此下面开始反思包头解析怎么就出问题了？按理说不应该呀，我直接那SMA线把两台 X310 的发送接收端口连起来接受数据的，首先就可以排除噪音太大带来的影响。那也没道理了。。排除了信道的影响，就只剩下自身的原因了。一通 google 下来（这时候就别指望baidu了。。），终于在一个回答中发现了一丝希望：
这么说的意思就是：在发送端最终数据进入 UHD:USRP Sink 前有一个 Multiply Const 模块:
通过调整该乘数因子的大小就可以控制发送信号的幅值大小，而我这种情况可能就是乘数因子太大的缘故，导致输出信号被限幅了（LFRX/LFTX子板信号限幅[-1, 1]v），这样就导致了发送信号的严重失真，接收端自然就解析不出来了。于是我直接减小乘数因子为 0.008（8m），之后在进行测试，问题完美解决！顺利与 usrp 世界进行了 hello world，哈哈哈哈哈哈哈
