Re: Detected an invalid packet at item

[Hamed Al-Zubi]

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, 

HZ

On Saturday, May 13, 2023 at 04:36:10 AM CDT, Marcus Müller <marcus.mueller@ettus.com> 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