Running OFDM in gnuradio_ RX error: gr:: Log: info: packet_ headerparser_ b0 - Detected an invalid packet at item ××

Modification method ： Reduce the multiplier factor at the sending end .

But with the learning attitude of knowing what it is and why , The reasons for this phenomenon are explained below ：

2021.10.28 to update ：

In the actual test, it is found that , The cause of this problem may also be the failure of demodulation of the received signal , Cause header information （header_data） Parse failure , Then we can't know the frame length and other information . At this time, we should consider the channel environment 、 Demodulation algorithm and other factors affect .

Recently trying to run and modify GNU Radio Medium OFDM routine , First try to do a text transmission demo.

（ Location gnuradio/gr-digital/examples/ofdm）.

First, the official routine ofdm_tx Medium OFDM_Receiver use UHD:USRP Sink To replace . take ofdm_rx Medium OFDM_Transmitter use UHD:USRP Source To replace . And modify the data source to a txt file .USRP Some parameters are set as follows ：

The sender

The receiving end

  Because it is before the test of underwater acoustic communication , So the frequency is khz Grade , At this time, the antenna cannot be used for transmission , So use SMA Test by direct connection . Use two X310+LFTX/LFRX To test . At first , Data transmission at the transmitter is normal , But at the receiving end, the following appears error message ：

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
......

Look carefully at the error information , It should be OFDM In the code header There is a problem in data parsing , The following modules ：

  This problem looks like the output of the assertion code in the source code log, So check  Packet Header Parser  The block Source code , It is found that the error is as follows ：

......
    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);
    }
......

In the code  d_header_formatter->header_parser(in, tags) The function of is to parse the input port in And as tag Write to tags in , If the parsing is successful, it will return ture, Otherwise return to false. See here , Obviously, it shows that the error reported above is due to header There is a problem in data parsing . So let's start to reflect on how Baotou parsing went wrong ？ It's not supposed to be , I'll go straight there SMA Two cable handles X310 The sending and receiving ports of are connected to receive data , First of all, we can eliminate the impact of too much noise . That makes no sense .. Excluding the influence of channel , Only their own reasons . a fit google Come down （ Don't count on baidu 了 ..）, Finally in the One answer Found a glimmer of hope ：

That means ： At the sending end, the final data enters UHD:USRP Sink There's a Multiply Const modular :

By adjusting the multiplication factor The magnitude of the transmitted signal can be controlled by the magnitude of , And my situation may be because the multiplier factor is too large , Lead to The output signal is limited 了 （LFRX/LFTX Daughter board signal limiting [-1, 1]v）, This leads to serious distortion of the transmitted signal , Naturally, the receiving end cannot be parsed . So I just Reduce the multiplier factor by 0.008（8m）, After that, the test is carried out , Problem solving ！ Smooth and usrp The world has hello world, Ha ha ha ha ha ha ha