Why packet decode failure happen when fft-length is set to 64?

GNU Radio
1

Hi guys,
Thanks in advance. I am using usrp2 in OFM example. When I set
fft-length to 64, subcarrier to 32,the receiver cannnot decode the
packet correctly. The whole chunk of received data are almost false.
However, when I set fft-length to 128, subcarriers to 64, nearly all
packets can be decode correctly. I feel so confused about that. Does
anyone know that?

Sent from my iPhone

2

On Wed, Mar 27, 2013 at 5:33 AM, Yingjie C. [email protected] wrote:

Hi guys,
Thanks in advance. I am using usrp2 in OFM example. When I set
fft-length to 64, subcarrier to 32,the receiver cannnot decode the
packet correctly. The whole chunk of received data are almost false.
However, when I set fft-length to 128, subcarriers to 64, nearly all
packets can be decode correctly. I feel so confused about that. Does
anyone know that?

Could be related to the subcarrier spacing in the bandwidth and
frequency offset. Try to hand-tune your tx and rx frequencies so they
are as close as you can get (using uhd_siggen and uhd_fft) them and
see if that helps.

Tom

3

Hi,

I tried to run tunnel.py on my machine (Ubuntu 11.10) with 2 USRPs
(usrp1).

from one side I launched:
./tunnel.py --tx-freq 2.4G --rx-freq 2.4001G -a=“name=dev1” -A TX/RX
–bitrate 500k -v
then :
sudo ifconfig gr0 192.168.200.1
from another terminal (on the same machine):
./tunnel.py --rx-freq 2.4G --tx-freq 2.4001G -a=“name=dev0” -A TX/RX
–bitrate 500k -v
sudo ifconfig gr1 192.168.200.2
But when I run ping from both sides I see nothing displayed!
Is what I’ve done correct? Is it possible to use one machine? What did I
miss?
Can you help me plz!

Best Regards,
Nada

4

An exact clock source may help, or clocking both USRPs from the same
clock.

Ralph.

Could be related to the subcarrier spacing in the bandwidth and frequency
offset. Try to hand-tune your tx and rx frequencies so they are as close
as

5

In case your USRPs have an input for an external clock just feed them
from
one external clock source. USRP1 need a modification as the external
clock
connector is not yet installed, but the connections are available on the
PCB.

Ralph.

6

There’s stuff missing in tunnel.py. The receiver has to return ICMP echo
reply. Instead it writes to the tunnel socket. The packet will get to
the
kernel but will be promptly dropped as it has a source address that does
not originate locally.

Add code in tunnel.py to do an icmp echo reply.

On Wed, Mar 27, 2013 at 11:54 AM, Nada ABDELKADER <