Re: Detected an invalid packet at item
Johannes, Thanks for your reply! Occasionally, I encounter difficulties in retrieving the data when I send a text file and attempt to read it using the message debug feature on the receiving end. Regards,HZ On Monday, May 15, 2023 at 05:30:59 AM CDT, Johannes Demel wrote: Hi Hamed, you mentioned that increasing the TX and RX gain reduced the number of invalid packets. Still, as long as you transmit over an imperfect channel, there will be reception errors. The reports you receive stem from the logging system. They are tagged ":info:" because this might be an interesting information in some cases. However, this is not a software system error. This is a reception error and should be treated as such. You already mentioned a few channel effects that influence your reception: - multipath - interference I'd like to stress that: - noise - hardware imperfections - any unfortunate condition in your receiver chain may also affect your reception. The questions that arise are: - What do you want to fix here? - Did you observe anything that you didn't expect? Cheers Johannes On 14.05.23 05:33, Hamed Al-Zubi wrote: > > Ed, > > I tried the NLOS scenario to avoid distortion, but still the same error > occurs. > > Thanks! > HZ > On Saturday, May 13, 2023 at 11:07:22 AM CDT, Ed Criscuolo > wrote: > > > 2 meters seems like an incredibly short distance unless you have an > attenuator in series with the Tx antenna. You may be overdriving the > receiver and causing distortion errors. > > @(^.^)@ Ed > Sent from my iPhone > >> On May 12, 2023, at 8:10 PM, Hamed Al-Zubi >> wrote: >> >> >> Hello, >> >> I am utilizing two USRPs, specifically the X300 models, along with >> GNURadio for the purpose of transmitting and receiving OFDM signals. I >> have implemented the OFDM flowgraphs available on Github for this >> purpose. The transmission and reception setup involves LOS >> (Line-of-Sight) configuration, where the transmit and receive antennas >> are positioned with a separation distance of 2 meters. To minimize the >> impact of multipath interference, the antennas are surrounded by >> absorption boards. Although the transmission and reception process >> itself is functioning without issues, I have encountered a problem >> when displaying the channel state information. In particular, there >> are instances where invalid packets are detected, as evidenced by the >> following occurrences. >> >> *packet_headerparser_b :info: Detected an invalid packet at item 167472* >> *header_payload_demux :info: Parser returned #f* >> >> I have searched the possible causes of the error I'm encountering, and >> there are a few factors that have been suggested: >> >> 1- Interference--> I used different frequencies and ensured they are >> not in use. >> 2- Multipath --> absorption boards were used to minimize the impact of >> multipath. >> 3- Some people suggested to change the FFT length and CRC length as a >> potential solution, however, modifying these papermeters did not >> resolve the issue. >> >> When I used a channel model instead of USRPs, the error did not occur. >> I am still uncertain about the exact cause of the error I am experiencing. >> >> >> Thanks, >> HZ
Re: Detected an invalid packet at item
Hi Hamed, you mentioned that increasing the TX and RX gain reduced the number of invalid packets. Still, as long as you transmit over an imperfect channel, there will be reception errors. The reports you receive stem from the logging system. They are tagged ":info:" because this might be an interesting information in some cases. However, this is not a software system error. This is a reception error and should be treated as such. You already mentioned a few channel effects that influence your reception: - multipath - interference I'd like to stress that: - noise - hardware imperfections - any unfortunate condition in your receiver chain may also affect your reception. The questions that arise are: - What do you want to fix here? - Did you observe anything that you didn't expect? Cheers Johannes On 14.05.23 05:33, Hamed Al-Zubi wrote: Ed, I tried the NLOS scenario to avoid distortion, but still the same error occurs. Thanks! HZ On Saturday, May 13, 2023 at 11:07:22 AM CDT, Ed Criscuolo wrote: 2 meters seems like an incredibly short distance unless you have an attenuator in series with the Tx antenna. You may be overdriving the receiver and causing distortion errors. @(^.^)@ Ed Sent from my iPhone On May 12, 2023, at 8:10 PM, Hamed Al-Zubi wrote: Hello, I am utilizing two USRPs, specifically the X300 models, along with GNURadio for the purpose of transmitting and receiving OFDM signals. I have implemented the OFDM flowgraphs available on Github for this purpose. The transmission and reception setup involves LOS (Line-of-Sight) configuration, where the transmit and receive antennas are positioned with a separation distance of 2 meters. To minimize the impact of multipath interference, the antennas are surrounded by absorption boards. Although the transmission and reception process itself is functioning without issues, I have encountered a problem when displaying the channel state information. In particular, there are instances where invalid packets are detected, as evidenced by the following occurrences. *packet_headerparser_b :info: Detected an invalid packet at item 167472* *header_payload_demux :info: Parser returned #f* I have searched the possible causes of the error I'm encountering, and there are a few factors that have been suggested: 1- Interference--> I used different frequencies and ensured they are not in use. 2- Multipath --> absorption boards were used to minimize the impact of multipath. 3- Some people suggested to change the FFT length and CRC length as a potential solution, however, modifying these papermeters did not resolve the issue. When I used a channel model instead of USRPs, the error did not occur. I am still uncertain about the exact cause of the error I am experiencing. Thanks, HZ smime.p7s Description: S/MIME Cryptographic Signature
Re: Detected an invalid packet at item
Ed, I tried the NLOS scenario to avoid distortion, but still the same error occurs. Thanks!HZ On Saturday, May 13, 2023 at 11:07:22 AM CDT, Ed Criscuolo wrote: 2 meters seems like an incredibly short distance unless you have an attenuator in series with the Tx antenna. You may be overdriving the receiver and causing distortion errors. @(^.^)@ EdSent from my iPhone On May 12, 2023, at 8:10 PM, Hamed Al-Zubi wrote: Hello, I am utilizing two USRPs, specifically the X300 models, along with GNURadio for the purpose of transmitting and receiving OFDM signals. I have implemented the OFDM flowgraphs available on Github for this purpose. The transmission and reception setup involves LOS (Line-of-Sight) configuration, where the transmit and receive antennas are positioned with a separation distance of 2 meters. To minimize the impact of multipath interference, the antennas are surrounded by absorption boards. Although the transmission and reception process itself is functioning without issues, I have encountered a problem when displaying the channel state information. In particular, there are instances where invalid packets are detected, as evidenced by the following occurrences. packet_headerparser_b :info: Detected an invalid packet at item 167472header_payload_demux :info: Parser returned #f I have searched the possible causes of the error I'm encountering, and there are a few factors that have been suggested: 1- Interference--> I used different frequencies and ensured they are not in use.2- Multipath --> absorption boards were used to minimize the impact of multipath.3- Some people suggested to change the FFT length and CRC length as a potential solution, however, modifying these papermeters did not resolve the issue. When I used a channel model instead of USRPs, the error did not occur. I am still uncertain about the exact cause of the error I am experiencing. Thanks, HZ
Re: Detected an invalid packet at item
2 meters seems like an incredibly short distance unless you have an attenuator in series with the Tx antenna. You may be overdriving the receiver and causing distortion errors. @(^.^)@ Ed Sent from my iPhone > On May 12, 2023, at 8:10 PM, Hamed Al-Zubi wrote: > > > Hello, > > I am utilizing two USRPs, specifically the X300 models, along with GNURadio > for the purpose of transmitting and receiving OFDM signals. I have > implemented the OFDM flowgraphs available on Github for this purpose. The > transmission and reception setup involves LOS (Line-of-Sight) configuration, > where the transmit and receive antennas are positioned with a separation > distance of 2 meters. To minimize the impact of multipath interference, the > antennas are surrounded by absorption boards. Although the transmission and > reception process itself is functioning without issues, I have encountered a > problem when displaying the channel state information. In particular, there > are instances where invalid packets are detected, as evidenced by the > following occurrences. > > packet_headerparser_b :info: Detected an invalid packet at item 167472 > header_payload_demux :info: Parser returned #f > > I have searched the possible causes of the error I'm encountering, and there > are a few factors that have been suggested: > > 1- Interference--> I used different frequencies and ensured they are not in > use. > 2- Multipath --> absorption boards were used to minimize the impact of > multipath. > 3- Some people suggested to change the FFT length and CRC length as a > potential solution, however, modifying these papermeters did not resolve the > issue. > > When I used a channel model instead of USRPs, the error did not occur. > I am still uncertain about the exact cause of the error I am experiencing. > > > Thanks, > HZ
Re: Detected an invalid packet at item
Hi Marcus, I am using GPSDO as a reference clock. I also increased the UHD gain of both TX and RX. The number of invalid packets was reduced, but still there is some invalid packets. Thanks, HZOn Saturday, May 13, 2023 at 04:36:10 AM CDT, Marcus Müller wrote: Hi Hamed, consider noise. Any real-world communication is subject to it. Another thing would be sample clock offset, which you could reduce if you clock both X300 from the same reference clock, or the Clock ref out on the back of the first X300 and connect it to the Clock ref in of the second, and set the clock source to "external". Also, good idea to isolate multipath effects, but don't forget that if your system can't deal with the multipath environment you're in, you've incorrectly designed your OFDM system. Best, Marcus On 13.05.23 02:09, Hamed Al-Zubi wrote: Hello, I am utilizing two USRPs, specifically the X300 models, along with GNURadio for the purpose of transmitting and receiving OFDM signals. I have implemented the OFDM flowgraphs available on Github for this purpose. The transmission and reception setup involves LOS (Line-of-Sight) configuration, where the transmit and receive antennas are positioned with a separation distance of 2 meters. To minimize the impact of multipath interference, the antennas are surrounded by absorption boards. Although the transmission and reception process itself is functioning without issues, I have encountered a problem when displaying the channel state information. In particular, there are instances where invalid packets are detected, as evidenced by the following occurrences. packet_headerparser_b :info: Detected an invalid packet at item 167472 header_payload_demux :info: Parser returned #f I have searched the possible causes of the error I'm encountering, and there are a few factors that have been suggested: 1- Interference--> I used different frequencies and ensured they are not in use. 2- Multipath --> absorption boards were used to minimize the impact of multipath. 3- Some people suggested to change the FFT length and CRC length as a potential solution, however, modifying these papermeters did not resolve the issue. When I used a channel model instead of USRPs, the error did not occur. I am still uncertain about the exact cause of the error I am experiencing. Thanks, HZ
Re: Detected an invalid packet at item
Hi Hamed, consider noise. Any real-world communication is subject to it. Another thing would be sample clock offset, which you could reduce if you clock both X300 from the same reference clock, or the Clock ref out on the back of the first X300 and connect it to the Clock ref in of the second, and set the clock source to "external". Also, good idea to isolate multipath effects, but don't forget that if your system can't deal with the multipath environment you're in, you've incorrectly designed your OFDM system. Best, Marcus On 13.05.23 02:09, Hamed Al-Zubi wrote: Hello, I am utilizing two USRPs, specifically the X300 models, along with GNURadio for the purpose of transmitting and receiving OFDM signals. I have implemented the OFDM flowgraphs available on Github for this purpose. The transmission and reception setup involves LOS (Line-of-Sight) configuration, where the transmit and receive antennas are positioned with a separation distance of 2 meters. To minimize the impact of multipath interference, the antennas are surrounded by absorption boards. Although the transmission and reception process itself is functioning without issues, I have encountered a problem when displaying the channel state information. In particular, there are instances where invalid packets are detected, as evidenced by the following occurrences. *packet_headerparser_b :info: Detected an invalid packet at item 167472* *header_payload_demux :info: Parser returned #f* I have searched the possible causes of the error I'm encountering, and there are a few factors that have been suggested: 1- Interference--> I used different frequencies and ensured they are not in use. 2- Multipath --> absorption boards were used to minimize the impact of multipath. 3- Some people suggested to change the FFT length and CRC length as a potential solution, however, modifying these papermeters did not resolve the issue. When I used a channel model instead of USRPs, the error did not occur. I am still uncertain about the exact cause of the error I am experiencing. Thanks, HZ
Detected an invalid packet at item
Hello, I am utilizing two USRPs, specifically the X300 models, along with GNURadio for the purpose of transmitting and receiving OFDM signals. I have implemented the OFDM flowgraphs available on Github for this purpose. The transmission and reception setup involves LOS (Line-of-Sight) configuration, where the transmit and receive antennas are positioned with a separation distance of 2 meters. To minimize the impact of multipath interference, the antennas are surrounded by absorption boards. Although the transmission and reception process itself is functioning without issues, I have encountered a problem when displaying the channel state information. In particular, there are instances where invalid packets are detected, as evidenced by the following occurrences. packet_headerparser_b :info: Detected an invalid packet at item 167472header_payload_demux :info: Parser returned #f I have searched the possible causes of the error I'm encountering, and there are a few factors that have been suggested: 1- Interference--> I used different frequencies and ensured they are not in use.2- Multipath --> absorption boards were used to minimize the impact of multipath.3- Some people suggested to change the FFT length and CRC length as a potential solution, however, modifying these papermeters did not resolve the issue. When I used a channel model instead of USRPs, the error did not occur. I am still uncertain about the exact cause of the error I am experiencing. Thanks, HZ
Re: [Discuss-gnuradio] INFO: Detected an invalid packet at item INFO: Parser returned #f
On 30 Jan 2015, at 14:00, zs zswx_...@126.com wrote:
Hi Bastian:
Thank you so much.I use the ofdm example,and I think maybe
the crc is wrong as you said,thank you.
Can you give me some advices to avoid these warning?Thank
you so much.
The fact that your CRC is not correct just means that *something* does not
work. This can have a lot of reasons. For example you could try different gain
settings. Also assert that the samples that you stream to your USRP are in the
interval [-1, 1].
If that doesn’t solve your problem you can debug your flow graph with graphical
sinks and check if the signal looks as expected.
At 2015-01-30 00:43:12, Bastian Bloessl bloe...@ccs-labs.org
wrote:
Hi,
On 01/29/2015 03:13 PM, zs wrote:
Can you tell me,for general,in which circumstance,the packet header maybe
corrupt?
This is very hard to tell since I don't know what you are doing. I guess
you use a header_formatter in your flow graph and (for whatever reason)
its header_parse method returns false.
For example with the default header it looks like this happens if the
CRC is not correct
https://github.com/gnuradio/gnuradio/blob/master/gr-digital/lib/packet_header_default.cc#L132
At 2015-01-29 20:44:13, Bastian Bloessl
bloe...@ccs-labs.org
wrote:
Hi,
On 01/29/2015 01:03 PM, zs wrote:
Detected an invalid packet at item INFO: Parser returned #f.
The answer may be RF settings are distorting your signal or others.I
want to ask a question.Which block in gnuradio give us this hint.Where
is the source code of the block?And have someone can help me to explain
this problem more details?Why will have this error/warning?
~/src/gnuradio ack-grep -C 3 an invalid packet
gr-digital/lib/packet_headerparser_b_impl.cc
80- );
81-
82- if (!d_header_formatter-header_parser(in, tags)) {
83:GR_LOG_INFO(d_logger, boost::format(Detected an invalid packet
at
item %1%) % nitems_read(0));
84-message_port_pub(msg_port_id, pmt::PMT_F);
85- } else {
86-pmt::pmt_t dict(pmt::make_dict());
I guess your packet header is corrupt.
Best,
Bastian
--
Dipl.-Inform. Bastian Bloessl
Distributed Embedded Systems Group
University of Paderborn, Germany
http://www.ccs-labs.org/~bloessl/
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] INFO: Detected an invalid packet at item INFO: Parser returned #f
Hi Bastian:
Thank you so much.I use the ofdm example,and I think maybe the
crc is wrong as you said,thank you.
Can you give me some advices to avoid these warning?Thank you
so much.
Best regards,
zs
At 2015-01-30 00:43:12, Bastian Bloessl bloe...@ccs-labs.org wrote:
Hi,
On 01/29/2015 03:13 PM, zs wrote:
Can you tell me,for general,in which circumstance,the packet header maybe
corrupt?
This is very hard to tell since I don't know what you are doing. I guess
you use a header_formatter in your flow graph and (for whatever reason)
its header_parse method returns false.
For example with the default header it looks like this happens if the
CRC is not correct
https://github.com/gnuradio/gnuradio/blob/master/gr-digital/lib/packet_header_default.cc#L132
At 2015-01-29 20:44:13, Bastian Bloessl bloe...@ccs-labs.org wrote:
Hi,
On 01/29/2015 01:03 PM, zs wrote:
Detected an invalid packet at item INFO: Parser returned #f.
The answer may be RF settings are distorting your signal or others.I
want to ask a question.Which block in gnuradio give us this hint.Where
is the source code of the block?And have someone can help me to explain
this problem more details?Why will have this error/warning?
~/src/gnuradio ack-grep -C 3 an invalid packet
gr-digital/lib/packet_headerparser_b_impl.cc
80- );
81-
82- if (!d_header_formatter-header_parser(in, tags)) {
83: GR_LOG_INFO(d_logger, boost::format(Detected an invalid packet at
item %1%) % nitems_read(0));
84- message_port_pub(msg_port_id, pmt::PMT_F);
85- } else {
86- pmt::pmt_t dict(pmt::make_dict());
I guess your packet header is corrupt.
Best,
Bastian
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] INFO: Detected an invalid packet at item INFO: Parser returned #f
Hi,
On 01/29/2015 03:13 PM, zs wrote:
Can you tell me,for general,in which circumstance,the packet header maybe
corrupt?
This is very hard to tell since I don't know what you are doing. I guess
you use a header_formatter in your flow graph and (for whatever reason)
its header_parse method returns false.
For example with the default header it looks like this happens if the
CRC is not correct
https://github.com/gnuradio/gnuradio/blob/master/gr-digital/lib/packet_header_default.cc#L132
At 2015-01-29 20:44:13, Bastian Bloessl bloe...@ccs-labs.org wrote:
Hi,
On 01/29/2015 01:03 PM, zs wrote:
Detected an invalid packet at item INFO: Parser returned #f.
The answer may be RF settings are distorting your signal or others.I
want to ask a question.Which block in gnuradio give us this hint.Where
is the source code of the block?And have someone can help me to explain
this problem more details?Why will have this error/warning?
~/src/gnuradio ack-grep -C 3 an invalid packet
gr-digital/lib/packet_headerparser_b_impl.cc
80- );
81-
82- if (!d_header_formatter-header_parser(in, tags)) {
83: GR_LOG_INFO(d_logger, boost::format(Detected an invalid packet at
item %1%) % nitems_read(0));
84- message_port_pub(msg_port_id, pmt::PMT_F);
85- } else {
86- pmt::pmt_t dict(pmt::make_dict());
I guess your packet header is corrupt.
Best,
Bastian
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] INFO: Detected an invalid packet at item INFO: Parser returned #f
Hi,
On 01/29/2015 01:03 PM, zs wrote:
Detected an invalid packet at item INFO: Parser returned #f.
The answer may be RF settings are distorting your signal or others.I
want to ask a question.Which block in gnuradio give us this hint.Where
is the source code of the block?And have someone can help me to explain
this problem more details?Why will have this error/warning?
~/src/gnuradio ack-grep -C 3 an invalid packet
gr-digital/lib/packet_headerparser_b_impl.cc
80- );
81-
82- if (!d_header_formatter-header_parser(in, tags)) {
83: GR_LOG_INFO(d_logger, boost::format(Detected an invalid packet at
item %1%) % nitems_read(0));
84- message_port_pub(msg_port_id, pmt::PMT_F);
85- } else {
86- pmt::pmt_t dict(pmt::make_dict());
I guess your packet header is corrupt.
Best,
Bastian
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] INFO: Detected an invalid packet at item INFO: Parser returned #f
Hi all: Thank you in advance.I have searched the questionINFO: Detected an invalid packet at item INFO: Parser returned #f. The answer may be RF settings are distorting your signal or others.I want to ask a question.Which block in gnuradio give us this hint.Where is the source code of the block?And have someone can help me to explain this problem more details?Why will have this error/warning? Thank you. Best regards, zs ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] INFO: Detected an invalid packet at item INFO: Parser returned #f
Hi Bastian:
Thank you so much for your kindly reply.Can you tell me,for
general,in which circumstance,the packet header maybe corrupt?
Thank you so much.
Best regards,
zs
At 2015-01-29 20:44:13, Bastian Bloessl bloe...@ccs-labs.org wrote:
Hi,
On 01/29/2015 01:03 PM, zs wrote:
Detected an invalid packet at item INFO: Parser returned #f.
The answer may be RF settings are distorting your signal or others.I
want to ask a question.Which block in gnuradio give us this hint.Where
is the source code of the block?And have someone can help me to explain
this problem more details?Why will have this error/warning?
~/src/gnuradio ack-grep -C 3 an invalid packet
gr-digital/lib/packet_headerparser_b_impl.cc
80- );
81-
82- if (!d_header_formatter-header_parser(in, tags)) {
83:GR_LOG_INFO(d_logger, boost::format(Detected an invalid packet at
item %1%) % nitems_read(0));
84-message_port_pub(msg_port_id, pmt::PMT_F);
85- } else {
86-pmt::pmt_t dict(pmt::make_dict());
I guess your packet header is corrupt.
Best,
Bastian
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] INFO: Detected an invalid packet at item INFO: Parser returned #f
Hi Bastian:
Thank you so much.I use the ofdm example,and I think maybe the
crc is wrong as you said,thank you.
Best regards,
zs
At 2015-01-30 00:43:12, Bastian Bloessl bloe...@ccs-labs.org wrote:
Hi,
On 01/29/2015 03:13 PM, zs wrote:
Can you tell me,for general,in which circumstance,the packet header maybe
corrupt?
This is very hard to tell since I don't know what you are doing. I guess
you use a header_formatter in your flow graph and (for whatever reason)
its header_parse method returns false.
For example with the default header it looks like this happens if the
CRC is not correct
https://github.com/gnuradio/gnuradio/blob/master/gr-digital/lib/packet_header_default.cc#L132
At 2015-01-29 20:44:13, Bastian Bloessl bloe...@ccs-labs.org wrote:
Hi,
On 01/29/2015 01:03 PM, zs wrote:
Detected an invalid packet at item INFO: Parser returned #f.
The answer may be RF settings are distorting your signal or others.I
want to ask a question.Which block in gnuradio give us this hint.Where
is the source code of the block?And have someone can help me to explain
this problem more details?Why will have this error/warning?
~/src/gnuradio ack-grep -C 3 an invalid packet
gr-digital/lib/packet_headerparser_b_impl.cc
80- );
81-
82- if (!d_header_formatter-header_parser(in, tags)) {
83: GR_LOG_INFO(d_logger, boost::format(Detected an invalid packet at
item %1%) % nitems_read(0));
84- message_port_pub(msg_port_id, pmt::PMT_F);
85- } else {
86- pmt::pmt_t dict(pmt::make_dict());
I guess your packet header is corrupt.
Best,
Bastian
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
