GNURadio中运行ofdm_rx报错:gr::log :INFO: packet_headerparser_b0 - Detected an invalid packet at item ××

修改方法:减小发送端的乘数因子。

但是本着知其然还要知其所以然的学习态度,下面就解释下出现这种现象的原因:

2021.10.28 更新:

在实际的测试中发现,引起该问题的原因还有可能是接收信号解调失败,导致头信息(header_data)解析失败,进而无法知道帧长度等信息。这时就要考虑信道环境、解调算法等因素的影响了。

最近在尝试运行并修改 GNU Radio 中的 OFDM 例程,先尝试做一个文本传输的demo。

(位置 gnuradio/gr-digital/examples/ofdm)。

首先将官方例程 ofdm_tx 中的 OFDM_ReceiverUHD:USRP Sink 来替代。将 ofdm_rx 中的 OFDM_TransmitterUHD: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,哈哈哈哈哈哈哈

  • 5
    点赞
  • 6
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 9
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 9
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

地球被支点撬走啦

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值