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