discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Running tunnel.py/benchmark_tx.py (OFDM) with XCV


From: Tom Rondeau
Subject: Re: [Discuss-gnuradio] Running tunnel.py/benchmark_tx.py (OFDM) with XCVR2450?
Date: Tue, 31 Jan 2012 08:31:01 -0500

On Tue, Jan 31, 2012 at 8:28 AM, Florian Schlembach <address@hidden> wrote:
> But fiddling with gain values is often useful; even if you've already
> done that I recommend trying again, by reducing tx-amplitude and the
> actual gain values, shifting the terminals around (perhaps they're too
> close?).

We have now found out that we need a sampling rate of at least 2Msps
which means we have to set the bandwidth to at least 2MHz (I read sth
about that the USRPs have problems with higher decimation rates):

./benchmark_tx.py -f 2.400G -A TX/RX --tx-amplitude=0.2 -v -W 2M
./benchmark_rx.py -f 2.400G -A TX/RX --rx-gain=35 -v -W 2M


 The OFDM (bpsk) example is now working and all packets seems to be
transmitted. Unfortunately, not all of the packets could be
demodulated correctly as they are marked as "ok: False" - lets say a
quarter of them. This would yield a really bad performance in terms of
a reliable transmission. We also played around with the distance and
the alignment of the omni antennas but ultimately, we could not get
rid of the false packets.

Have you encountered a similar bad performance? Have you also
encountered such a strange behavior regarding the lower sampling rate?
What else could we try?

There is not channel coding on the packets. A packet of 1500 bytes is is 12000 bits. If a single bit is incorrect, the CRC check will fail and the packet is marked as bad.

You'll have to take the OFDM basic examples and extend them with error correcting codes to get anything like reliable performance from it.

Tom


reply via email to

[Prev in Thread] Current Thread [Next in Thread]